[eggy]

Great quote. I had never read that one. The irony of language wars about the monolith that is C vs. the many higher-level languages that allow a human to code according to his mental abstractions and cognitive ability, rather than memorizing machine-specific, or os-specific facts that don't translate over to newer machine architectures. All this on HN, running on a Lisp, Arc, that once sat upon an academic scheme now called Racket.

I agree C is necessary for low-level programming, but for the meat of all the other applications and usages, higher-level languages are needed. I don't mind programming certain things in C, but I thoroughly enjoy the mental exercise when programming in the J programming language, Lisp, or Forth. Yes, Forth. C programmers can have the Earth; I would like to be coding with the fellas who design mission-critical software for satellites like Rosetta, and groups like NASA and the ESA, using Forth in Rosetta's case [1].

Slim Whitman sold more records than the Beatles, or so I think I heard that on a late-night TV commercial back in the 80s, but I never owned a record from him ;)

  [1]  http://adsabs.harvard.edu/full/2003ESASP.532E..72B

[tbirdz]

This is a bit off topic, but would you mind sharing what resources you used to learn forth? I'm interested in the language myself, but I don't really get how to use it. I've learned the basics about defining words and manipulating the stack, but whenever I try to apply it to an actual problem, I have a very hard time even understanding how to approach, wheras if I were using a procedural or OO language, I would know where to start.

Any advice on getting over this hump?

[eggy]

There are the main books everyone refers to like 'Thinking Forth' [1], and others, but I really learned faster by picking up Factor [2] and Retro [3]. The community on Factor is very helpful and smart. I actually wrote my first real Forth program for work in Factor. I had written a lot of one-liners, and some curiosities, but this was a business need met in one night. It was basically a program to munge a whole lot of tab-delimted text files, and do some math on fields and then generate a report. It was all < 100 LOC, and it was easy to interactively test if I was missing anything in the interpreter. Retro is cool, since it is so minimal, and there are add-ons for Chrome so you can run it in your browser locally to try it; otherwise, you download the image file for your platform, and Retro itself. Retro was built on a VM called Ngaro, which is an interesting diversion, but not Forth. There are also microcontroller ports of Forth [4], which I found a lot easier than using the assembler for a particular microcontroller. FlashForth has been recently updated, and is featured in a 'Circuit Cellar' magazine article. I have also purchased iForth [5], since I had stopped dual-booting linux at the time, and it offered a lot for Windows, and mathematics (fast). I hope these help you get started. If you are a maker, using an Arduino or PIC-like chip with FlashForth is great. The whole dictionary, or word list (all the defined functions called 'words' in Forth, are listed in the reference I provided). In Forth, you can easily add to the dictionary, it is concise enough to know your whole system in a short time, and add to it when you need it. Good luck!

  [1]  http://thinking-forth.sourceforge.net/ 
  [2]  https://factorcode.org/
  [3]  http://forthworks.com/retro/
  [4]  http://flashforth.com/tutorials.html
  [5]  http://home.iae.nl/users/mhx/

[tbirdz]

Thanks for the reply. Those look like some pretty cool resources, and I can't wait to check them out.

[groovy2shoes]

> I agree C is necessary for low-level programming, but for the meat of all the other applications and usages, higher-level languages are needed.

I actually disagree with this for the most part.

C's main advantage as a systems language is its ubiquity -- virtually every platform released in at least the last 25 years has had a reliable C compiler available. Before JavaScript hit it big with Web 2.0, C was a lingua franca among programmers. Starting in the late 80s and continuing throughout much of the 90s, pretty much every textbook that had used Pascal or Pidgin Algol for code listings was edited to contain code listings in C instead.

Of course, as Java gained momentum in the education space in the late 90s and early 00s, many were again updated for code listings in Java. Although a great deal of computer science curricula now crowd around Java, most of them also have at least one required course either on C or that makes good use of C (my own track at NC State contained, beyond the introductory Java courses, "C & Software Tools", "Operating Systems", and "Computer Graphics", all in C).

That all being said, there were historically quite a few systems languages that were better than C in almost every way[1]: they were (typically both memory- and type-) safe, they were higher level in the sense that they offered more and better tools for abstraction (and were therefore considerably more expressive), they offered more opportunities for automatic optimization, they were easier to port to new platforms, many of them were easier to read and had far fewer nuances/"gotchas"/"footguns" than C, the languages themselves were designed in such a way that better tooling was possible, the list goes on and on. The one thing that C had on them was that it was already default. Programmers could (and can) count on the target platform having a C compiler. C programs have access to the wide assortment of C libraries. C was good enough. In a sense, C's popularity was and is perpetuated by the fact that it's the path of least resistance. Once C managed to get into that position, of course it became the "king of systems languages".

I think C's days are numbered. There was a time when systems programming was how you went about learning to program professionally on microcomputers. (Unstructured) BASIC was popular among hobbyists but right-out for professional programs due to abysmal performance. So, you learned assembly/machine language, or, if you were lucky, Turbo Pascal, a similar-in-spirit C system, or QuickBASIC (a compiled, structured language that I'd actually classify as a systems language, given that its feature set is mostly isomorphic to C's). Nothing else offered the level of performance you needed for commercial applications. This continued from the mid 80s through to the early 00s, yielding several generations of programmers who were systems programmers by training.

But things are different now: most programmers nowadays are cutting their teeth on high-level languages like JavaScript, Ruby, Python, Lua, etc., and if they become systems programmers it's due to their own desires and interests rather than out of any real necessity. These programmers know better, and are in an excellent position to notice the many shortcomings of C, and some even outright reject it due to its gnarliness in comparison with the high-level languages they're accustomed to. They know, deep down in their bones, that systems programming doesn't have to be so unsafe, so intricate, so field-of-landmine-ish, so... shitty. And some of them intend to do something about it.

I think we're already seeing the results of this: languages like Rust, Nim, and Myrddin strike me as products of these happenings. And now, I think, is a good time for it, because C's ubiquity has never been less relevant since its rise to power: there's only a handful of platforms anyone needs to support nowadays (POSIX and Windows, desktop and mobile; you can count OS X/iOS as a separate platform if you're feeling squirrely, but even then you haven't reached an unattainable set of targets, and it seems as if soon you may be able to strike Windows from the list as well); if you offer ABI compatibility with C, you get libraries for free; parsing is practically a solved problem; .... And then there's the LLVM, which can handle roughly a third of the compilation process for you -- and it's the backend: the hardest part!

I imagine that within another 20 years to 30 years, C will be hiding within its final strongholds of legacy code and embedded programs. Outside the embedded space, new projects in C will be exceedingly rare, and another decade or two after that will see even the embedded programmers breathing a collective sigh of relief as they become gradually liberated from the tyranny of C.

Only time will tell if the newcomers can usurp C's throne, but I have my fingers crossed. When C gasps its last breath, I will say "good riddance", and happily return to my safe, expressive, pleasant systems language, whatever that may happen to be at that time.

[1]: Just to name a few: Algol 60, Modula-2, Oberon, Ada, Modula-3(one of my personal favorites), ATS, even several non-standard dialects of Pascal such as the ones from UCSD, Apple, and Borland. Then, of course, there are the newcomers: Clay, Rust, Go, D, (does Nim count?), Myrddin (definitely one to keep an eye on), even some dialect(s) of C# were used at Microsoft Research for systems programming. I'd also be remiss not to mention PreScheme (another one of my favorites), used by Jonathan Rees and Richard Kelsey to implement the Scheme48 virtual machine, and its nephew RPython, used for implementing the PyPy JIT framework. I'm sure there are quite a few I'm leaving out, but these are the ones that come to mind at the moment (also, do keep in mind that I'm restricting this to systems languages that are strictly better than C, so some otherwise neat ones like BCPL and BLISS have been intentionally omitted).

[eggy]

Great summary. I especially like your point about the programmers migrating to systems programming having a different mindset than an older person like me, who started with assembly. Thanks for that.

Not sure if by 'disagree with this' you mean the whole piece, or just the quoted sentence. Addressing the obvious quoted sentence:

Don't get me wrong, I like C. I am currently writing a Lisp in C, playing with ImGui and Nuklear immediate-mode GUI kits. That is why I used the word 'needed' vs. something like 'are majorly used'. C pulled me from my Vic-20 6502 assembly language days (I lie, I had moved to Basic before C!). When I program in a higher-level language (Lisp/Scheme, Python, Julia), I find I am dealing with what I actually want to get done, and in the end my programs are not AAA games, or large deep learning neural networks, so they are plenty fast for my needs. I start out clearly with an objective in C, but usually get mired in some C-specific, non-goal-related task, whether I need to refresh my knowledge of pointers, or platform-specific idiosyncrasies. I certainly would choose C over Java any day, or move to another higher-level language. I think Java's VM is a fantastic piece of work, and Java syntax is very C-like, but I'd rather not use it. I use a lot of programs written it though! I prefer Lisp/Scheme, and compiled SBCL is fast. And now with the opensourcing of Chez Scheme, I will be busy this next week. The Spring 2016 Lisp Game Jam is starting in about 24 hours [1].

  [1]  https://itch.io/jam/spring-2016-lisp-game-jam

[groovy2shoes]

I had spent 50 minutes or so writing a reply to this Thursday morning, and was nearly finished when I must’ve accidentally hit F5 or something and lost it all. It went more or less like this:

> Great summary.

Thanks!

> Not sure if by ’disagree with this’ you mean the whole piece, or just the quoted sentence.

Just the quoted sentence, though it does make two assertions: 1) that C is necessary for low-level programming; and 2) that higher-level languages are necessary for all other applications. My previous comment focused primarily on the first one, but I disagree with both. One only need look at the sheer number of applications written in C [1] to see that C is suitable for applications outside of the “low-level” realm.

> I especially like your point about the programmers migrating to systems programming having a different mindset than an older person like me, who started with assembly.

We’re in a similar boat, I think. I cut my teeth on QuickBASIC, quickly picking up some 8086 assembly to get some fancy-schmancy VGA graphics and some SoundBlaster goodness. After around two years, I got my hands on Turbo C 2.0 and never looked back. Although I now prefer higher-level languages, I’m a systems programmer at heart, and that affects how I approach the art and the act of programming. I have a hunch that many programmers “suffer” from the same affliction: that however they learned the ropes still affects their approach to programming in some way; and that’s the thought that underlies my suspicion that we’re about to see a “systems programming renaissance” of sorts.

> Don’t get me wrong, I like C.

Don’t get me wrong, either. I also like C. But it’s also just not a good language. Even at the systems level, there are so many better alternatives. I don’t know if it’s familiarity (most of the lines of code I write are in C), nostalgia (C was one of the first languages I learned), laziness (C’s ubiquity makes it pretty convenient), tradition (these days I’m a UNIX™ guy through-and-through), some combination, or something else entirely. I’ve also noticed that many C programmers have an attitude of “if you don’t know all the ins-and-outs, nuances, footguns, hazards, dark corners, unspecified and implementation-dependent behaviors, and compiler optimizations, then you’re stupid and a bad programmer and you should feel bad” — so maybe it’s narcissistic elitism…

> I am currently writing a Lisp in C, …

Care to elaborate? Is it a naïve interpreter, bytecode compiler & VM, native code compiler, …? Is it an existing dialect or one of your own design? Is there anything about it that you feel is distinctive? Anything you feel particularly proud of?

I’m working on a Lisp of my own, too. It’s based primarily on EuLisp, but with some influences from Scheme, Common Lisp, and some older Lisps like Le-Lisp. I’m still in the design process, though, and am not ready to talk about it at length yet.

> I certainly would choose C over Java any day, or move to another higher-level language. I think Java's VM is a fantastic piece of work, and Java syntax is very C-like, but I'd rather not use it.

I’d originally written a rather lengthy response to this, going over various shortcomings of Java and various trade-offs involved in making that decision, and cases where Java might be a good choice, but honestly I don’t feel like reproducing it now. I don’t care enough for Java to defend it, really.

> I use a lot of programs written it though!

Of course! It’d be silly to say “X does exactly what I want/need, but it’s written in language Y, and I don’t like Y, so I refuse to use X”, though sadly I do know some people who say such things. It baffles me. What an idiotic attitude.

> I prefer Lisp/Scheme, and compiled SBCL is fast.

As do I. I’m a smug Lisp weenie and proud! In fact, up until recently, I would’ve told you that Scheme is my favorite programming language, followed by ML. Then, being disenchanted with the current state of Scheme — the divisive and controversial standards, the inability of the community to unite behind the language — and my “discovery” of EuLisp have lead me to say that my favorite programming language is my own breed of Lisp. I took a couple days of vacation from work, and I’d planned to spend them working on my Lisp, but…

> And now with the opensourcing of Chez Scheme, I will be busy this next week.

Me too. I completely changed my vacation plans when I saw this announcement. I’ve spent some time, and will continue to spend time, playing Chez and studying the source :)

> The Spring 2016 Lisp Game Jam is starting in about 24 hours….

I hadn’t heard about this. Thanks!

P.S. Hit me up sometime if you want to talk about Lisp or programming languages in general. I’m definitely a PL nerd, and I like to talk about this stuff (including implementation strategies and history). My e-mail address is in my profile.

[1] https://github.com/search?q=language%3Ac

Besides the obvious low-level stuff, like the Linux kernel, there are quite a few applications that don’t require the low-level offerings of C: git, redis, the-silver-searcher, awesomeWM, etc.