7 ms·
K&R C has a beautiful, elegant simplicity to it, which later ANSI C has lost --- the idea that everything is a machine word unless specified otherwise means tha
by david-given 11y ago
K&R C has a beautiful, elegant simplicity to it, which later ANSI C has lost --- the idea that everything is a machine word unless specified otherwise means that you get to do things like this:
add(a, b) { return a+b; }
fib(a) { return (a <= 1) ? 1 : (fib(a-1) + fib(a-2)); }
That's totally valid K&R C. The lack of boilerplate makes abstraction really cheap, conceptually --- Forth programmers will recognise the advantage here. You can write real programs out of tiny one-line definitions like the above.
Of course, ANSI C is better in just about every other way, but I still regret losing the stripped-down simplicity of K&R C.
- Xophmeister 11y ago> fib(a) { return (a <= 1) ? 1 : (fib(a-1) + fib(a-2); } > > That's totally valid K&R C. Apart from, presumably, the missing closing parenthesis ;)
- david-given 11y ago* cough * Fixed. Thanks.
- mhd 11y agoEver seen C code by APL programmers?
- srpeck 11y agoThese came to mind: http://kx.com/q/c/c/k.h http://kx.com/q/c/c/k.h http://kx.com/q/c/c/c.c http://kx.com/q/c/c/c.c http://www.jsoftware.com/jwiki/Essays/Incunabulum http://www.jsoftware.com/jwiki/Essays/Incunabulum
- agumonkey 11y agoThere could be a movie about the steps needed to reach that state. ps: I have some javascript bits that are almost as dense... Hum.
- kbenson 11y agoI wouldn't call that C code, I would call that a language defined by the C macro system that also happens to accept C code if you choose to sprinkle that in.
- pcwalton 11y ago> The lack of boilerplate makes abstraction really cheap, conceptually Well, as long as you don't care about abstracting over anything other than int.
- rootbear 11y agoANSI C could be cleaner than it is. I regularly lament that I must type int func(long_type_name a, long_type_name b, long_type_name c) { ... when I really, really should be able to type int func(long_type_name a, b, c) { ... It would be nice to get this back and it would take away some useless noise. Sadly, this is now seen as a feature and languages like D insist on the repeated type name. I'm sure there are other places were ANSI C could be made cleaner, but perhaps at the cost of backwards compatibility.
- sampo 11y ago> int func(long_type_name a, long_type_name b, long_type_name c) { ... The K&R style variable declarations are still also part of ANSI C, so you could write: int func(a, b, c) long_type_name a, b, c; { ...
- rootbear 11y agoI don't now about the later versions of the standard but in C89, using the old style meant you did NOT get the type checking of the prototype style declarations. If there is no semantic difference these days, then yes, that would be a solution. I'm on the road and don't have the C11 standard handy, so I'll check later what the deal is.
- kazinator 11y ago> get this back That never existed. Syntactically it could work; you would need semicolons in there: int func(long_type_name a, b, c; int d); similar to struct/enum member declarations. Speaking of which: don't have long type names in C programs, and simplify API's with structs rather than large numbers of parameters. :)
- userbinator 11y agoIt is actually valid in ANSI C89 too, although it does look rather odd to those accustomed to seeing the types. http://stackoverflow.com/questions/5885156/no-defined-type-of-a-function-parameter-defaults-to-int-am-i-insane http://stackoverflow.com/questions/5885156/no-defined-type-o...
- ben0x539 11y agoSounds like you might enjoy Haskell or similar :P