Sorry. You lost me here. If you don't understand why so many developers are so committed to Vim, then I don't believe you understand how actual developers (not beginners) interact with code well enough to replace it.
This is actually one of my core reasons for using Vim. I agree, but all of those "more powerful ways to interact with code" happen in my head, not in an IDE. And my head is far more flexible than the IDE. In pretty much every IDE I've used you start thinking according to the patterns of transformation that the IDE supports, which can be helpful for a beginner, but is ultimately very limiting. New languages start with no IDE support. This is mostly for practical reasons I concede, but it is usually also often the case that the new language is being written because it represents a new paradigm of thinking. It's not until the language matures and the common patterns of thought become known that they then become encoded as "helpers" in IDEs.
The other main objection to this, I think, is to point out that linear textual encoding of code is itself a bottleneck, and that a strict text editor like Vim will never let you move past that. Implicit in this assumption, however, is the belief that there is a better way to represent code than linear text. However, I would point out that throughout all of mankind's history, language (and text as it's persistent form) has been the highest form of communicated logical representation. We have had access to pictography and other forms of communication for millennia, but none has had the same ability to encode and transfer knowledge and logic like text. I think we are primarily adapted as humans to think in terms of language. My bet is that there isn't a more powerful abstraction than this given the structure of our brains. I'm happy to be proved wrong though.
Given both of the above, personally I find the most productive means of working is to work primarily at the conceptual/abstract level in my head, model the problem and solution in thought, then translate the solution into the most natural form for expressing thought: language (as text).
So most of the tools that the IDE gives me (especially regarding code transformation, etc.) are hard-coded, less powerful versions of the kind of mental processes I am already doing. I don't need those. What I do need is a way to encode my thoughts in text as quickly and efficiently as possible. I don't want to have to think about that at all. I want it to flow naturally from my mental model into prose (though not English prose, obviously). For that an IDE again gets in the way. It's slow and full of distractions. The Vim keybindings have become so ingrained that it's muscle-memory. And I've yet to find another paradigm that lets me manipulate text as effortlessly.
A lot of thought and experiment went into what became eve.
I'm glad someone is exploring it. Maybe I'm wrong. Maybe this will yield promising results. But so far it seems like every time this kind of work come around again it continues to make big promises without concrete benefit. At best it provides a more gentle introduction for beginners, which is a good thing. But I have yet to see anything that would provide to me as a professional even half the utility and "accessibility" of my current toolset. Typically many of the simplifications they make in the name of accessibility become more of a hindrance than a help as you advance past the beginning stages.
I'm probably going to get down-voted to hell for this opinion here but it's literally the least productive, least intuitive, and most frustrating editor I've used.
But "learning curve" it's advocates cry! The time I have to spend getting up to speed with vim is better used actually programming, not to mention the people I know who are advanced users don't appear to code any faster than I do. A couple of occasionally used text operations are faster perhaps (though in modern editors it's debatable) but it appears to not have much cumulative effect.
As far as I can tell the only reason developers use vim is because developers use vim. It's a tautological tool.
However, vim is just great fun. That's why people obsess over it, fundamentally. It makes tricky and repetitive transformations of text intuitive and enjoyable.
This is such a fundamental disconnect from my idea of fun that I don't think we're going to see eye to eye on this ;)
> It makes tricky and repetitive transformations of text intuitive and enjoyable.
Given the fact that the number one phrase involving vim is "how do I do X in vim" I think intuitive is something that shouldn't even be in the same zipcode as it.
I suffered through learning "Brief" back in the 80s, and vim. The only feature I miss in modern editors is copying columns (usually from a bitmapping enum table). Not even drunken nostalgia is enough to make me want those control-this-that-or-the-other combos back. It's not worth the pain. It's impressive for me to see someone dance around the screen in vim, in the same way I watch somebody play a pipe organ with lots of ranks -- pulling this lever and stamping on that pedal and pushing this key and such while beautiful music pours out. Always impressive, but at what cost?
Besides, I like being able to see my code as it's executing, stop it, edit in place, back up, change execution points, etc. Maybe the visual editors have made me soft, but I can get far more done these days then back in the 80s anyway.
Genuinely curious if someone can explain how they're more productive in Vim than say Sublime? Take for example syntax highlight. If these things are feasible and easier, I'd really like to know.
Sure! I'd love to hear your opinion. I will caution you: I've heard "it's just more productive" as a general statement so many times that if it's just that then I'm going to shrug and point you at my original post where I address that.
But if its something other than that - I love to hear it (even if I end up disagreeing).
I do note that you're comparing vim (a - feature rich - text editor) to massive, bloated, IDEs... I'm curious if you've tried other, often programming related, leaner text editors to compare? (ie, Sublime Text, VSCode, Notepad++, etc)
I doubt you'd be "outperforming" if you were writing Java in say Vim, over Eclipse/Intellij...which have vi-keybindings.
The only real reason I've heard people use vim instead of a GUI IDE is because it's simply what they're used to and don't want to change. (EDIT: And the fact that it's available on every system, but that only gives a reason to learn vim, not a reason to prefer it over an IDE)
In terms of features, there's not a damn thing vim can do that an IDE can't, while there are tons of things IDEs can do. It's excruciating to hear developers say "I use vim instead of an IDE because I can do X in vim" when every IDE made in the last 10 years can do X. And it does it out of the box without needing plugins!
I've literally heard people say they like vim because they can do some key combination to highlight several lines of text and then hit TAB to indent them all at once.
Vim is at the end of the day also just a text editor, so no, there's no things that it does that you cannot achieve in some way or another with any other text editor.
The point is how quickly you can achieve these things.
Vim requires a lot of learning before you can use it effectively, but if you do know it, you can do things with it quicker than you can with other text editors.
For example, to delete the last three words in a line, you can type into Vim's command mode "$ 3b D".
The $ moves your cursor to the end of the line, the 3 does three times whatever comes next, the b moves your cursor back a word, and the D deletes everything to the end of the line.
This is the kind of stuff you can do with it. And well, you can mix and match these to do lots of different things.
It is somewhat ridiculous, but for people who actually know these commands, they have every right to feel horribly slow in any text editor that doesn't work like this.
And aside from that, Vim is really extensible, so whatever feature an IDE might offer, you can probably get that in Vim, too.
1.) They abstract important (to me) details. For example, build system integration. I prefer to see the actual Makefile to ensure that things are being linked correctly. This is especially important on large HPC clusters where there are a plethora of compiler options.
2.) They are too graphical. Essentially all of my programming is done through the terminal, which is fast and lightweight as compared to, say, Visual Studio or XCode (or w/e the standard OS-X IDE is).
3.) They do too much to 'help' the user, which ultimately just gets in the way. This is obviously a highly personal and biased opinion on my part. However, it is important (to me) to physically type the source, rather than starting from some template with boilerplate and adapting it to my needs. This is perhaps a reflection of the poor design of many languages (e.g. Java, C++) which necessitate such quality of life 'improvements' for some. But, for me, I just want to code what I want to code without an IDE getting in the way ala the maligned Microsoft Paperclip.
While I personally prefer emacs to vim, I have no doubt that these points may be common to developers who prefer either to an IDE. To your point, I do not know (but would not be surprised) to learn that some fantastic modern IDE could do all of the above. But, why do all that when emacs works so darn well for me?
# Edit text without having to constantly move hands off of the keyboard home row to move the mouse or hit keys like PgUp/PgDn.
# Change all the 'X's to 'Y's on the current line in 5 seconds.
# Syntax highlighting for [any language the IDE doesn't compile].
# Pipe text through an external program.
# Start quickly enough to pop open text files whenever you need it.
There's probably more you can do without using the mouse than you realize.
> # Change all the 'X's to 'Y's on the current line in 5 seconds.
In PyCharm, I can easily select the current line with Home followed by Shift+End, hit CTRL-R, X, Tab, Y, click Replace All. Doesn't really take much more effort than whatever black magic command vim uses.
> # Syntax highlighting for [any language the IDE doesn't compile].
Then you're using the wrong IDE. PyCharm is primarily a Python IDE, but also does syntax highlighting for JavaScript, HTML, XML, YAML, CSS, and CoffeeScript. Visual Studio Code supports C/C++, C#, CSS, Go HTML, Java, JavaScript, JSON, PHP, Python, and a few others.
Both of them have support for adding custom syntax highlighting.
> # Pipe text through an external program.
I'd be doing this on the command line anyways.
> # Start quickly enough to pop open text files whenever you need it.
I'll give you that one. But that's not enough to do your general development in vim.
Hence, they needed language constructs to make it easier to talk to databases. As a result, Eve was inspired by the Bloom language being researched at Berkeley, which was in turn inspired by an old language called Datalog. In it, they take constraints of a declarative language (like SQL) and use it to make distributed computing a lot easier.
"Our main data-structure was now a tree of tables. Rather than one big top-level function, we switched to a pipeline of functions. Each function pulled data out of the global store using a datalog query, ran some computation and wrote data back. Having less nesting reduced the impact of lexical scope and cursor passing. Using datalog allowed normalising the data store, avoiding all the issues that came from hierarchical models.
At this point we realised we weren't building a functional language anymore. Most of the programs were just datalog queries on normalised tables with a little scalar computation in the middle. We were familiar with Bloom and realised that it fit our needs much better than the functional pidgin we had built so far - no lexical scoping, no data-structures, no explicit ordering. In late March we began work on a Bloom interpreter." http://incidentalcomplexity.com/2014/10/16/retrospective/
Here's a talk by Peter Alvaro (doing research with Bloom) about it, and I had to watch it 4 to 6 times to really get everything out of it. He makes a shout out to Eve at the end (https://www.youtube.com/watch?v=R2Aa4PivG0g).
The Bloom guys are the same guys that released the paper to Anna, the KV store just 11 days ago. (https://news.ycombinator.com/item?id=16551072)
MUMPS [1] has a DB baked in. kdb+ [2] is a marriage of K and a DB.
[1]: https://en.wikipedia.org/wiki/MUMPS [2]: https://en.wikipedia.org/wiki/Kdb%2B
As an aside: Does anyone (other than Epic Health Systems or whoever) use Mumps/M at any kind of scale? I hear that the issues with global namespacing can become really burdensome above even small thresholds.
Removing the fetching and placing of data is probably the biggest source of Eve's efficiency too. It turns out a lot of the code we write is nothing more than plumbing things into the correct location.
Were you guys planning a next version of Eve with a different useful semantic? Or was this idea of having the world as views over a datastore the last overall useful idea that you guys ended up with?
Taking a stronger stance that Eve was still a bit too much like programming, and not as directly modeling as we meant for it to be, can take you to some interesting places too.
As a programmer, I had the same reaction, actually.
https://franz.com/products/allegrocache/
IBM took the idea further with AS/400 integrating one at OS-level for various apps to use that OS could manage for them.
None of them ever made it past the 'desktop' as a whole though, probably a feature of any db-included programming language.
Project home: https://lasp-lang.readme.io/docs
Results on scaling: https://arxiv.org/abs/1708.06423
[1] https://picolisp.com/wiki/?home"Even the short amount of time I wrote Eve taught me that programming doesn't need to be so complex.
If Eve didn't come along I wouldn't have believed you could program without loops.
If Eve didn't come along I wouldn't have thought twice about why all of the different layers of the stack communicated and passed data around in different ways.
If Eve didn't come along I wouldn't have believed you could just programming the happy case, because the runtime would run only the blocks of code that work with your state.
Rest assured that rethinking and reimagining programming has a bigger movement now than when you started and you helped drive it.
Ruben" (https://groups.google.com/d/msg/eve-talk/YFguOGkNrBo/r_S9hNc...)
I still think learning some Eve is worth your time just to see and experience something very different. You can get started here: http://play.witheve.com/#/examples/quickstart.eve. (This is Eve 0.2)
What's he referring to here?
recursion?
For example, writing out words instead of using symbols is easier to understand at first glance, but it's much harder to skim (even after becoming familiar with the language). SQL is a really hard language to skim. Of course, the opposite end of the spectrum (C is close) is also hard to skim.
I like the idea that most of the words that someone sees in a program are words in the domain of the program itself — its nouns and verbs — and not words in the domain of the underlying implementation language.
For example, though I visually like the way Ruby's "begin" and "end" look for delimiters, I think braces are better in that they reduce the "word clutter" of the code.
You can probably take this too far. I wouldn't want to use punctuation for control flow. But perhaps that's an argument that, like Smalltalk, control flow should be an API and not built in syntax.
I prefer Erlang's approach: dispense with the words and the braces. Unfortunately Elixir decided words were friendlier.
In retrospect, their harsh words about our current languages and tools representing a 1970s mindset come across as hubris.
Nah, I think the hubris is thinking you could make a business with a near-horizon payoff fixing the problem they accurately identified.
I can't think of any “build a new language” startups that have succeeded (I'm sure there's one out there somewhere, though.) Getting a language established is a long slog, unless you've got a mega-user as a partner from day one, which mostly happens when the project is developed internally by that mega-user.
it may not be possible any more, though.
We never did get to see the vision that was presented in that KS...
[1] 2012 was two years before Brackets/Atom and three before VSCode.
When we produced this video (https://www.youtube.com/watch?v=TWAMr72VaaU) for the v0.2 release, we actually went though the LT kickstarter video and tried to deliver on the promises made there. I think at one point in the office we had them going side by side, showing the promise in LT and the reality in Eve.
(Hopefully the community will keep it alive, I enjoyed playing around with it and I think the programming model might be onto something)
Why not write a Markdown doc that compiles to code? Especially with a system like Rails, where so much can be auto-generated. Obviously this isn't for mission-critical or new ideas, but for putting your CRUD app into the world, it makes total sense.
Those consultants have moved on to selling some new fantasy. I'm still here writing code.
What was different in Eve was that the entire language was unordered, and thus you don't need a tool-chain to read literate source -- the raw source itself is literate.
Haskell will recognize a .lhs extension and do comments by default, using > to prefix lines that are actual code (looks block-quote like).
Frankly I am something of a skeptic of literate programming. In most of the literate source code I've read, the code is clearer than the prose anyway, and having every detail in comments just makes the whys and the high level design harder to find.
My approach is to basically assume the reader is familiar with the language and the key libraries, document the whys, overall design, and the api contracts, and try to pick good variables and write clear code. This is not to say "inline comments are bad," but I find that usually when I find myself writing a lot of comments explaining the details it's because I'm writing a lot of confusing code.
https://news.ycombinator.com/item?id=16625687 > No Klik & Play?! It was the reason I can say I was building and distributing my own games back in 5th grade! > No Lego Mindstorms!? I was building Robots with six degrees of freedom in middle school!
I think you, in fact, do understand the value of human-oriented programming.
I’d argue that programming languages are already human oriented, it’s not like we’re putting together programs with assembly or binary code like some people imagine. And syntax and conventions improve all the time to make it easier.
If you want to be able to simply speak a program’s requirements and watch it happen, there’s already a solution for that: hire a coder.
If everyone had this attitude we'd still be traveling between cities on foot.
Based on their demo, it appears the purpose of the language was to push the "human centered" aspect of it even further, and not to settle for what's possible today.
I think the problem they really had from the beginning was they were pressuring themselves to innovate in an industry that is already decades old. You can't raise $2 mil and not feel the pressure to perform, and sadly this is not how innovation works. So instead they kept releasing prototypes that didn't really make sense or remotely scale:
- turning sql into graphs that made a 2 line statement take up the whole screen
- the database language that had no performance characteristics at all
- the bouncing ball demo that seems to only be made to create a bouncing ball, and yet doesn't add more understanding to the process anyway
- the imperative language written in 'english' (but of course only accepts the english words and specific grammar the software understands) and so on.
Not trying to be harsh, but this is probably a good thing. Once they take a break and move on to other things, a ton of ideas will no doubt come flooding in, just because they aren't under the same scrutiny and pressure anymore.
You have to remember that there are still many people who want to back this as a project. One of the big issues is that it is a really hard problem technically to solve with many "unknown" "unknowns".
And yes, I agree that many ideas will flood in because of this, and Chris Granger and Rob Attori and co have already influenced many other people and projects, they are in my opinion the thought leaders in this new programming space, and as a consequence have already influenced the entire industry with their ideas.
In any case, they influenced me, and if they influenced just one person, that is enough for me :)
I've been in tech a long time and have known lots of extremely bright people. But, I've not met many who exhibit such a broad horizontal grasp of complex technical concepts combined with an elegant and concise way of expressing this knowledge (e.g. via Eve).
I'd surely bet on this guy again.
- "Prose-style", where comments are a first-class citizen and code lives inside blocks. Seems like this would go a long way to encourage thorough commenting.
- The checkbox-style thing, where you can easily mix different pieces from different files on the screen at once. That was incredibly slick. The general idea of abstracting code constructs away from the literal files they live in is something that's been bouncing around in my head for a while.
- The state export was pretty cool, though it's not clear to me that could easily be implemented without controlling the language itself.
That will NEVER (ie, to be on mainstream) work for large scale software OR attract non-experts.
Try to make a "virtue" a "callback-hell" with other names is a futile idea (apart some specific scenarios). If is hard to debug, is hard to have a mental model of it, period.
---
The other parts of the idea sound well, but is not clear how the magic is made or how create the "data store".
I would love to see something like literate programming become more mainstream, though. Even little things like having to repeat parameter names in a block above a function/routine, rather than simply next to each parameter, seems like it’s harder than it ought to be.
http://www.eslsyndetic.com/Documentation/overview_of_respons...
It was a cool model, if a bit ahead of its time. Good to see the idea living on.