C, The Beautiful Language
tenaciousc.com
C, The Beautiful Language
1–10 of 85 posts
Re: C, The Beautiful Language
#2C is more a description of a Harvard machine than a von Neumann machine. In fact, a useful new language feature would be dynamic generation of machine code.
Re: C, The Beautiful Language
#3Nice!
Re: C, The Beautiful Language
#4>In other languages, the abstractions and sweet (if helpful) syntactic sugar that attend the code conceal the heartbeat.
IMO, that means they're failed abstractions and syntactic sugar. Proper ones should result in better understanding due to simplification - you can learn it in levels, easily encapsulating the knowledge at each level so you know you can "trust" what it's doing without having to remember all of it.
Re: C, The Beautiful Language
#5C is more a description of a Harvard machine than a von Neumann machine. In fact, a useful new language feature would be dynamic generation of machine code.
Of course this isn't a feature of the language -- but most implementations (e.g. gcc) technically allow this, if you really, really know what you're doing. For example:
http://www.cesarbs.org/blog/2010/07/19/run-time-machine-code...
Re: C, The Beautiful Language
#6> we watch Ronaldo doing things on the pitch
Hmmm...
Lionel Messi does crazy things you never thought were possible. He's Lisp.
Gareth Bale has few fancy tricks, but does what he does very well, and often relies on pure speed - C.
Joey Barton is good, but has a bad reputation and a sordid history - Fortran?
Etc :-)
Re: C, The Beautiful Language
#7> In other languages, the abstractions and sweet (if helpful) syntactic sugar that attend the code conceal the heartbeat. IMO, that means they're failed abstractions and syntactic sugar. Proper ones should result in better understanding due to simplification - you can learn it in levels, easily encapsulating the knowledge at each level so you know you can "trust" what it's doing without having to remember all of it.
As such, any abstraction or syntactic sugar that distances you from the flow of the program fail.
Bu that's for programs that are procedural. Functional programming has no flow. Truth neither moves nor changes.
To use an analogy, a procedural program is like music, where rhythm and motion of the instrument are the essence of what you are representing. Functional programming is more like sculpture, where you create an elaborate piece that has no rhythm or movement of itself, but guides the flow and transformation of the data around it.
Re: C, The Beautiful Language
#8In my experience it is more 'fun' to write C code then to lay down yet another line of boiler-plate high level code. However, it seems to take longer to get things done and the resulting code is also much more error-prone (at least my code that is).
Re: C, The Beautiful Language
#9This is a nicely written tribute, but there are two generalisations that I feel are worth pointing out.
Many parts of Linux kernel are really, really nice C code. Sadly, in my experience most C code is not especially nice. I don't know how this extends to the football metaphor, but certainly I wish most of the C code I have encountered (not to mention written) in my career to date was one tenth as neat.
On balance, I'd say there are other languages (Erlang, Python) where I've personally found the median quality, and level of expression, to be substantially higher (for the random subset of code I've read and my own standards, clearly YMMV.)
The other generalisation is "other languages". Which "other languages" are they? What other projects (despite the Linux kernel) are they reading, and in what contexts?
You can find beautiful or precise code is almost any language if you try hard enough. You can find ugly or obfusticated code in nearly every language without barely trying at all.
Re: C, The Beautiful Language
#10C is more a description of a Harvard machine than a von Neumann machine. In fact, a useful new language feature would be dynamic generation of machine code.
Of course this isn't a feature of the language -- but most implementations (e.g. gcc) technically allow this, if you really, really know what you're doing. For example: http://www.cesarbs.org/blog/2010/07/19/run-time-machine-code...
Yes, you can generate machine code yourself, but then you have to write machine code ...
I'm suggesting a JIT compiler as a built-in language feature so that you could write code in a high-level language and have machine code generated that was specialized based on the program's dynamic state.
It could be done as a library, but it would benefit from language integration so that you wouldn't have to write the code as strings or ASTs.