Hacker News Reader

Comment by pka | Hacker News Reader

I agree that often the choice of C is philosophical rather than technical, or we wouldn't see so much misuse of that language (and yes, I wouldn't count the build or package management system (or rather the non-existence thereof) or the documentation format as serious technical arguments for or against a language).

Just to be clear, I'm not advocating the usage of Javascript here, rather I'm trying to make the point that C is a really really primitive language and programming in it, rather than in a higher-level language (any higher-level language) is almost always a waste of time.

(Drivers and memory / performance-constrained code being an exception.)

Btw, there's a mmap module or library for any major programming language out there (checked for Js, Python, Ruby, Haskell, even Clojure.)

View on HN

Some things are just more convenient/efficient to do in C. As an example the mark handling[1] used to represent cursors/selection relies on pointer arithmetic.

Other things like the syntax highlighting are implemented in Lua which is high level but still has low resource usage.

And yes part of the choice is also philosophical. I consider an editor a core system tool which should have minimal dependencies.

[1] https://github.com/martanne/vis/blob/02c6df7cd4bca89506cf1d0...

A mark could just be an offset inside the Text buffer instead of a direct pointer. Yes, dereferencing a mark would be slower, but do you really think that matters? I mean even if you did that 1M times/sec there wouldn't be a noticeable difference to the user.

On the other hand, look at array.c. Or buffer.c. Or map.c. Or all the manual linked list management stuff. Or all the other logic that would be so much simpler with a more functional language. I mean, sure - there's an unique feeling to being so close to the metal, and that's fine, but if you want to build something new reinventing the wheel for the millionth time is a waste of time.

edit: there are compiled higher-level languages too (i.e. Haskell). If you want minimal dependencies, it doesn't really matter how the binary got built.

The nice thing about the pointer as mark thingy is that while the offset from the start of the file might change when something is inserted before it, the pointer will remain the same.

Anyway this was just an example. I agree that higher level languages (including functional ones) have their own merit. If I would start again today I might consider Rust. But again the LLVM dependency seems kind of scary.

Again for me an ideal base system is built upon a kernel, libc (musl), C compiler (cparser/libfirm), coreutils (sbase/ubase, toybox, busybox), editor (vis) etc. Writing a C compiler is non-trivial, but doable. Creating a C++ compiler on the other hand ...

A self contained (including terminfo entries etc), statically linked vis binary weights in at around ~800K. This allows usage in resource constrained sytems, I don't think the same would be possible using e.g. Haskell.

Fair enough - if portability to systems without much more than a C compiler is a project goal, than C is obviously a good (the only?) choice :)

Reply on news.ycombinator.com