Hacker News Reader

Comment by scrame | Hacker News Reader

Nice article; short, sweet and enough to pique my curiosity about modern assembly.

Some aphorisms like "C has the efficiency and speed of assembler, with the portability and readability of assembler" come to mind, but those are from ancient history in programming years, and usually said by people proficient in both.

There are other assertions (like jwz in the 'Java Sucks' rant), that refer to C as "a PDP-11 assembler that thinks its a language", but again an exaggerated statement made by someone who knows.

I have not met anyone who primarily codes in an interpreted language who think that C is just syntactic sugar for assembly. Maybe because most of them don't program in C.

I can certainly see some amateur programming pundits (or maybe just forum dickheads) regurgitating the lines without understanding them, but there is a world of difference between the examples touched on, and the actual syntactic sugar of recent java releases (generics, unboxing).

View on HN

It's not too much of a stretch to look at just 'C' as a very sophisticated macro assembler.

And probably you should strip out the 'macro' bit there because in reality that's the pre-processor doing it's work and even though there isn't a C compiler without a pre-processor technically speaking it is not part of the compiler since all it does is output more C.

"And probably you should strip out the 'macro' bit there because in reality that's the pre-processor"

I disagree. Looping constructs that typically would be macros in an assembler such as 'while' and 'for' are C constructs. Also, C itself has automatic field offset computations.

>>automatic field offset computations

A macro for subroutine entry could reserve stack space and define offset constants. A macro for subroutine returning releases the extra space.

It could be neat to use, if the processor architecture has sane addressing modes. (I might have seen/done something similar... doesn't feel like a new idea to me. :-) )

(The entry macro might need a simple preprocessor.)

Disclaimer: C and lower was another life, dimly remembered. :-)

It's not too much of a stretch to look at just ' FIXME' as a very sophisticated macro assembler.

s/FIXME/Ruby, or Python, or Perl, or any other language. Where does one draw the line that distinguishes a language from a sophisticated enough assembler?

Those are interpreters, not compilers.

If you're not comfortable with interpreted languages, substitute for Java, C++ or other compiled languages. My question still stands for itself.

No it doesn't.

In java any kind of minimal assignment can explode behind the scenes into a a whole pile of function calls, that would never happen in C, what you see is what you get.

It's interesting to compare the real difference here. In C, what you see at compile-time is what you get. As compared to an interpreted language where what you see at compile-time is probably going to be completely different from what happens at runtime. The difference is really where the optimizations occur. Runtime optimizations have certainly come a long way.

jasonwatkinspdx and hackermom have explained why your statement is highly inaccurate.

Reply on news.ycombinator.com