How to C

https://matt.sh/howto-c

Very good read for anyone that wants to write this outdated language in 2016.

>>40

Sure:

Unless you're writing something which directly interfaces with the hardware, don't.

Even if you are interfacing with hardware, consider any other language with inline asm.

>>40
Don't be a retard. If you are a retard, don't program at all.

>>41
You are probably a retarded code monkey.

check 'em

>>42
As >>41, I am a big believer in teaching the machine to measure and figure out out how to make things fast, not require the human to hand-hold the CPU through its every step. The latter is the human working for the machine, which is backwards.

>>33
It's simply a recommendation, not a definition.

>>40
How to C in 2016:
Read K&R and C89.

>>43
nice

>>1
You should write Rust instead.

>>1
SHUT UP YA FUCKIN YUPPY. IF U WROTE DAT ARTICLE UR A BIT PUSHIN STACK BOI RETOID DAT YUPPS ON HIS OWN COCK.

>>2
OR JUST DONT INCLUDE FUCKIN <stdint.h>

>>8
ITS DA FAT CATS AT DA FUCKIN ISO DAT DID IT, DA SAME ONES DAT HAVE PICKED AWAY N CONTINUE TO PICK AWAY AT DA LANGUAGE DAT DEANIS RICKY LOVED TURNIN IT TO A HUNK OF CORPORATE CRAP.

DA STAK BOI DAT WROTE DA ARTICLE'S JUST ONE OF DER FUCKIN PAWNS. DOESNT KNO DA FIRST THING ABOUT C, JUST HAS HIS HED UP HIS BOSS'S BUTT N HIS BOSS SAID SOME SHIT IN PASSIN ABOUT C SO HE THOT HED CHECK IT OUT N HERE'S DA CRAP HE CAME OUT WITH. NOTHIN OUT OF DA ORDINARY RLY. IF U DIDNT FIND C URSELF, ON UR OWN TERMS, U SHUD SHUT UR FUCKIN MOUTH N WRITE ABOUT SOMETHIN U ACTUALLY UNDERSTAND

>>15

I HAV A BETTER IDEA: DONT DO NESTED INCLUDES, YA FUCKIN RETOID. THEN U DONT NEED EITHER ONE.

>>16

I do have to agree with him on size_t (although I try to avoid it) and -Wall -Wextra, though.

EXCEPT HE THINKS U NEED TO USE ITALL THE FUCKIN TIME BECAUSE HE TIHNKS U NEED TO BE ABLE TO STORE THE SIZE OF EVERY POSSIBLE FUCKIN OBJECT ALL THE FUCKIN TIME WHEN int WILL PROBABLY DO DA JOB WELL AND WITH NO FUCKIN ISSUES FOR REPRESENTIN DA SIZE OF MOST OBJECTS.

N WAT DA FUCK'S WITH HIS COMMENT DAT sizeof RETURNS SOMETHIN? IT'S A FUCKIN OPERATOR. I KNO HIS STACK BOY ASS THINKS sizeof(int) IS A FUNCTION CALL, BUT I GOT NEWS FOR U, U BIT PUSHERS: ITS TWO OPERATORS: sizeof FOLLOWED BY A CAST. YAINT RED DA STANDARD, YAINT WRITTEN A DECENT LINE OF C, AND YAINT ABLE TO DISCUSS C INTELLIGENTLY. GO BAK TO UR FUCKIN NEW AGE YUPPY LANGUAGES

>>19

UR BIRTH'S AN ACCIDENT OF HISTORY, YA FUCKIN STACK BOI RETOID

>>48

Please write a C tutorial, LAC.
With lots of examples and shit.
Maybe we can even publish it.
Those "publish your own book" allow you to print 100 copies for around $2 each.

I KNO A GOOD GUIDE TO C, ITS CALLED KERNYAN N RICKY 2

DO DEY USE HEADER GUARDS IN K&R2? NO:

calc.h:
#define NUMBER '0'
void push(double);
double pop(void);
int getop(char []);
int getch(void);
void ungetch(int);

(DEY TEACH EM THO, BUT GUESS WAT? DER'S NO FUCKIN #pragma BULLSHIT)

HOW ABOUT FIXED INTEGER TYPES N <stdint.h>? NOWHERE TO BE FOUND.

AND sizeof?

The sizeof operator yields the number of bytes required to store an object of the type of its operand. The operand is either an expression, which is not evaluated, or a parenthesized type name.

OPERATOR. NOT A FUCKIN FUNCTION.

WAT ABOUT EXCESSIVE USE OF size_t IN K&R2? HELL NO:

int getline(char line[], int max);

int strlen(char *s);

ARE DEY WRITING getline AND strlen FOR ANYTHIN OTHER THAN THEIR OWN PERSONAL USE HERE? NO. SO WHY DA FUCK IS size_t IMPORTANT IF U ALREADY KNOW THAT int CAN STORE DA SIZES OF EVERYTHIN UR WORKIN WITH? IF UR WRITIN A LIBRARY AND U HAVE NO FUCKIN IDEA HOW SOMEONE'S GONNA CALL UR FUNCTION, THEN YEA, size_t'S DA TYPE TO USE THERE COS U DON'T KNOW WHAT'S GOIN INTO UR FUNCTIONS AND U WANT TO HANDLE AS MANY INPUTS AS POSSIBLE. BUT OTHERWISE UR JUST OVERENGINEERIN SHIT, AND IF U WANT TO OVERENGINEER SHIT, U SHOULD BE USIN C++ OR JAVA AND WRITIN A CLASS FOR EVERY LITTLE FUCKIN THING.

IN CONCLUSION, BIT PUSHER MATT'S POSITION ON C, WITH HIS HIGHLY SOFISTICATED TYPE NAMES, AMOUNTS TO: "I'M TOO STOOPID TO READ DA STANDARD (DAT'S Y I THINK sizeof IS A FUNCTION!), TOO STOOPID READ ABOUT DA RANGES OF STANDARD TYPES (DAT'S Y I USE FIXED WIDTH INTEGER TYPEZ!), N TOO STOOPID TO THINK ABOUT MY PROGRAM'S INPUT RANGES (DAT'S Y I USE size_t EVERYWHERE! IT HANDLEZ EVERYTHIN!)

THANKS FOR DA ARTICLE, BIT PUSHER MATT, UR A REAL PIECE OF WORK. I HOPE DIS ARTICLE GETS U WHAT U WERE SEEKING ALL ALONG: A BIG FAT SLOPPY KISS FROM UR BOSS IN DA BIG MONDAY MEETING, AND A STICKER U CAN WEAR ON UR SHIRT DAT SAYS "C EXPERT", SO U CAN PARADE AROUND FOR DA REST OF DA WEEK PORTRAYING A SENSE OF SUPERIORITY OVER UR FELLOW COFFEE-GUZZLING RETOIDS

NOW GET DA FUCK OUTTA MY THRED, YA CORPORATE CRAPAZOID.

I love C. It's really fun, like a puzzle, to come up with ways to make do shit with such an un-expressive language.

<3 zhivago
https://www.reddit.com/r/programming/comments/412kqz/a_critique_of_how_to_c_in_2016/cz05ket

>>41

Look at this horse's ass. In the real world, you always write in C.

>>53
Have fun living in the 70s.

>>54
Why do you kids always think that 'new = better'?
C is much more useful and efficient than some ``modern'' languages out there.

>>55
Bullshit. C is not useful, and not more efficient. Every major C project I've seen "In The Real World", aka in actual use in companies, is bloated to shit with string libraries, bad attempts at OO, bad attempts at dynamic dispatch, all because the language itself doesn't do jack shit and is fucking useless.

There is no efficiency or usefulness at all in C in the Real World™.

>>55
Programmer time is far more expensive than computer time. In the real world in most applications, it is not necessary for a programmer to manually manage computer resources to solve most software problems. It is normally a more efficient use of the programmer time for them to use a high level language that allows the programmer to concentrate on the business logic with minimal regard to machine logic.

>>55
So tell me, in which language is your kernel written in? Your windowing system? Your file manager? Your web-browser?

In the end, pretty much everything is in C.

How is it not useful?

Your's you Haskell (or whatever ``modern'' language you advocate) operating system?

>>58
Kernel, fine. But do you see how much bullshit all these massive file manager, window manager, and web browser projects have to put up with? And again, they all have their Greenspun bloat of janky dynamic infrastructure cobbled together because it's impossible to write such large, dynamic programs in straightforward C. It always becomes a beyond-C abomination.

All of these projects would get a ton shorter, simpler, and yes FUCKING FASTER if they wrote it in a good fast compiled dynamic language, Common Lisp being my choice.

If you're writing a 100-line C program, or a straightforward data conversion library, sure, whatever, you won't hit too many problems. If you're writing a million-line monster that isn't the kernel & drivers, C is fucking stupid, a waste of time, and all the shit you pile on top of it to try to implement your dynamic runtime user features slow the fuck out of it.

Everything is machine code. C is just one way to get there, and is an extremely shitty way for large dynamic applications. Enough compilers and JITs generate their own byte-level machine code without going through C.

>>59
Oh, and do I even need to mention pointer level security, especially when piling on the dynamic infrastructure shit on top of C? It's unmanageable, with billions of unknown vulnerabilities that continually creep out, because it's impossible to manage the dynamic state from the static view of the world that C imposes. Fuck that noise.

>>59
1.Lisp depends on C or generates C code(with exception of some exotics like https://github.com/benthor/mongoose)
2.Lisp is much slower and takes more memory. GC,eval and List structure aren't cheap.
3.Lisp can be replaced by adding a tokenizer-eval macro feature to C preprocessor see
http://w11.zetaboards.com/frozenbbs/topic/11501531/
Which would eliminate any advantage of using Lisp as C preprocessor if added to C standard.

>>61
Fuck you, and fuck your ignorance.

Lisp has its own assemblers and compilers. The bootstrap from C could happen in any language.

Large C bullshit does fucking reference counting and shit-tons of copies. GC is faster in large apps.

Tokenizer eval shit is shit. Flipping around cons cells does not even scratch the surface of a powerful, fast, dynamic language.

You're a cave man of computing. Stop waving your shit around people who know how to drive a computer.

>>62

Stop waving your shit around people who know how to drive a computer.

World doesn't run on elegant abstractions. Its runs in C/C++ and this wouldn't change for awhile(and C/C++ standards guarantee it would be backward compatible).
You fear that adding tokenizer eval will make your Lisp irrelevant? Guess what: its already implemented in some third-party preprocessors, its just isn't part of the C standard.

>>63
Tokenizer cons cells are literally a toy. How are you going to networking/graphics/sound/input/etc in the preprocessor? Do you seriously believe that's in the future for the preprocessor of a portable assembly code?

The only reason the world runs on C is because of that portable assembly language use case, which has a lot of momentum in writing OSes. But then they expose the OS interface only as a C interface, nearly requiring that their applications be written in their systems language, which is fucking backwards and everybody knows it. It's that interface that keeps everything clung to C.

But the web world is far beyond C & C++. The ENTERPRISE world loves it some Cobol, Java, and whatnot. Devops is python, perl, ruby, shell scripts. Supercomputing is Fortran. So you've got games, UI libs which are still stuck onto that C/OS interface shit, and basic OS utilities still being written in C. But even the utility layer is being taken over by other languages.

>>64

Tokenizer cons cells are literally a toy. How are you going to networking/graphics/sound/input/etc in the preprocessor?

Tokenizer-eval isn't used alone:
it produces C code which is run and then uses "networking/graphics/sound/input/etc" as standard C code does(by using libraries/functions/etc).

Do you seriously believe that's in the future for the preprocessor of a portable assembly code?

Yes, tokenizer-eval makes C preprocessor more powerful than Lisp(though a bit more verbose, will require a macro library like void.h to fully utilize). You underestimate what could be done with it, since you're used to "elegant and terse" abstractions that come with Lisp.

The ENTERPRISE world loves it some Cobol, Java, and whatnot. Devops is python, perl, ruby, shell scripts. Supercomputing is Fortran.

Written in C/C++ or uses C infrastructure.

>>65

You underestimate what could be done with it, since you're used to "elegant and terse" abstractions that come with Lisp.

You don't even know what "elegant and terse" means, and I have no idea what you think "more powerful than Lisp" means, because you clearly know nothing of the language at all. It won't be faster, it won't be safer, it won't be more expressive. Maybe it could have a smaller footprint? That's about it.

Written in C/C++ or uses C infrastructure.

Your attempt at a meme is the whining of a child and needs to die. Because it's an artifact that has disappeared behind the scenes, it can be replaced with anything. It is a commodity of zero value in that position. Your insistence on bringing it up reinforces its lack of value.

>>66

"more powerful than Lisp" means, because you clearly know nothing of the language at all.

C macros are lexer-level: they allow literally everything.
With tokenizer-eval it also adds the constexpr-like ability to macros - allowing lexer-stage evaluation/rewriting of tokens.
Lisp lacks the above or uses convoluted expressions to partially emulate a simple C macro.

Maybe it could have a smaller footprint? That's about it.

Zero-overhead principle: if something is unused it costs nothing. _TokenOf() is like having a extremely compact eval() which feeds back into C preprocessor. The key reason C won its doesn't impose costs before use.

Your insistence on bringing it up reinforces its lack of value.

Its brought up because delusional users of toy language often proudly claim independence from C while using software which depends on it. When Lisp OSes/Games make a comeback you could claim lisp is actually powerful/useful and not a shitty script.
After all the abstract bullshit in Lisp hasn't helped it one bit to compete with any other language.
Where are the Lisp webservers,text/graphics/sound editors, operations systems,games today?

>>67
1) Lisp has full control (ie, controlled by plain Lisp functions) of how characters are converted to tokens, and how tokens are converted or manipulated before hitting the compiler. It is a real programming language manipulating tokens as real data structures, not a bunch of shell-like string hacks. You know nothing of what Lisp is or does, and are making a complete jackass of yourself by attempting to hold little pieces of shit above it.

2) Every Lisp compiler already does constant folding, dead code elmination, and all that. If something is unused, it costs nothing. And in a much better implementation than you'll pull off in preprocessor expansion hacks. Will cpp even have a notion of type inference? (Again, you have no fucking clue what Lisp is or what it does.)

3) If I write something in Pascal, my code has no dependence on C. You are too fucking stupid to understand this concept. Why do I even bother with your fucking willful ignorance, but here we go, for the benefit of others who don't have your mental impairments who might be interested.

There are Forth machines. There are Lisp machines. There are Oberon machines. There are assembly-based embedded machines. None of these have C in their toolchain. They are either bootstrapped from assembly languages or from their own non-C language. I can port the Pascal environment to it, and run my Pascal there. The Pascal defines the execution of my program in only Pascal terms. I can run it on a Pascal compiler/interpreter written in C, written in Assembly, written in Forth, or whatever. I don't care. Windows, Linux, and Mac are chasing after the Unix way, and have planted themselves on C. That is a purely arbitrary decision, and once you're one layer removed from that decision, C is 100% irrelevant. I can write a simple stack machine in any machine language, and high level language functionality is instantly bootstrapped and wide open to me.

The fact that C is somewhere buried in the chain, and generally stays buried there once nicer programming constructs are built on top of it shows that it is a dying language existing only on its own momentum, not any sort of benefit.

Lisp has mature in-use webservers, text editors (duh), graphics/layout editors, not sure about sound editors but I know there are music programs, the Symbolics OS is getting an emulation based comeback with many inspired projects, and Lisp game jams are a thing. Lisp-style languages are growing in popularity, while C is declining. Besides, popularity is politics, money and inertia. Powerful & useful are generally not in the limelight, no matter the industry; the McDonald's products are what's most popular.

And it's not about "abstract bullshit" (another clue that you're fucking clueless about Lisp), it's about productivity, flexibility, and directness of expression. In C you always have to build up a ton of abstract bullshit infrastructure to make anything work, so you're eating bowls of dicks while calling everybody else homo, you clueless shit-spewing hypocrite.

1) Lisp has full control (ie, controlled by plain Lisp functions) of how characters are converted to tokens, and how tokens are converted or manipulated before hitting the compiler. It is a real programming language manipulating tokens as real data structures, not a bunch of shell-like string hacks. You know nothing of what Lisp is or does, and are making a complete jackass of yourself by attempting to hold little pieces of shit above it.
-------
Lisp has macro hygiene and syntax rules. C preprocessor doesn't: its more powerful though unsafe to manipulate "a bunch of shell-like string hacks" and even more powerful with _TokenOf() evaluation.

Will cpp even have a notion of type inference? (Again, you have no fucking clue what Lisp is or what it does.)
------
typeof() and __auto_type (provided by GCC)
https://gcc.gnu.org/onlinedocs/gcc/Typeof.html

As for overloading on typeexpression, its called _Generic(used extensively in void.h) and GCC-specific types_compatible_p https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html (see choose_expr/types_compatible_p example)

3) If I write something in Pascal, my code has no dependence on C.
-----
FreePascal only(its a quite different from enterprisey pascals of the past and cross-platform). They did it by manually adding huge amounts of arch-specific assembler includes. Also, writing Lisp compilers in it would be much harder due pascal BDSM-like rules:you'll be forced to use assembler to workaround it.

There are Forth machines. There are Lisp machines. There are Oberon machines. There are assembly-based embedded machines. None of these have C in their toolchain.
----
And they are niche or legacy products that lost the competition with C-based solutions. If the reverse was true you would be posting on LISP/Forth/Oberon machine.

shows that it is a dying language existing only on its own momentum, not any sort of benefit.

Well, github shows its one of most popular languages. Millions of lines in it are written daily. Pretty strong "momentum" for a dead language.

Lisp-style languages are growing in popularity, while C is declining.
----
Lisp-like? Does this means JavaScript/Scala? Does Java itself(got lambdas recently) and C++(C++11/14 added lots of functional stuff) fit the defintion?
Could you list github repositories in Lisp or Scheme(only Lisp/Scheme not JavaScript),instead of spewing meaningless claims?

Besides, popularity is politics, money and inertia.

Are you backpedaling on Lisp popularity?

And it's not about "abstract bullshit" (another clue that you're fucking clueless about Lisp), it's about productivity, flexibility, and directness of expression.

Abstract bullshit violates Zero-Overhead principles by costing performance/memory without explicit benefit to programmer:its already understood by JavaScript community and been key to improving performance while preserving productivity, unlike Lisp where performance is seen as secondary and productivity is hampered by crippled syntax(ironically slower and less expressive than JavaScript).

Lisp has macro hygiene and syntax rules.

No it doesn't, you fuck.

typeof() and __auto_type (provided by GCC)

HAHAHAHAHAHAH, eat a didk, and learn what the fuck a compiler does, you little baby. Why the fuck are you even here if you don't even know the basic shit that's even inside your beloved C compiler?

FreePascal only(its a quite different from enterprisey pascals of the past and cross-platform).

I'm talking about the goddamn language, you fuck. You have no fucking clue about anything.

If the reverse was true you would be posting on LISP/Forth/Oberon machine.

The common platforms have been commodotized. I do use virtualizations of those machines which give me a full capable environment which can ignore the rest. You fuck.

Pretty strong "momentum" for a dead language.

I didn't say "dead" you fuck, I said it's dying. Now you're just waffling trying to defend yourself.

Lisp-like?

Clojure is the biggest "core" Lisp rising in the actual job market. Ever wonder about those languages, including C++, that are constantly playing catch-up on ancient Lisp features? Do you think that means anything you piece of shit?

Are you backpedaling on Lisp popularity?

I never said it is popular, you fuck. Stop twatwaffling. However, it was king of the hill back in the Lisp machine days, and leading up to it (which is why there was a commercial market for Lisp machines in the first place).

Abstract bullshit violates Zero-Overhead principles by costing performance/memory without explicit benefit to programmer:its already understood by JavaScript community and been key to improving performance while preserving productivity, unlike Lisp where performance is seen as secondary and productivity is hampered by crippled syntax(ironically slower and less expressive than JavaScript).

This is a quote for the ages. Never has somebody tried to talk so authoritatively about language technology, while being so demonstrably ignorant about everything within it.

You don't even know what "abstract bullshit" is or what it does. Lisp is one of the fastest languages on the planet. Even JavaScript is as fast as C nowadays in terms of the inner loop numeric processing, which is all that C fucks ever measure (because in anything regarding dynamic behavior C will fall on its fucking face as everybody blows past it).

unlike Lisp where performance is seen as secondary and productivity is hampered by crippled syntax(ironically slower and less expressive than JavaScript

It's clearly established that you know absolutely zero about the language and are still spewing falsehoods like you think you have any clue to do so.

Seriously, you really need to kill yourself. You are a worthless human being. Your brain has stopped functioning decades ago, if you're even that old. If you're a kid who's just learning this stuff (because clearly you don't even know C compilers, let alone Lisp), kill yourself anyway for being such a little fuck online.

I did C for a decade, and Lisp for about the same. You've dabbled in C and don't know jack shit about Lisp. Why the fuck are you even in this conversation? Die.

You know what, here's a challenge regarding syntax and macros, since you obviously can't read, learn, or state anything sensible in actual conversation:

Make compile-time roman numeral literals in C.

Prefix them with some single escape character for clarity. Say int i = `MCLI; should work to set i to 1151. To make it more straightforward, just use additive order-independent numerals, so `ILCM would still be 1151.

Lisp can certainly do that easily with its reader macros. How about C? How about even C with the hypothetical extensions you say are more powerful than Lisp?

_{(fuck, I meant preprocessor-time, not compile-time. I'd be curious to see either, but kudos only to the former.)}

Lisp has macro hygiene and syntax rules.

No it doesn't, you fuck.
-------
Apparently it does since translating simple C macros is
let me quote "Regarding that C macro, I'm not even going to bother trying to parse that garble. At first glace, though, I will say it's generally bad form for macros to blindly insert local variable names into whatever it's generating, partially because in Lisp they're not just strings but symbols (which are interned & namespaced, and the macro & usage can be in different namespaces). The first step in converting it to Lisp would be to untangle that mess into a more sane expression."

typeof() and __auto_type (provided by GCC)

HAHAHAHAHAHAH, eat a didk, and learn what the fuck a compiler does, you little baby. Why the fuck are you even here if you don't even know the basic shit that's even inside your beloved C compiler?
-----
It replaces type-inference along with _Generic(replaces C++ ADL type-to-function resolution). Its not a perfect solution(C++ auto/decltype(auto)/decltype provide a cleaner syntax) but it works.

FreePascal only(its a quite different from enterprisey pascals of the past and cross-platform).

I'm talking about the goddamn language, you fuck. You have no fucking clue about anything.
-----
No other Pascal dialect is C/C++ independent.

If the reverse was true you would be posting on LISP/Forth/Oberon machine.

The common platforms have been commodotized. I do use virtualizations of those machines which give me a full capable environment which can ignore the rest. You fuck.
-----
Only in a contrived, virtual environment written in C/C++/asm.

Pretty strong "momentum" for a dead language.

I didn't say "dead" you fuck, I said it's dying. Now you're just waffling trying to defend yourself.
-------
it patently obvious C and C++ have no signs of dying or being replaced.

Lisp-like?

Clojure is the biggest "core" Lisp rising in the actual job market. Ever wonder about those languages, including C++, that are constantly playing catch-up on ancient Lisp features?
-----
Clojure seems popular, but i don't see any serious project in it and its Java-based. Could you link a few repositories?


Are you backpedaling on Lisp popularity?

I never said it is popular, you fuck. Stop twatwaffling.
---------------
>>68
"Lisp has mature in-use webservers, text editors (duh), graphics/layout editors, not sure about sound editors but I know there are music programs, the Symbolics OS is getting an emulation based comeback with many inspired projects, and Lisp game jams are a thing. Lisp-style languages are growing in popularity, while C is declining"

However, it was king of the hill back in the Lisp machine days, and leading up to it (which is why there was a commercial market for Lisp machines in the first place).
----
This era is gone. Being attached to it is akin to longing for vinyl records because of their "superior sound".

Abstract bullshit violates Zero-Overhead principles by costing performance/memory without explicit benefit to programmer:its already understood by JavaScript community and been key to improving performance while preserving productivity, unlike Lisp where performance is seen as secondary and productivity is hampered by crippled syntax(ironically slower and less expressive than JavaScript).

Never has somebody tried to talk so authoritatively about language technology, while being so demonstrably ignorant about everything within it.
-----
I don't need to be a chef to comment on taste of food.

You don't even know what "abstract bullshit" is or what it does. Lisp is one of the fastest languages on the planet. [delusional rants follow]
--------
Apparently while "one of the fastest languages" its losing all benchmarks and speed comparisons, which incidentally only use the C-like subset of Lisp, not idiomatic Lisp code(which would be at the end).
https://benchmarksgame.alioth.debian.org
The only Lisp compiler that approaches C performance is Stalin scheme, which implements only a subset of Scheme/Lisp. Being delusional about Lisp superiority doesn't change the facts on the ground: the only way to get a decent performance out of Lisp(and by extension any project written in lisp-like dialect) is to use minimal abstraction: essentially C/C++ code with Lisp overhead.

>>71

Make compile-time roman numeral literals in C.

There is no need to use _TokenOf()

#define I +1
#define II +2
#define III +3
#define IV +4
#define V +5
#define IX +9
#define X +10
#define XL +40
#define L +50
#define XC +90
#define C +100
#define D +500
#define M +1000
int i= M C L I;

>>74
That's not MCLI as a single token representing a number, as per the challenge. That's 4 tokens. Fail.

Come on, introduce actual new syntax with your shitty little preprocessor.

Do you even read English? Does using one word vs another even mean anything to you? You can't even respond to what I say.

mangled C macro

Totally doable in Lisp, and I explained the process to getting there. Desire for behavior → C fucks it up with weak-ass preprocessor shit → Unfuck it back to behavior → Nice Lisp macro that isn't a shit hack but does the same thing better. If I took the time to unmangle it, I would likely follow the same idioms in Lisp.

Fuck, I can implement the whole fucking C preprocessor in Lisp's macro system, just to shut you the fuck up about your shitty weak string masher.

No other Pascal dialect is C/C++ independent.

Pascal is a language that is not dependent on C, which is a completely different language, as you don't seem to know the distinction. Which part of the Pascal language depends on the C langauge? Be clear and specific, you laughably stupid piece of shit, or shut the fuck up and kill yourself.

Only in a contrived, virtual environment written in C/C++/asm.

Lisp takes my Lisp and converts it to machine code. You're contriving C into the picture because you're a desparate loser who can't admit that the old shit you've never learned past is being laughed at.

it patently obvious C and C++ have no signs of dying or being replaced.

Who even teaches C anymore in universities? Not that Java doesn't suck, but it's at the very least left common CS curriculum. Such is the way to becoming the next Cobol.

[popularity]

I know you can't read, but "is popular" ≠ "growing in popularity" anyway.

The era is gone

Again, because top popularity is driven by money, politics, and momentum. Which speaks nothing about the power, flexibility, ease of use, and speed of a language.

I don't need to be a chef to comment on taste of food.

You've never even tasted Lisp enough to make a determination. Reading between the lines, it's like you think it's still interpreted or something.

It's not fast

What the fuck are you smoking? Even just looking at the very first benchmark:

C:
secs N KB gz cpu cpu load
binary-trees 0.09 12 ? 706 0.07 0% 30% 80% 0%
binary-trees 1.61 16 9,492 706 1.60 100% 1% 2% 1%
binary-trees 37.71 20 132,384 706 37.68

Lisp:
secs N KB gz cpu cpu load
binary-trees 0.07 12 ? 612 0.06 100% 0% 0% 0%
binary-trees 1.36 16 77,168 612 1.35 1% 1% 1% 100%
binary-trees 32.77 20 325,092 612 32.71

Going down the line, Lisp takes the advantage often enough. Certainly it's competitive with C, thus "one of the fastest languages" would be apt for that competitiveness.

But this doesn't even begin to describe the speed advantages in the "real world", with large-scale programs where it actually counts. C gets slow when you use it in real systems, because it needs to dispatch, change runtime behavior based on user scripts/config/data, track shit that it doesn't know the lifetime of. Pull it into real world large scale and your C code is buggier, slower at runtime, and harder to write than Lisp, while dynamic runtimes eat those problems for breakfast.

Now, show me some fucking working roman numerals.

>>75

single token representing a number

It works anyway. Welcome to C.

introduce actual new syntax

There is no need since the C syntax isn't crippled enough.
You can do all things in void.h without any lisp, but you can't apply void.h to lisp because it would add Lisp overhead and produce the same result as C code.

Pascal is a language that is not dependent on C, which is a completely different language, as you don't seem to know the distinction.

Pascal as in abstractly delusional design document does not actually depend on C.
Pascal as implemented in real-world software does.
You could say Lisp doesn't depend on assembler(as language spec) but in reality it does(unless you evaluate lisp on paper).

who can't admit that the old shit you've never learned past is being laughed at.

In reality you're the one being laughed at, since you deny reality of using C/C++ software in your toy language by pretending it doesn't exist.

>>77
Fuck off, then. You know the preprocessor is shit, and the hacks people are doing with it are just playing with it for fun.

>>78
So Pascal written for, say, retro home computers that didn't run C doesn't exist. Or Symbolics Pascal that didn't involve C doesn't exist. Uh huh. I know your mind is warped to be C centric, because you're incapable of gaining skills being the most basic of Lego bricks, but the world is bigger than that.

I know you're probably going to type more, but as you can't pull your head out of C's ass for one second to discuss actual programming, and refuse to actually show me something with macros, you're not worth the replies.

Fuck off, and go piss about with your portable assembler.