5 ms·

That's because it's a waste of time to write a program in a primitive language like C when you don't end-of-the-world absolutely need performance/hard realtime

by pka 11y ago

That's because it's a waste of time to write a program in a primitive language like C when you don't end-of-the-world absolutely need performance/hard realtime guarantees; even then it's a better idea to only write the 5% performance-critical parts in C/asm and the rest in a saner high-level language. C is definitely the wrong choice for a complex data-structure processing piece of software like a text editor. Even though vanilla JS is madness, it gives you a very nice base to build on - namely closures and a GC, which make languages like Clojure or Purescript possible. Still, for an editor I'd prefer pure Javascript over C every time.

adrusi 11y ago
There are more concerns than performance. The choice of C here is a philosophical one. Vis seems to come from the same school of thought as the Suckless projects, where the unix design principles are worshipped. People who are interested in that kind of stuff are also usually fans of writing in C, simply because C is the most Unix of languages: Makefiles control the build, which allows trivial integration of external tools into the build process, function names match 1:1 with the labels in the produced object files, no name mangling, documentation comes in man pages. But really, a text editor is something C is quite well suited to. Javascript wouldn't bring much to the table, and you'd have to jump through hoops for something like mmap.
- pka 11y ago
  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.)
  - martanne 11y ago
    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/02c6df7cd4bca89506cf1d0e4a08bd719e8f17d3/text.c#L1543 https://github.com/martanne/vis/blob/02c6df7cd4bca89506cf1d0...
    - pka 11y ago
      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.
      - martanne 11y ago
        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.
digitaltoad 11y ago
>end-of-the-world absolutely need performance/hard realtime guarantees As someone who spends much of their time inside a editor, I would say that this is pretty important to me.
- pka 11y ago
  I meant hard realtime [0]. Your operating system is probably not hard realtime, which means that any editor you run isn't either. [0] http://stackoverflow.com/questions/17308956/differences-between-hard-real-time-soft-real-time-and-firm-real-time http://stackoverflow.com/questions/17308956/differences-betw...

by pka 11y ago

adrusi 11y ago

There are more concerns than performance. The choice of C here is a philosophical one. Vis seems to come from the same school of thought as the Suckless projects, where the unix design principles are worshipped. People who are interested in that kind of stuff are also usually fans of writing in C, simply because C is the most Unix of languages: Makefiles control the build, which allows trivial integration of external tools into the build process, function names match 1:1 with the labels in the produced object files, no name mangling, documentation comes in man pages. But really, a text editor is something C is quite well suited to. Javascript wouldn't bring much to the table, and you'd have to jump through hoops for something like mmap.

pka 11y ago
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.)
- martanne 11y ago
  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/02c6df7cd4bca89506cf1d0e4a08bd719e8f17d3/text.c#L1543 https://github.com/martanne/vis/blob/02c6df7cd4bca89506cf1d0...
  - pka 11y ago
    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.
    - martanne 11y ago
      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.

digitaltoad 11y ago

>end-of-the-world absolutely need performance/hard realtime guarantees As someone who spends much of their time inside a editor, I would say that this is pretty important to me.

pka 11y ago
I meant hard realtime [0]. Your operating system is probably not hard realtime, which means that any editor you run isn't either. [0] http://stackoverflow.com/questions/17308956/differences-between-hard-real-time-soft-real-time-and-firm-real-time http://stackoverflow.com/questions/17308956/differences-betw...