Live data from Hacker News

C, The Beautiful Language

tenaciousc.com

81–85 of 85 posts

Re: C, The Beautiful Language

#81
post #78
post #73

Earlier quoted context omitted.

Indeed, you are right about Scheme (and Arc). Thanks for the correction.

Sure, no problem. I guess Emacs Lisp falls under the old-and-broken category. And Picolisp eschews functions as a data-type by choice. Do you know whether Picolisp offers lexical scoping?

As the other response says. The FAQ provides some rationale & makes it clear you can, actually, build robust software with picolisp's model of scoping. My understanding is, ``dynamic scoping is faster for an interpreter'' and ``funarg is easy to avoid and closures are possible''.

See the three following points:

http://www.software-lab.de/doc/faq.html#dynamic

http://www.software-lab.de/doc/faq.html#problems

http://www.software-lab.de/doc/faq.html#closures

Re: C, The Beautiful Language

#82
post #80
post #53

Earlier quoted context omitted.

C is the language some may love to hate, but an experienced developer will create clean, concise code. I remember reading through cifsd [1] by cinap_lenrek and thinking, ``my god, this is beautiful''. No boilerplate, just straightforward code. And yes, unobtrusive error handling. Also, a blogpost post comes to my mind: ``A Timeless, Desert Island Language'': `And that's why I'd choose C as my desert island language.…

> ... I can bootstrap a basic Lisp interpreter That sounds like an argument for any language, though. As long as you can build the language of your choice in language X, you're fine being stuck with X because you're not really stuck. If they had to write absolutely everything in more "pure" C, would their tune be the same? I think C is a fine language, but it's missing some significant niceties. Like a decent native…

> That sounds like an argument for any language, though.

Not really. Unless the language gives you access to the computer (either directly, or by emitting machine code and scheduling for execution), you'll have hard time implementing it efficiently. Compare IronPython (python implemented in python) with the mainline Python (implemented in C).

Yes, there are meta-circular interpreters. But that's not the holy graal.

> I think C is a fine language, but it's missing some significant niceties. Like a decent native string class.

C++ is what happens when you sprinkle a few niceties here and there. The C++ Faq Lite [1] is longer than the whole C specs. The kitchen sink language can do everything, but porting it to a new environment is quite a task. Never mind the compilation time.

You can get an optimizing C compiler [2] in less characters than C++ Faq Lite has.

If you want modernized C with niceties, (Google's) Go probably comes close enough. No string class, thou, just string type.

--

[1] http://www.parashift.com/c++-faq-lite/

[2] http://gsoc.cat-v.org/projects/kencc/

Re: C, The Beautiful Language

#83
post #82
post #80

Earlier quoted context omitted.

> ... I can bootstrap a basic Lisp interpreter That sounds like an argument for any language, though. As long as you can build the language of your choice in language X, you're fine being stuck with X because you're not really stuck. If they had to write absolutely everything in more "pure" C, would their tune be the same? I think C is a fine language, but it's missing some significant niceties. Like a decent native…

> That sounds like an argument for any language, though. Not really. Unless the language gives you access to the computer (either directly, or by emitting machine code and scheduling for execution), you'll have hard time implementing it efficiently. Compare IronPython (python implemented in python) with the mainline Python (implemented in C). Yes, there are meta-circular interpreters. But that's not the holy graal. >…

>Not really. Unless the language gives you access to the computer (either directly, or by emitting machine code and scheduling for execution), you'll have hard time implementing it efficiently.

Why not use Ruby to emit a bunch of bytes (ie, assembly), push it into a file, and set the executable bit? Ruby could be used to create GCC so you can write C. ie, a Ruby-based Ruby-to-assembly compiler. With that technique and therefore technically Ruby alone, you're still capable of recreating every language or application in existence, right down to being exact binary duplicates.

Sure it's pedantry. But the entire hypothetical deserted-forever-with-one-language situation is pedantic at its core.

Re: C, The Beautiful Language

#84
post #49
post #22

All it means is that he understands C better than other languages. Even Java (yes, Java) has these rhythms that he speaks of. You look at code and you feel the logic, even the necessity of it. That's just the feeling of being in tune with code and with the person who created it, thanks to a shared understanding of the language. Master any language and you'll get the same feeling when you read well-written code. Actua…

+1 C is ugly. - Why do I need to typedef a struct to make it look like any other type? - Why do function pointers look so bad? - Error handling in C? Those goto exception; if(0){exception:} sure look fantastic. - int* var1, var2; var2 is an int, not an int* ... The language lets you stick the * right next to the type as though it modifies the type. Which it does in casts. (how do I escape asterisks on here?) - A syst…

C's designers agree with you about the notation for types and declarations, which was one of the things they fixed when they designed Go.

Re: C, The Beautiful Language

#85
post #53
post #22

All it means is that he understands C better than other languages. Even Java (yes, Java) has these rhythms that he speaks of. You look at code and you feel the logic, even the necessity of it. That's just the feeling of being in tune with code and with the person who created it, thanks to a shared understanding of the language. Master any language and you'll get the same feeling when you read well-written code. Actua…

C is the language some may love to hate, but an experienced developer will create clean, concise code. I remember reading through cifsd [1] by cinap_lenrek and thinking, ``my god, this is beautiful''. No boilerplate, just straightforward code. And yes, unobtrusive error handling. Also, a blogpost post comes to my mind: ``A Timeless, Desert Island Language'': `And that's why I'd choose C as my desert island language.…

My basic Lisp interpreter was six pages of C, but it's really not usable; it responds to almost any program error (including searching for nonexistent variables) by dumping core. http://lists.canonical.org/pipermail/kragen-hacks/2007-Septe...

Darius Bacon's https://github.com/darius/ichbins is a Lisp-to-C compiler written in itself. It includes an interpreter written in C to bootstrap it — ten pages: https://github.com/darius/ichbins/blob/master/boot-terp/lump... — but the actual compiler is only six pages of Lisp.

My somewhat more performant (but less complete) Scheme-subset-to-assembly compiler is more like 30 pages: http://www.canonical.org/~kragen/sw/urscheme/

If your desert-island language is the one in which bootstrapping your high-level language of choice is the easiest, it seems like you'd probably be better off with Haskell or ML.

Post reply on HN