Kudos to the developers for listing non goals. Too many software projects lose focus and become bloated because they take on features that are secondary to the main purpose. Projects may refrain from listing non goals for fear of excluding people who may want some of those features.
And looking at the list, there are some pretty nice features excluded. For example network support, or editing compressed or tar files. I guess the expectation is that these can still be accomplished by leveraging commands outside the editor. This is a clean approach.
Okay, but no diff mode? vimdiff is fantastic! And I'm not sure how you recover that functionality without multiple workspaces. Maybe the answer is you don't. Use vis for normal editing and pull out vimdiff only when you need it.
concerning vimdiff:
one of the goal is to get vis to also work in server mode and be embeddable.
it should then be possible to create a diff tool that uses vis for the editing.
Very often I find myself editing outside of vim and wishing vim style editing were there. Recreating optional vim key bindings for every app that has text is clearly not realistic. Getting as many things inside of vim as possible is just tantalizing enough that a lot of people (myself included) try it. It's better than nothing, but results in some very hacked together tools.
Embedding vim (or in this case, vis) inside of other things would be a much better solution.
So instead of the vim philosophy of embedding every functionality within vim, this potentially embeds vis in every functionality? I actually like that--much more composable.
I believe (and I may be wrong) that the vim philosophy is actually to embed vim in things rather than embed things in vim. They've just lost track of that a little over time.
See also :help design-not:
'Vim is not a shell or an Operating System. You will not be able to run a shell inside Vim or use it to control a debugger. This should work the other way around: Use Vim as a component from a shell or in an IDE.
A satirical way to say this: "Unlike Emacs, Vim does not attempt to include everything but the kitchen sink, but some people say that you can clean one with it. ;-)"'
You're right, and I sold vim a little short there, compared to something like emacs.
More accurately, I meant that when someone wants to combine vim with a functionality they tend to implement it as a plugin with vim as the host and interface. I won't speak for anyone else, but my vimrc tends to accumulate a lot of behavior such that it's still a kitchen sink--it just wasn't included with the initial distro.
The great thing about vim is that it'll always be there as a fallback.
I keep a file with my passwords, encrypted with Vim's builtin encryption. Neovim removed that feature. If I ever switch to neovim, I can still use vim when I need to open that file.
vimdiff is a mode within vim to compare differences between buffers. It allows side-by-side comparisons like modern GUI diff tools by showing buffers in different 'windows' (vim screen splitting). You could also open multiple window in this mode to make vimdiff behave like a 3-way merge tool. It also has commands to pick hunks from different buffers into the merge buffer.
More people should definitely try out sam and 9term as examples of how much code/features you don't really need and can still get real work done.
Personally, I wish sam had even less complexity and features than it currently does and thus be more understandable and hackable. Also, never going back to a normal terminal again, "dumb" terminals are awesome.
And actually, this experience has lead to a philosophy of software where I think the "dumb"er a piece of software the better and more reliable/performant it is likely to be. So I'm also hugely skeptical of the current Deep AI efforts leading to anywhere good.
Just jumping off your last sentence: "Simplicity" and "Transparency" are orthogonal.
In the case of deep learning, all current state-of-the-art models can be expressed as nothing more than matrix multiplication, addition, and clipping. That's all you need. It's so simple: multiply, add, clip. Multiply, add, clip.
But the model isn't transparent. It's clear what each step is doing (multiply! add! clip!), but it's not clear to the human why that's necessary.
I've never tried sam, but I used to do all my unix coding in nano, because it was simple enough that I never had to think about how to use it. I prefer simpler tools, generally, since I don't want to think about the tool; I want to think about the work I'm doing with the tool. People do amazing things with emacs, and to a lesser degree also with vi, but I simply don't want to spend the time it would take to learn such a complicated interface when I clearly don't need such a powerful tool to get my job done.
I eventually wrote my own editor, which is effectively just a text-mode window manager wrapped around a simplified nano clone which uses the control key bindings I'm familiar with from non-terminal environments. I'd be reluctant to recommend it to anyone else, since it's such a specific implementation of my own personal taste, and it has a handful of minor problems I've never bothered to fix that might cause someone else significant irritation; but it suits me. It's a very comfortable feeling to know all that can be known about the tool; I never have to waste a moment trying to remember how any of it works, and can direct my full attention through the tool to the work I'm actually trying to do.
A great trivia bit about Sam is that it's the first full screen editor Ken Thompson switched too, and he still uses it today[1]. Ken Thomspon wrote ed (in addition to being the primary original author of Unix).
I agree there are a lot of interesting ideas in 9term/sam/acme and Oberon (which was the initial inspiration for the project). In the future I would like to experiment with integrating a few more, but unfortunately time is a limiting factor.
9term/Unix is still not as lean as something you'd get with a more integrated environment like Oberon or Lisp. Just think of the many ways of parsing arguments and input. Ad-hoc languages wherever you look.
Exactly. When you want to exchange data, it's much preferable to have typed/tagged representations. If not that, then one should strive to at least avoid regex "parsing" everything. The exception is that plumbing is okay because it integrates output from all kinds of programs that already exist, but if you have control, it's a lot better to have short prefixes like, say, bug:BUG123, git:COMMITID, pkg:DISTROPACKAGE, etc. But these short prefixes miss namespacing. Anyway, this is only true for acme and friends and in Oberon elements are rich and not plain text.
Yeah, every programmer at one point has to make her own argument parsing library. Nope, there is no one syntax that fits all use cases.
While there are thousands of ways programs can parse arguments (and that's great!) there is only one argument passing mechanism in Unix (plus environment variables for implicit static things and file descriptors for streams).
Unix doesn't care how you parse your arguments, and that's why it is lean, and why it has been successful as a development platform.
Donald Knuth: "I define UNIX as 30 definitions of regular expressions living under one roof."
Yeah. I've been using Acme for awhile now. While Acme itself is nice, what I really like is the B/E editor embedded in it. It's just a very simple editor that can be extended with _external_ programs.
Finally, I've come to appreciate using a mouse with my editor. Until I completely got rid of using most keyboard shortcuts (other than the most basic ones), I didn't realize how much cognitive taxes I was paying to retain and context-switch among different families of keyboard shortcuts. Mousing is so much more uniform.
They are the utility scripts to start an editor window in Acme. B is async whereas E is sync (so that it can be used for the EDITOR env variable for software like git).
Not sure what they stand for for sure. E is probably editor. B might be buffer?
The main difference is that vis is written from scratch while neovim inherited an old and hard to maintain code base.
This allows vis to experiment with various ideas:
- native multiple cursors/selection support
- structural regular expression support
- different core data structure resulting in efficient large file support
- LPeg based syntax highlighting
- Lua as an in process extension language
- client/server design (not yet implemented)
without having to care about backward compatibility and legacy systems. Of course this has also some drawbacks for example there is no existing plugin ecosystem etc
Great! I remember last time I looked at Vis it wasn't so far along (it had no Lua integration AFAIK).
When I started submitting code to Neovim my biggest desires for it were (1) Lua extensibility (2) A clean codebase (3) Compatibility with (most) Vim plugins.
Perhaps ZyX-l's Vim to Lua project (for Neovim) could help with (3) at some point, if that's desired.
An LPeg based syntax highlighting was also something in the back of my mind, though way down the priority list. Fantastic to see it implemented, it truly is the right choice (Neovim uses Corsix's C99 LPeg parser for its testing framework, automatically exposing headers in a way LuaJIT's FFI groks).
Does it build with LuaJIT? (Sorry for the perhaps stupid question, I've just glanced at your comments here and the terminal "video".
I'm not sure. I think a few Lua >= 5.2 dependencies have crept in, but it shouldn't be difficult to fix this if desired.
LuaJIT's FFI is indeed very nice, but it is unfortunate that Lua has essentially been forked after the 5.1 release. The current C->Lua interface has been manually written.
The parser will match the specified grammar exactly, like it should. You could of course specify a grammar that is broader than the actual language you are parsing.
Well, I am vaguely aware of the existence of "incremental parsers" and "tolerant parsers", and a code editor necessarily works on code that's only partially correct...
evil-mode lets you do things like "insert this text into the same position in a block of consecutive lines" using rectangular selections. I find it occasionally very helpful. It's a little clunky though: you make the selection, press I, edit the first line, press esc, and then the other lines get edited the same way. (I'm not sure what "the same way" means if you delete a bunch of text or move the cursor around while editing.)
I haven't used multiple cursors, but I imagine they'd let you do that, but with the other lines getting updated in real time, and without requiring the insert points to be neatly aligned.
I note that with the exception of the sam code (which unfortunately uses the Lucent Public License Version 1.02, this editor is very liberally licensed (ISC/MIT/CC0).
If the sam code is optional or easily replaced, this could evolve to become a serious, modern text editor with a truly liberal license (something surprisingly absent from the current landscape, to the best of my knowledge - I've done a couple searches for an editor that could be embedded with an LGPL project, and the choices were pretty limited. This looks quite interesting.
From a portability standpoint, is there any chance of creating a native Windows version using something like http://www.projectpluto.com/win32a.htm ? That was another kicker when I was searching previously - only the really big editors like vim/emacs appear to have Windows ports...
Sure it doesn't have the features of Vim or Emacs (and some would say that's a feature!), but it's perfectly serviceable if you're okay with vi's modality.
Close, but it doesn't appear to be active (the version you get from the download link is from 1996?) and it's using the 4 clause BSD license, which (as I understand it) poses GPL compatibility problems.
A good point. I didn't specify in my initial comment (and I should have) but one of our other criteria is to be able to build everything with just a C/C++ compiler. So we'd have to bundle/bootstrap Go just to build the editor, which I believe is too heavy to be practical for that (unfortunately).
Every good programmer should write their own text editor, I think, much as each Jedi must build their own light saber. It's the tool that a programmer will spend a disproportionate amount of their time using, and they should know it well. And it's fun to do, and easy (c. 7KLOC or so for mine).
What would be the advantage of using it over vim? I am just curious. One thing I found is huge file support that would be definitely good but not sure about the rest.
The promise is that given it's a new, modern codebase, it could quickly outpace vim in capabilities and usability. Vim's legacy is what is holding the editor back from major improvements.
It sounds like you are saying it is better just because it is being written from scratch. I don't plan on contributing or writing any plugins to Vis (or vim) so I don't really care about what the 'guts' of the project look like as long as it does what I use it for (text editing). What motivation would I have to install Vis and deal with the mental overhead of switching (I am sincerely asking)? I have the same concerns with NeoVim. Maybe I just need to wait a decade for the ecosystem to catch up.
Yes. I would absolutely not advise to switch over at this point in time, unless you want to support the project. In its current state, I suspect it will be a poorer experience than vim and neovim.
One thing that comes to mind is that vim doesn't support multithreading very well or at all, when it comes to plugins. This is one of the issues Neovim is tackling.
I'd like to suggest trying integrating the syntax highlighter from JOE for speed, but JOE is GPL...
Also, I'm not sure how large the Lua/LPeg state is, but for JOE we found the highlighter is more accurate if you retain the state of each line (or every n lines), and start parsing from a real known state. It looks like Vis starts parsing 16K before the start of the window.
Thanks for the hacking file, it is a good read for people like myself who are interested in text editor implementations. If time permits I will try delve a bit into the joe code base.
As for the syntax highlighting in vis, yes it currently is stateless and only considers a fixed range of text prior to the start of the window. Having no state at all simplifies some things and allows vis to highlight even extremely large files at the expense of the occasional glitch. In practice it seems to work reasonably well.
This approach also requires that the highlighting is fast, because nothing is cached, it is completely redone after every cursor motion. I'm quite happy with LPeg so far, it is convenient to express grammars in a high level language like Lua. It also supports nested grammars nicely, but due to the completely stateless approach taken by vis this is currently not fully exploited. As an added bonus there were already ~100 lexers (of admittedly varying quality) available for use.
Thanks for writing the JOE editor. I've been using it for simple text editing tasks (commit messages, etc.) now that I've moved over to a Linux system. I appreciate its simplicity.
I shall add to your thanks. Joe's the first thing I install on any new box or server and has been my default "quickly edit this thing" editor for a decade and a half now.
Excellent. The more vim the better. I would like to see many of the core vim patterns replicated in other editors:
- modal over chords
- text objects
- the vim "language" which ties it together
- all the other good stuff, did I mention text objects ?
There is a reason vim has more users today then ever before: once you learn the deceptively simple language you can have deep conversations with your editor.
The vim language would be better if it wasn't full of exceptions that have no reason for existing (e.g. `Y` is `yy` rather than `y$`, or `cw` and `ce` being equivalent while `dw` and `de` perform different actions).
I actually like the fact that NeoVim is working on VimL to Lua translation so you can write plugins in Lua. Emacs has had LISP from the beginning. Maybe we can soon fight back with a real programming language.
Yes from a design philosophy standpoint vis is closer to kakoune than {neo,}vim. The implementation is quite different though (no C++, no boost, no home grown scripting/extension/syntax highlighting language).
I don't use either, but to be fair, I wouldn't call vis's requirements lighter than kakoune. Vis needs Lua and libtermkey (which according to its author is EOL'ed) at build and run time.
Regarding vis, Lua is optional (you lose syntax highlighting though).
libtermkey is a 3 file library and despite what the author claims it works, is useful and could be maintained in the vis repository if necessary.
If you think anything C++ related is lighter than something C based, then we just have to agree to disagree.
Dunno about libtermkey but I wouldn't worry too much about the Lua dependency. Lua is very portable and lightweight and the entire Lua interpreter and standard library are just a couple hundred kbs. You always have the option of linking them statically if you really need to.
I just switched from vim to neovim to evil. I can't see myself ever going back. (Neovim was basically just vim with async support, and terminals, but as a tmux user, that didn't really grab my attention).
There's a lot more polish in the integrations for emacs than vim, likely as a result of literally everything in the editor being a function call that can be hooked into.
The only thing I miss is solid tab functionality (there's a short of hack I've seen so far, but feels too rough for me). But honestly, with projectile + heap, I barely miss that.
Company-mode far outpaces the auto completion options in vim (though to be fair to the plugin authors, apparently they need to resort to major hacks to perform some of the things they do). Just as an example, when you autocomplete a function call, it populates the arguments and let's you tab through completing them. This same functionality sits as open tickets in the major vim autocomplete plugins, with a response of essentially "this is really hard to do in vim, hopefully we can figure something out in neovim".
It's worth the 2-3 days to make the switch and set yourself up. Also, a recommendation -- autostart emacs in server mode and use enacsclient to connect to that for all your editing needs.
What's wrong with buffers? (Not attacking, just genuinely curious)
Like you, I loved my vim tabs. But "state" is what changed my mind.
In a few keystrokes, sure I could switch tabs. Right, right, right, right, there that's the tab I want. But it's coupled to my project state: if I close a tab, there goes the muscle memory for that session. Now it's "right-right" to get to the thing I need instead of "right-right-right".
Buffers are invariant to your session state. In a few keystrokes, I could just search for the buffer by the first few letters of its filename.
I routinely keep >500 buffers open in emacs. Ten projects, half a year of journal entries, a few dozen mail messages. Having all those things available in the same number of keystrokes no matter where I am is immensely helpful.
I tried out evil some time ago, and while it was very nice, it glitched out regularly - I would (mis)type a key combination and suddenly I'm dropped to Emacs and feel completely lost. Has this happened to you?
On a side note, one of those days I'll just have to drop everything for 2 weeks and just learn Emacs.
I feel you. I want to like neovim, I really do. Same thing with this. I even want to just use emacs+evil. But since I've picked up spacemacs (~3 months ago) I can't really use anything else. I'm already pretty hooked on orgmode, and the consistent keybindings that spacemacs provides are wonderful.
This seemed interesting and I'm glad they posted their "Non goals". For me, and I would assume many others, plugins (which apparently is part of the 20% they don't plan to support) is one of the most critical features to any good text editor. This is one area where I think they may want to reconsider.
"Plugins" can mean many things, ranging from dynamically loading parts of the app to having an embedded scripting language.
I'm fine with a text editor without plugins as long as the editor can neatly interface with external applications. I used to use some Vim plugins but I found them to be more trouble than they're worth. Now I have vanilla Vim with only some syntax highlighting additions.
Rather than embedding my workflows into the editor, I'd like to embed the editor in my workflows. I don't want to run terminal apps from inside the editor, but I do want to run external apps and get the results in the editor. E.g. Vim has :make and :grep that work with the quickfix list, but this can also be done by invoking make or grep in the shell and piping the output to vim (+ some command line options to read the quickfix from stdin).
For my use, the feature that Vis needs the most is the client-server model, so I can use tmux to manage windows and open editor windows in any terminal session. That, coupled with some helpers to run external apps should do more than 80% of what I'd use editor plugins for.
Sam expressions for manipulating text. This is a blub thing - if you haven't seen them you might not realise what you're missing out on. Try to imagine an editor where the core idea is a better-sed-than-sed.
Two well-known editors to come from the ed tradition: vi and sam. Vi is an obvious evolution - make it 2d. Sam did this as well, but its main focus was developing the expression language. For example, so you can chain expressions together for text manipulation. Another comment mentions multiple cursors.
But sam also has plan9 culture. It strongly encourages the mouse with an interaction that I've found to difficult to adjust to.
Vis seems to unify the best bits of vi and sam, from a unix user's perspective.
If anyone reading this knows sam or vis fluently, it would be helpful to have a youtube video for each of sam and vis in the the style of the recent Russ Cox video on acme.
[I'm struggling to get this vis thing to build and run, tips? Debian stable. I downloaded libtermkey, configure, make make install. Not thrilled about this - would rather it create .a and .h files I could copy it into the vis dir. Now when I run ./vis it says, "error while loading shared libraries: libtermkey.so.1: cannot open shared object file: No such file or directory".]
Generalized library troubleshooting: make sure you installed the -dev of whatever package through apt-get, and try running sudo ldconfig (it is supposed to happen automatically). If you did not use apt, check your library search path.
The editor core is written in a reasonable amount of clean (your mileage may vary), modern and legacy free C code enabling it to run in resource constrained environments. The implementation should be easy to hack on and encourage experimentation (e.g. native built in support for multiple cursors). There also exists a Lua API for in process extensions.
Definitely going to give it a try. Currently I'm using Neovim and I like a lot the embedded terminal feature. I wonder how easily this can be recreated using a Lua plugin.
You can also make a command that inserts a file into the current tmux buffer, which is technically a much more straightforward solution than reimplementing terminal emulation, I think.
Fair enough. Though, I've tried vim/neovim inside a tmux session, and the terminal in neovim. And I find the latter(my personal opinion) to be more fluent to use.
There's only one .nvimrc to manage as opposed to also, tmux's file. Also, when I was using it, tmux it didn't support 24bit colors.
Again, that's a trade off, for the maintainer of the editor, it makes sense to make it as simple as possible. But this means that the user of the app will have to manage a part of the complexity, of setting up and maintaining a tmux instance.
About terminal integration, I think neovim does it by embedding libvterm, which takes care of handling the terminal part. This might be an oversimplification though.
> There's only one .nvimrc to manage as opposed to also, tmux's file.
Yes, this is definitely a trade-off.
I tend to have a global .vimrc and .tmux.conf with some sensible default settings and on top of that, I do ad-hoc per project config files that have keybindings and other definitions unique to the project configuration. E.g. run a certain test suite with a keypress.
The neat part in this is composability. The editor is just a component that you embed in your tmux. You might have other "components", such as a debugger or REPL or a file browser (ranger/midnight commander) in there too. This doesn't work as nicely if the "top level" is a text editor.
I'm really fond of building these per-project ad-hoc "IDEs" out of terminal and editor windows because I work with a really diverse set of languages and tools and no single IDE or editor plugin suite would cover all my use cases without hurting the others.
> There exist plans to use a client/server architecture, delegating window management to your windowing system or favorite terminal multiplexer.
This is from Vis's Github page. It looks like Vis's author thinks the same way as you. And I get it, it's the Unix philosophy. Though the embedded terminal is the single biggest feature I chose Neovim, over Vim. And that's just my opinion.
Will give it a try though, to Vis, and some terminal multiplexer. See if I can make it work.
As the producer of the "video" (it is actually ASCII, you can copy paste stuff out of it) I agree, here is an annotated version:
- x/pattern/ extracts stuff from the text, creates a selection for every match
- some normal vi motions are used to modify the selections, "o" to move the
cursor from one end of the selection to the other, "w" to move the cursor
to the start of the next word
- y/,/ similar to x/ but create a selection for everything which does not match,
hence splitting the existing selection into multiple ones
- \ trim selections i.e. remove leading and trailing white space
- v/Vis keep all selection not matching Vis
- g/F|C keep all selection matching F|C
- + rotate selection contents on the same line
- v/Com keep all selection not matching Com
- + rotate some more
- ESC clear selections, ESC remove all cursors
- x/pattern select different regions
- .,/^\} extend selection by searching in forward direction until the first match
of } at the start of a line
- { i/#if 0\n/ a/\n#endif/ } insert some text before every selection with i/text/
and append some text after every selection with a/text/
- change file, select similarily indented code block using a text object: vi<Tab>
- x/\w+ extracts all words from selection
- Tab align selections
- C-c remove first selection column (i.e. remove first selection on every line)
- Esc clear selections, switch to normal mode, move to next { with f{
- i<S-Tab> goto insert mode and align cursors
- search a variable, select it with C-n
- C-n select next match
- C-x skip this match, that is clear it and select next match
- C-n select next match
- c vi change operator, delete selection, switch to insert mode
- rename the variable, switch back to normal mode
- undo the changes
> it is actually ASCII, you can copy paste stuff out of it
No offense to your texteditor, I'm a vim enthusiast and after installing vis just now I really liked it, but that I can copy paste from that screencast caught me really off guard, and it's the height of my day today.
Sure, in hindsight it seems obvious, but ... that's pretty cool!
... not sure what that says about me, maybe I don't wanna know.
Only engineers see stuff like this and go "aw, cool!"
Incidentally the "video" is a small pile of JSON - filter for XHR in the devtools to find it, the URL uses an expiration system so a direct link would break. (Aaaand I just learned they implemented VT100 in JavaScript... the JSON is full of actual, real, escape sequences...)
Looks promising, and support for huge files is a weak point in vim, so I gave it a try. My usual workflow with big logfiles is to zoom into certain types of messages with e.g. :v/error/d and back out with u, and alternatively jump from one occurrence of a string to the next with *. That doesn't seem to work, so for the moment it's not the right 80% for me. But I do think it's a worthy project, so I'll keep an eye on this
Everything involving searching is currently probably very slow for large files, this is especially true for backward searches. The reason being that we currently rely on the regexp engine of libc and thus have to copy the underlying text to a contiguous memory area.
Navigating large files with motions like 50%, 70% should however be instantaneous. Navigating by line number is again somewhat slower, because the file actually needs to be read in this case.
Aside from that :v/ has a different meaning in vis.
I was gonna complain about the lack of binaries, which will instantly make me skip your project, until I saw this:
> On Linux based systems make standalone will attempt to download, compile and install all of the above dependencies into a subfolder inorder to build a self contained statically linked binary.
You'll still need the entire compiler toolchain, and 'libtool' on Ubuntu. I got as far as the ncursesw dependency before I gave up.
from https://github.com/martanne/vis/issues/140 it seems like vis doesn't yet support language-specific autoindentation. this is a must-have feature for me; i'm surprised it wasn't more of a priority for them given that this seems to be targeting programmers.
Please don't engage in programming language flamewars here. They're shallow, tedious, and silly, and never teach anybody anything (except maybe flamewar tactics).
> Can we please try to stop talking about this specific language ecosystem as an awful deplorable hell hole or whatever?
Back in the second century BC, Cato the Elder ended his speeches with the phrase 'Carthago delenda est,' which is to say, 'Carthage must be destroyed.' It didn't matter what the ostensible topic of the speech was: above all, Carthage must be destroyed.
My opinion towards JavaScript is much like Cato's towards Carthage: it must be rooted out, eliminated and destroyed entirely. I don't know if I'd go quite so far as to say that the fundamental challenge of mass computing is the final destruction of JavaScript — but I want to say it, even though it's false.
JavaScript is a pox, a disaster, a shame. It is the most embarrassingly bad thing to become popular in computing since Windows 3.1. Its one virtue (that it's on every client device) is outshone by its plethora of flaws in much the same way that a matchstick is outshone by the sun, the stars and the primordial energy of the Big Bang added together.
JavaScript is the XML, the Yugo, the Therac-25 of programming languages. The sheer amount of human effort which has been expended working around its fundamental flaws instead of advancing the development of mankind is astounding. The fact that people would take this paragon of wasted opportunity and use it on the server side, where there are so many better alternatives (to a first approximation, every other programming language ever used), is utterly appalling.
That's great, but someone else thinks PHP is worse than javascript. (All those copy-pasted security holes.) Another person thinks iOS is the real problem. (If we don't own our devices, we're not free.) For me it's malaria. (Think how many more capable programmers we'd have if fewer people were dying every day. Plasmodea delenda est!)
We can all go around commenting on every single thread about how our chosen terrible thing is terrible, and then every thread looks exactly the same and it gets really boring. Or we can all restrain ourselves to only talking about how terrible our chosen terrible thing is, in threads that are about that thing.
I would disagree with you on a variety of levels, but the phrasing and effort you put into that are impressive. Please have an upvote, and this has gone into my quotes file.
> I don't know if I'd go quite so far as to say that the fundamental challenge of mass computing is the final destruction of JavaScript — but I want to say it, even though it's false.
It's not node.js that's horrible: it's great for what it does (web development). When taken out of that use case, it's awful, because it's simply not meant to do systems programming or to make local applications.
It's kind of like people who knock Perl: it's made specifically for text parsing, nothing more, and too many people use it for much more. Since it's not meant for more complex things, it fails, understandably.
I think what the comment was trying to point out is that oftentimes there are things on Hacker News that are written in JS that shouldn't be: systems programs, emulators, shells, etc. This is not the fault of the ecosystem itself, but rather the misunderstanding of the authors about the viable use cases of the tool that they're using (node.js).
> It's kind of like people who knock Perl: it's made specifically for text parsing, nothing more, and too many people use it for much more.
Perl 1 and 2 I think really were specifically for test processing, but it is neither widely regarded as a text processing language by its users, nor would someone learning the language notice that it's particularly geared toward text processing. Perl is hated on because it's a language that turned the dynamic up to eleven and embraces multiple ways of doi g something which causes ecosystem fragmentation, and because perl 5 predates a lot of now-widespread conveniences.
I think that's still a lot of blanket judgments that programmers who can and have built other things with Node than web things, and with Perl than text monging tools, have to disagree with.
Node, for example, is a high-performing and fast-starting interpreter for a dynamic language with a base runtime that includes good tools for building network servers, system utilities, etc. There are many, many uses for which it's just great.
So when you say that Node is "awful" for anything except "web development" it's just inviting disagreement. Why make this kind of strong value judgment about a general purpose tool?
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.
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.
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.)
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.
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.
I still like node for writing utility CLIs as well, which I find myself doing A LOT these days. To be totally fair, that's mainly because of the excellent feature rich CLI modules out there (yargs, commander, etc...); but, I've found I want my CLI utilities to be in an interpreted language, and node just fits the bill pretty well for that.
But why? It's a deployment nightmare to keep node updated on servers and laptops and desktops that will never, ever use node to server server-side JS, why do I need it and NPM and the whole upgrade nightmare it implies to run a random CLI utility?
Can this specific ecosystem please stop being a massive pile of crap? Then maybe we can have something nice to say about it :)
Perhaps the new ECMAScript standard will help. I have my doubts (but as with any statement about the future it is hard to say with any certainty what will happen). The Node rot runs deeper than the usual Javascript nonsense.
If it feels like Javascript is being unjustly maligned: (a), it isn't; (b), wait for the next gnarly buffer overflow exploit to come along and you'll see that people despise C just as much.
I don't think people despise C, they just think it's misused and difficult to master.
With JavaScript, many people are just vitriolic about it. I try to offer counterpoints because I'm a small part of this ecosystem, and I'm thankful for the work people put into open source tools, libraries, etc.
I also happen to think JavaScript is a pretty neat language... like, one of my favorites, despite its shortcomings.
By the way, I don't know of any languages without serious shortcomings... funny, that...
(a meta-comment: please don't call people 'lazy' on hackernews.
We're all here specifically because we enjoy thinking about the tools we use.
It's like telling an artist not to paint a picture because they won't ever be able to capture the scene they want in the right way, or telling a student to they shouldn't bother trying their homework because they won't get every question right.)
Dang, there is nothing negative about being critical. The user I responded to clearly has childish ways of motivating himself. Being critical helps him analyze the flaws in how he motivates himself.
Hacker news is degrading quickly and you blocking me is helping that. This site needs inter-user critical comments. I doubt you have the insight to see that yourself and you're probably just following implied orders from Sam and Paul. This site is facing a leadership vacuum in this crisis and will likely implode. Good job.
And looking at the list, there are some pretty nice features excluded. For example network support, or editing compressed or tar files. I guess the expectation is that these can still be accomplished by leveraging commands outside the editor. This is a clean approach.
Okay, but no diff mode? vimdiff is fantastic! And I'm not sure how you recover that functionality without multiple workspaces. Maybe the answer is you don't. Use vis for normal editing and pull out vimdiff only when you need it.