Eve: Programming designed for humans(eve-lang.com)
eve-lang.com
Eve: Programming designed for humans
http://eve-lang.com/
123 comments
> Most programming languages think of a database as a thing separate to it (I think Smalltalk is an exception).
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
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
I could be wrong, but my understanding is that MUMPS/M seems more analogous to a Database with a built-in language than a language with a built-in database, although having said that, the distinction seems pretty fine to me. Is Company X SQL, which can have sprocs and such, also a language with a database baked in?
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.
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.
The Veterans Administration's health system - one of the largest in the world - runs on Mumps, as does Epic Systems which powers a large percentage of the medical practice/hospital systems in the U.S. TD/Ameritrade runs some systems on M as do many banks. I have heard that ATM systems have used it in the past, though not sure if they still do.
Petroleum industry used to use Pick where I lived for some distribution software, but it seems it's main place is medical records software from what I've heard).
It is a fine distinction I suppose, although the Pick stuff I've looked at was more than just stored procedures - TUI/GUI support for apps (mostly dumb terminal based but Cache probably has some GUI stuff in there now), overnight batch scripts and report creation etc.
I haven't used MUMPS, but did a little bit of time with Pick and later on Cache. I believe Pick systems were often more than just the multi-valued database and absolutely horrendous language, in that they were often tightly integrated into the OS too - disk storage, terminal support etc.
It is a fine distinction I suppose, although the Pick stuff I've looked at was more than just stored procedures - TUI/GUI support for apps (mostly dumb terminal based but Cache probably has some GUI stuff in there now), overnight batch scripts and report creation etc.
I haven't used MUMPS, but did a little bit of time with Pick and later on Cache. I believe Pick systems were often more than just the multi-valued database and absolutely horrendous language, in that they were often tightly integrated into the OS too - disk storage, terminal support etc.
The system that gathers data for California birth certificates and related [pre]natal health stats reporting is written in MUMPS/M/Cache.
I’ve not worked with the code for that, though - we are in the process of replacing it. The fellow that originally created the system decades ago has been in “semi retirement” for quite a while, and it’s hard to find people that want to work on the platform. So, we are doing a replacement in (mostly) Java, of course. And I don’t even especially like Java, but it pays the bills in the Sacramento area.
I suspect the bigger scaling issues with the codebase are “people-ware”, and thus the push (in most shops and projects) to go least common denominator on programming platform choice, sadly.
I’ve not worked with the code for that, though - we are in the process of replacing it. The fellow that originally created the system decades ago has been in “semi retirement” for quite a while, and it’s hard to find people that want to work on the platform. So, we are doing a replacement in (mostly) Java, of course. And I don’t even especially like Java, but it pays the bills in the Sacramento area.
I suspect the bigger scaling issues with the codebase are “people-ware”, and thus the push (in most shops and projects) to go least common denominator on programming platform choice, sadly.
The Lasp programming system also has an eventually consistent key-value store built-in (and, we've scaled it to 1,024+ nodes).
Project home: https://lasp-lang.readme.io/docs
Results on scaling: https://arxiv.org/abs/1708.06423
Project home: https://lasp-lang.readme.io/docs
Results on scaling: https://arxiv.org/abs/1708.06423
Picolisp has an integrate database [1] which the author has been using to build applications for a living since the 80s or 90s (I cannot recall when).
[1] https://picolisp.com/wiki/?homeThe whole thing actually reminds me of Inform7, which is a natural language implementation of text adventures on a similar (albeit very old) database query language system.
I just wrote a tiny parser game in Inform, and the language is fascinating. You can create complex, fully interactive scenes in just a few sentences. For example, with just "There is a billiards table in the Gazebo. On it is a trophy cup. A starter pistol is in the cup." Inform would create three objects (a billiards table, a trophy cup and a starter pistol) in a previously established room (the Gazebo), and would deduce that the billiards table is a supporter (you can put things on it) and the trophy cup is a container (you can put things in it). With no further code you can examine all three items, remove the pistol from the cup and put it on the table, and so on.
Another example is combining a database with LISP via AllegroCache:
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.
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.
"Excited, we presented our prototype to a small number of non-programmers and sat back to watch the magic. To our horror, not a single one of them could figure out what the simple example program did or how it worked, nor could they produce any useful programs themselves." (From the article linked above).
As a programmer, I had the same reaction, actually.
As a programmer, I had the same reaction, actually.
That quote isn't in reference to the version described in the comment you're replying to.
I completely agree that the semantics are probably the most overall useful thing we presented in this version of Eve. Having the world just be views over a datastore that you don't have to manage in any meaningful way is hugely liberating coming from the way we program now. You don't have to worry so much about how things are "placed" - you can always access them wherever and however you want. Bloom gave us a nice way of thinking about how to deal with change in that context so that it's not just some giant pile of scary mutable state.
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.
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.
> I completely agree that the semantics [of views over a datastore] are probably the most overall useful thing presented in this version of Eve.
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?
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?
There were a few directions we went hereafter. One was thinking of the world in terms of simulations, another was statemachine oriented. There are a few things that were never quite right with the set of semantics here: things that really were an ordered set of steps (far fewer things than you think, but still some) were pretty hard to express and the distinction between commit and bind caused some weird things to happen at the edges. The former could be fixed by directly integrating statemachines into the language. The latter remains a bit of an open problem. Some things you want to manually manage the lifetime of, others you want to be tied to their supports. The problem is that you often want to mix and match those freely, which is just a tough thing to reason about.
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.
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.
I'm sorry you didn't move forward with the state machine integrations.
I think some core primitives and conventions exposed at the language level would have developed it into a uniquely useful language environment.
I think some core primitives and conventions exposed at the language level would have developed it into a uniquely useful language environment.
I believe a major programming environment that you are missing here is the SAP environment and the ABAP language, which (from my minimal experience) is entirely database-centric and probably powers most of the large enterprise HR and commerce systems in the world.
I've been writing Elixir at work for the last 5 months and learned in that time that Elixir has DBs built in as well. ETS is a key value store and Mnesia (lol) is a bit more like a traditional db (I haven't actually used Mnesia yet). From what I understand these things are actually a part of OTP and so they ship with the whole environment.
I never had much to do with them, but stuff like dbase III and FoxPro and the like were integrated DB/language environments, and they were quite popular back in the day.
Mmm... Ashton-Tate dBase III+, those were the good old days:) And later, similarly with db and programming integration: MS Access, and even Excel to some extent.
None of them ever made it past the 'desktop' as a whole though, probably a feature of any db-included programming language.
None of them ever made it past the 'desktop' as a whole though, probably a feature of any db-included programming language.
I did quite a bit of dBase/Clipper back in the late 80s.
The resulting code was much cleaner than most of the “enterprise” crap I have to deal with now, but xBase had some serious shortcomings:
Corrupted indices in a multi-user (LAN) environment
No roll-back (since no transactions)
No referential integrity constraints
Yeah, I sometimes miss it, but I understand why it died.
The resulting code was much cleaner than most of the “enterprise” crap I have to deal with now, but xBase had some serious shortcomings:
Corrupted indices in a multi-user (LAN) environment
No roll-back (since no transactions)
No referential integrity constraints
Yeah, I sometimes miss it, but I understand why it died.
I hear you. Yea, I never got round to using Clipper but was on track, especially the possibility to create standalone applications as front-end clients in a client/server setup was interesting. It was bought and botched by CA before I got round to it though, at least it looked like CA mishandled it from what I could see.
A fun related fact albeit OT was that those DOS applications were orders or magnitude faster to keyboard operate than the GUI applications that came after ... I'm sure some of them are still in use for that reason.
A fun related fact albeit OT was that those DOS applications were orders or magnitude faster to keyboard operate than the GUI applications that came after ... I'm sure some of them are still in use for that reason.
In case you missed it, this project is no longer being actively developed: https://groups.google.com/forum/#!msg/eve-talk/YFguOGkNrBo/E...
[deleted]
Thanks for linking this. The community response is quite something.
"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...)
"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...)
That's me.
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)
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)
> If Eve didn't come along I wouldn't have believed you could program without loops.
What's he referring to here?
What's he referring to here?
Eve doesn't have loops, because the basic unit isn't a variable but a set of variables. So a computation is applied to every element in a value.
e.g.
x = [1, 2, 3]
x + 2
// x = [3, 4, 5]
I have since learned that APL does something similar, expect their basic unit is an array.
e.g.
x = [1, 2, 3]
x + 2
// x = [3, 4, 5]
I have since learned that APL does something similar, expect their basic unit is an array.
> If Eve didn't come along I wouldn't have believed you could program without loops
recursion?
recursion?
Recursion could be considered a form of looping. Eve does not have recursion either, see my above comment[0] on how Eve managed to apply computation to a bunch of values without loops.
[0] https://news.ycombinator.com/item?id=16631600
[0] https://news.ycombinator.com/item?id=16631600
I wonder what Chris Granger will almost-build next.
What a nice thing to say.
I'm actually a fan of his, and mostly mean it tongue in cheek. I kickstarted Light Table with my last $50 after paying rent one month in college and, while somewhat disappointed in the outcome of that project, remain generally supportive of his dream big/fall short approach.
Sorry for my reaction then. So much is lost in text posts.
I'm grateful for your reaction (and OP's response) because the clarification made a substantial difference in how I interpreted that.
Thoughts on why this project was dumped by investors:
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.
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.
As one of the investors I think it is strong language when you say "dumped", and not really true in my opinion.
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 :)
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 had only just learned of Eve through this post, and watched a bunch of Chris' videos... I was blown away by him!
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.
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.
I was just reading about Light Table's denouement and how Eve was in a way its successor, and now I find Eve has gone about the same way. It looks like both projects foundered because the problems they addressed --- representing code in non-linear ways with changes live-propagating through the system's state --- are very, very hard, apparently harder than Chris et al. realized.
In retrospect, their harsh words about our current languages and tools representing a 1970s mindset come across as hubris.
In retrospect, their harsh words about our current languages and tools representing a 1970s mindset come across as hubris.
[deleted]
> 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.
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.
definitely not recently but I think MATLAB, Mathematica, S, Stata, and lots of other commercial scientific/numerical packages could qualify.
it may not be possible any more, though.
it may not be possible any more, though.
As a KS backer of Light Table I always get sad about what might have been[1] if they hadn't gone the YC + VC route that basically lead to abandoning LT before it was near ready for daily use for most of us.
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.
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.
> We never did get to see the vision that was presented in that KS...
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.
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.
IIRC Eve was developed by a startup, and they stopped development because they couldn't find a business model to fund it, not because of problems with the language.
(Hopefully the community will keep it alive, I enjoyed playing around with it and I think the programming model might be onto something)
(Hopefully the community will keep it alive, I enjoyed playing around with it and I think the programming model might be onto something)
This is no longer an active project...
https://twitter.com/with_eve/status/956258695049981952
Odd that its not mentioned on their site though?
Maybe they haven't accepted it yet. Though their blog posts were always few and far apart.
Eve was a great idea, I’d love to see a community take it up after the business behind it folded. (I think v0.2 was the last version with the whole stack that had been built to that point working; v0.3 had engine improvements but I don't think ever had the dev environment, and v0.4 was a complete rewrite in Rust that I don't think ever got to a releasable state, though there were some demos before they went mostly silent for a while and then closed up shop.)
v0.4 was missing documentation and some other habitability improvements, but in its current state it was by far the most useful Eve. You can download it here if you want to try it out: https://github.com/witheve/eve-native
I'm a huge advocate of bringing usability/ergonomic considerations to programming languages. That said, I have strong opinions about syntax decisions that hinder those goals.
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.
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.
There are tradeoffs. The syntax was explicitly designed to be eminently readable, because our target audience were groups who were not traditionally programmers, but who might still be highly technical. For this group of people, they may not take readily to C++, but are instead more comfortable with languages like Python and SQL. Perhaps skimming code suffers from this design, but we thought we could mitigate that by adding other avenues for navigating code, such as a table of contents. We also made some progress in automatically annotating blocks of code based on what they do, to make filtering, sorting, and searching code richer.
So is APL easy to skim?
You're being snarky, but I think there's something to the parent comment.
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 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 agree! Anecdotally, I prefer `x >>= y` over `x .then y`, and `f <$> xs` over `map f xs` because the symbols "read quieter" to my mind, which helps me maintain focus.
Those aren't so bad if you have something like hasklig installed. But otherwise the stilted typography just drives me crazy.
Syntax highlighting usually is used to set apart the language's keywords from the rest of the program. They become less like words and more like standard symbols.
Great point! One of the things I really like about syntax highlighting is this separation. It's important enough that when I'm toying with syntax for my hobby languages, it's really hard for me to get a feel for how something looks if it isn't highlighted correctly.
I agree. I prefer to have both. It's hard to argue that either SQL or Brainfuck is more readable than, say, JavaScript (to an experienced eye), so a happy medium must exist.
> I think braces are better in that they reduce the "word clutter" of the code.
I prefer Erlang's approach: dispense with the words and the braces. Unfortunately Elixir decided words were friendlier.
I prefer Erlang's approach: dispense with the words and the braces. Unfortunately Elixir decided words were friendlier.
I love this idea. I've always thought the disconnect between documentation and code felt a bit repetitive.
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.
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.
This particular part of it isn't a new idea though, it's literate programming, been around since Knuth.
Literate Programming as put forth by Knuth always involved a "tangle" process in which source code and documentation is formatted into a literate document. This is due to the forced order of statements compilers impose on most programming languages.
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.
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.
Yeah, I've seen a fair bit literate code that is awkwardly structured to satisfy ordering needed by the underlying language. It works better in languages that don't care about the order of declarations, of which there are many, but usually there's something at the top to the effect of "we need to start off with a pile of imports, because compiler."
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.
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.
That's what was promised by the UML (Universal Modeling Language). I remember consultants telling us in the 1990s how "soon, you'll just draft UML diagrams and that will execute directly."
Those consultants have moved on to selling some new fantasy. I'm still here writing code.
Those consultants have moved on to selling some new fantasy. I'm still here writing code.
Discussion from original release in 2016 (nearly 400 comments): https://news.ycombinator.com/item?id=12817468
The IDE has some interesting ideas but I'm not convinced that the language itself is actually particularly intuitive. I would love to see a JavaScript IDE (Atom extension?) with features like
- "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.
- "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.
> An IDE like Medium, not Vim
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.
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.
For what it's worth, I have used Vim since ~2004. When I built Light Table, one of the first things I did was put a Vim mode into it. I understand pretty well why at least I use Vim. I also believe that these days there's relatively little payoff given the cost of investment. Rarely is the speed of text-editing the bottleneck in building something real. Moreover, there are far more powerful ways to interact with code than at the text buffer level.
> Moreover, there are far more powerful ways to interact with code than at the text buffer level.
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.
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.
I think you are right, but: how about tools like Excel, which is very non-linear, and yet it seems to be easier to pick up, and less intimidating, for complete newcomers compared to traditional programming?
Excel is, to me, an example of an alternative means of arranging logic that is very well suited to a specific subset of problems. You'll notice that people aren't typically building general-purpose applications with Excel. It's clearly not a replacement for a general-purpose language. But it is also clearly a more "natural" fit for it's niche of problems.
Actually, I think that this line of thinking holds a lot of promise: building specific tools well-tailored to solving specific types of problems. I think we could easily find models and alternate modes of thinking that outperform text for given domains.
I guess my argument is that as humans language is our most fluent medium for communicating abstractions. In the general case I don't think it will be outperformed.
Actually, I think that this line of thinking holds a lot of promise: building specific tools well-tailored to solving specific types of problems. I think we could easily find models and alternate modes of thinking that outperform text for given domains.
I guess my argument is that as humans language is our most fluent medium for communicating abstractions. In the general case I don't think it will be outperformed.
Sure, it might not be general purpose, but the "niche" is really quite large: there aren't too many websites written in Excel, but there aren't many written in C++ either :) I am really not a fan of Excel overuse, but it happens, so I think there must be something about it that makes its programming model attractive to people.
For one, constructs like loops that we have mostly internalized as natural, can look a bit intimidating to non-programmers (they are not found in regular language either though!). Even among fairly experienced coders, for example in statistical programming, people who come from general-purpose coding background sometimes find loops easier to read and write compared to "vectorized" code, and vice versa.
Thinking about it, the way say much Java code is written is not what I would call a linear language either, although that I suspect might be more a result of path dependence and optimizing for "large teams of replaceable programmers".
For one, constructs like loops that we have mostly internalized as natural, can look a bit intimidating to non-programmers (they are not found in regular language either though!). Even among fairly experienced coders, for example in statistical programming, people who come from general-purpose coding background sometimes find loops easier to read and write compared to "vectorized" code, and vice versa.
Thinking about it, the way say much Java code is written is not what I would call a linear language either, although that I suspect might be more a result of path dependence and optimizing for "large teams of replaceable programmers".
Having followed the project I don't think it's fair to assume that those working on it didn't understand why developers like vim. It's more just that traditional developers doing traditional developer things weren't the most important part of their target market.
A lot of thought and experiment went into what became eve.
A lot of thought and experiment went into what became eve.
Yeah, it's been a while since this effort has come up on my radar. Now that I'm remembering a little more, these are the same guys who were behind light-table, I think. So I guess it's fair to say that they've thought deeply about the problem. I still think that the path they are exploring will not bear fruit as in my opinion they seem to have a core, almost axiomatic disbelief in the inherent difficulty of software development and a corresponding disdain for the patterns of work that have led to what is actually productive today. I think that software development is fundamentally, irreducibly hard. Poor tooling can certainly makes it more inaccessible and good tooling can certainly make it more accessible, but the real difficultly is conceptual and not due to the nature to any particular language or tooling. Therefore tooling and language alone cannot make it fundamentally easier.
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 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.
Having been a programmer for 20 years I have no idea why so many developers are so committed to Vim (other than it is available almost everywhere, which is helpful when doing things on a remote server).
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.
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.
I think you're missing out a little here. Sure, vim doesn't make you more productive. Sure, time spent learning vim is probably better spent programming.
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.
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.
> However, vim is just great fun.
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.
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.
> intuitive is something that shouldn't even be in the same zipcode as it.
That's the thing, though. It's very different to non-modal text editors, so there's this learning 'cliff', where you get frustrated by how unfamiliar it is.
However, when it comes down to it - the neat thing about Vi is it's a re-imagining of what a text-editor is. Non vi-like editors essentially derive from the metaphor of a typewriter. You have a cursor, the print head, and you enter text there. You can use your hand (mouse) to change where the print head is pointing. You can highlight sections, as if with a pen - copy and paste stuff, as if you were using scissors. These functions are displayed a bit like the extra functions of one of those late-model electronic typewriters, where you could press a key-combination to get some neat functionality.
The nice thing about Vim is it accepts that editing text on a computer isn't like this. When you edit on a computer, you jump into a pre-existing text, mostly, adding or changing. So, for this reason, it has lots of functions for accurately manipulating sections of text, like words, or things between brackets, or sentences.
This kind of functionality is pretty standard for a good editor, but I think the thing Vi got really right is organizing these functions. The problem with having lots of functions is that they're hard to remember. So Vi structures them like a language.
So in the end, I think it's more intuitive than other editors. It doesn't work within the context of an outdated metaphor, and, it structures the functions that allow it to surpass that metaphor in a way that makes them extremely easy to discover and to remember.
That's the thing, though. It's very different to non-modal text editors, so there's this learning 'cliff', where you get frustrated by how unfamiliar it is.
However, when it comes down to it - the neat thing about Vi is it's a re-imagining of what a text-editor is. Non vi-like editors essentially derive from the metaphor of a typewriter. You have a cursor, the print head, and you enter text there. You can use your hand (mouse) to change where the print head is pointing. You can highlight sections, as if with a pen - copy and paste stuff, as if you were using scissors. These functions are displayed a bit like the extra functions of one of those late-model electronic typewriters, where you could press a key-combination to get some neat functionality.
The nice thing about Vim is it accepts that editing text on a computer isn't like this. When you edit on a computer, you jump into a pre-existing text, mostly, adding or changing. So, for this reason, it has lots of functions for accurately manipulating sections of text, like words, or things between brackets, or sentences.
This kind of functionality is pretty standard for a good editor, but I think the thing Vi got really right is organizing these functions. The problem with having lots of functions is that they're hard to remember. So Vi structures them like a language.
So in the end, I think it's more intuitive than other editors. It doesn't work within the context of an outdated metaphor, and, it structures the functions that allow it to surpass that metaphor in a way that makes them extremely easy to discover and to remember.
> I think intuitive is something that shouldn't even be in the same zipcode as it.
The Vi keybindings and command set is largely self-consistent and follows common patterns. So while it might not be intuitive to someone unfamiliar with it, it becomes very intuitive once you grok the core patterns and concepts. There have been plenty of times I have strung together sets of commands and only noticed afterwards that this was technically a new behavior I'd never invoked before.
The Vi keybindings and command set is largely self-consistent and follows common patterns. So while it might not be intuitive to someone unfamiliar with it, it becomes very intuitive once you grok the core patterns and concepts. There have been plenty of times I have strung together sets of commands and only noticed afterwards that this was technically a new behavior I'd never invoked before.
So it’s only intuitive if you know it already?
Not a selling point.
Not a selling point.
No downvote from me. I agree with your sentiment.
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.
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.
Take your well earned upvote! I've had many a person say the same thing to me about Vim and despite the fact that I like it, I can't see myself being as productive as I am in a normal IDE.
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.
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.
People like the actual text editing environment and either don't care about the extra functionality an IDE would provide or just add such functionality as plugins. Since text editing speed isn't the primary limiting factor in producing software you may realistically not be much or even any faster whichever environment you choose unless the environment is actively horrible.
Fair enough. I would never argue that Vim's text editing functionality wasn't superior. However, the advocates I've encountered all touted it as superior, "...in every way." and I just haven't seen that.
Are you actually interested in having a conversation about why developers (like me) use vim? I've also been a programmer for almost 20 years. For me Vim+unix has outperformed VisualStudio (6-through current), Eclipse (and multiple derivatives), NetBeans, Xcode, and lots of smaller, language-specific IDEs.
Are you outperforming with Vim, or is Vim outperforming over those other editors/IDEs?
I doubt you'd be "outperforming" if you were writing Java in say Vim, over Eclipse/Intellij...which have vi-keybindings.
I doubt you'd be "outperforming" if you were writing Java in say Vim, over Eclipse/Intellij...which have vi-keybindings.
> I doubt you'd be "outperforming" if you were writing Java in say Vim, over Eclipse/Intellij...which have vi-keybindings.
That's exactly what I'm doing.
----
edit If you're actually interested in a discussion: what does your IDE actually give you in Java?
* Syntax highlighting? Every code editor (including Vim) gives you that, especially for such common languages as Java.
* JavaDoc access? Cool, but not worth the overhead. I've got the JavaDoc up in a browser pane on my second monitor, easy to search, doesn't make typing laggy or crap all over my text editing pane like the IDE does, and isn't triggered until I actually need the JavaDocs. I've found that by looking them up myself and not having autocomplete I actually internalize the documentation better, which means I need it less. My brain is much faster at autocomplete than the IDE too.
* Automated variable rename. Again, cool. This is one of the few net benefits. Doesn't out-weigh the rest. And silver surfer/grep + Vim gets me 95% of the way there. The only real trouble is when you have lots of duplicate names for un-related things, and that's a bad pattern I'm try to eliminate in my code anyway.
* Debugger? This is a powerful tool, to be sure. But it's not IDE-only. And I've seen it abused. I've never been anti-debugger, quite the contrary. I love my debugger. But I've noticed that as I've gotten older and have developed deeper experience I use it less and less. In fact, I don't think I even have a debugger installed on my work machine right now!
* Automated refactor/etc. I'm convinced this is the cause of bugs more often then the fix. Certainly for poor architectural decisions. I've elaborated in other comments, but basically: train your brain.
That last one I'll emphasize. I don't want the IDE doing any of my thinking for me. It doesn't think it applies canned patterns which may or may not be appropriate. Certainly it can be used well, but the more you use your brain to do it the better your brain will be. And if you train your brain it will be accustomed to doing the work so that the value lives in you, not your IDE. Now it's language-agnostic. Now you can jump onto the next cool language without being hobbled by the lack of IDE support. Now you are forced to learn the details of all the tools your IDE is wrapping for you and are more prepared to actually solve problems with, for example, your build environment.
Of course, I'm not saying that it's a binary your brain vs the IDE thing, but personally I find it more productive to live outside the IDE all the time.
That's exactly what I'm doing.
----
edit If you're actually interested in a discussion: what does your IDE actually give you in Java?
* Syntax highlighting? Every code editor (including Vim) gives you that, especially for such common languages as Java.
* JavaDoc access? Cool, but not worth the overhead. I've got the JavaDoc up in a browser pane on my second monitor, easy to search, doesn't make typing laggy or crap all over my text editing pane like the IDE does, and isn't triggered until I actually need the JavaDocs. I've found that by looking them up myself and not having autocomplete I actually internalize the documentation better, which means I need it less. My brain is much faster at autocomplete than the IDE too.
* Automated variable rename. Again, cool. This is one of the few net benefits. Doesn't out-weigh the rest. And silver surfer/grep + Vim gets me 95% of the way there. The only real trouble is when you have lots of duplicate names for un-related things, and that's a bad pattern I'm try to eliminate in my code anyway.
* Debugger? This is a powerful tool, to be sure. But it's not IDE-only. And I've seen it abused. I've never been anti-debugger, quite the contrary. I love my debugger. But I've noticed that as I've gotten older and have developed deeper experience I use it less and less. In fact, I don't think I even have a debugger installed on my work machine right now!
* Automated refactor/etc. I'm convinced this is the cause of bugs more often then the fix. Certainly for poor architectural decisions. I've elaborated in other comments, but basically: train your brain.
That last one I'll emphasize. I don't want the IDE doing any of my thinking for me. It doesn't think it applies canned patterns which may or may not be appropriate. Certainly it can be used well, but the more you use your brain to do it the better your brain will be. And if you train your brain it will be accustomed to doing the work so that the value lives in you, not your IDE. Now it's language-agnostic. Now you can jump onto the next cool language without being hobbled by the lack of IDE support. Now you are forced to learn the details of all the tools your IDE is wrapping for you and are more prepared to actually solve problems with, for example, your build environment.
Of course, I'm not saying that it's a binary your brain vs the IDE thing, but personally I find it more productive to live outside the IDE all the time.
No. The top feature of an IDE is the call tree: Show me all the callers of this function and all of their callers and so on. This is a game changer. It means that you can reverse engineer someone else's code (or even your own). And in practice, that's what your spend most of your time doing if you want to make changes that are congruent with the whole system. Eve claims to have tools to help with this despite not being statically typed. If I get time I would like to try it because the querying and matching parts of the system are very attractive.
[deleted]
Eclipse is just an abomination I don't understand how anyone could love or not want to destroy with fire.
Intelillij's vim plugin is an example of delete the source code repo and start again. It is ... not good.
Intelillij's vim plugin is an example of delete the source code repo and start again. It is ... not good.
> Are you actually interested in having a conversation about why developers (like me) use vim?
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)
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 just posted a comment in response to ibdknox (Chris Granger, awesome that he's involved in the discussion, btw) here: https://news.ycombinator.com/item?id=16631233
To summarize, for me most of the real work of programming happens in my head, and in my experience that's a much more powerful place to work when you train yourself to do it. In light of that, all the "features" of the IDE become bloat and distraction. What I need is a fast, responsive editor that doesn't get in my way.
> 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)
Yes, exactly, and many of those are other good alternatives to Vim. Above is why I strongly prefer text editors to IDEs. I know Vim-style modal editing with basically a language of commands in and of itself is not a good match for everyone's mental model, but personally I'm at the point where I don't have to think when I'm manipulating text: it's all automatic, and extremely powerful. Moreso from a text-manipulation than any other editor I've used. That's why I'm with Vim specifically and why it's so productive for me. Vim+unix has become (over the years) the fastest way to author and manipulate large amounts of text: it's the quickest way for me to encode the model in my head in textual, language-oriented form.
To summarize, for me most of the real work of programming happens in my head, and in my experience that's a much more powerful place to work when you train yourself to do it. In light of that, all the "features" of the IDE become bloat and distraction. What I need is a fast, responsive editor that doesn't get in my way.
> 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)
Yes, exactly, and many of those are other good alternatives to Vim. Above is why I strongly prefer text editors to IDEs. I know Vim-style modal editing with basically a language of commands in and of itself is not a good match for everyone's mental model, but personally I'm at the point where I don't have to think when I'm manipulating text: it's all automatic, and extremely powerful. Moreso from a text-manipulation than any other editor I've used. That's why I'm with Vim specifically and why it's so productive for me. Vim+unix has become (over the years) the fastest way to author and manipulate large amounts of text: it's the quickest way for me to encode the model in my head in textual, language-oriented form.
> If you don't understand why so many developers are so committed to Vim
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.
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.
> there's not a damn thing vim can do that an IDE can't
# 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.
# 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.
> Edit text without having to constantly move hands off of the keyboard home row to move the mouse or hit keys like PgUp/PgDn.
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.
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.
I'm much more of an emacs than vim user, but the "wrong IDE" part is not quite true. Most IDEs support the common languages that you've listed, but once you go a bit further into domain specific, it is not as common any more. Speaking of what I'm familiar with (statistics), even SAS is supported in a very spotty manner, or at least was last time I've checked, and this is a popular language that has been around longer than C. At best you would get some limited R support, which really pales in comparison to what you can get in Emacs (and surely vim). Sure, sometimes they have their own IDEs (RStudio is quite good, and so is Matlab's IDE), but they have their own issues. I'm sure the same is true for lots of other DSLs.
I avoid IDE's for three reasons:
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?
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?
Then you don't actually know Vim.
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.
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.
I don't have much experience with Vim, so I don't really have the whole picture here, but I never understood why the examples of Vim's usefulness was appealing. They all seem to be examples of how you can edit text very efficiently, but that never seemed to be a problem for me. When I program, typing speed is never the bottleneck - I spend most of my time thinking about how to implement something, testing it, and debugging it. The actual typing part is a fairly small portion of it. Letting me input the text with like 25% increased speed doesn't seem worth the overhead of internalizing such a complex system. I'd rather work in an environment with good debugging tools and autocomplete system (but maybe those aren't incompatible with Vim; again, I'm not too experienced with using it).
Perhaps it depends on the type of work. I imagine some types of programming require more typing than others. I could see typing efficiency being really beneficial for front end web stuff. I mostly work on game engine things, and rarely does my speed-of-thinking-of-things-to-type exceed my typing speed.
Perhaps it depends on the type of work. I imagine some types of programming require more typing than others. I could see typing efficiency being really beneficial for front end web stuff. I mostly work on game engine things, and rarely does my speed-of-thinking-of-things-to-type exceed my typing speed.
Yeah, I also think it depends on what you're doing.
I'm currently in the middle of writing an application with Java, which is more or less just a GUI to enter things into a database. And both, the GUI code and the database code, is 90% just spelling out the obvious.
I mean, for the GUI code, context-sensitive autocompletion is still important, no doubt, even just so I don't have to type out "pnlInputTimeSpan" and similar all the time, but the naming is relatively consistent, so I could certainly imagine just typing it.
And there is something to be said as well about actually just typing things out, rather than also interacting with the GUI of your IDE. Remembering the name correctly and typing it, to me, feels closer to the core thought process than interacting with the GUI of my IDE.
Lastly, many people tell themselves they edit text all day long, so whatever helps to speed that up, even if it's just a few percent, is going to be worth it in the long run.
I'm currently in the middle of writing an application with Java, which is more or less just a GUI to enter things into a database. And both, the GUI code and the database code, is 90% just spelling out the obvious.
I mean, for the GUI code, context-sensitive autocompletion is still important, no doubt, even just so I don't have to type out "pnlInputTimeSpan" and similar all the time, but the naming is relatively consistent, so I could certainly imagine just typing it.
And there is something to be said as well about actually just typing things out, rather than also interacting with the GUI of your IDE. Remembering the name correctly and typing it, to me, feels closer to the core thought process than interacting with the GUI of my IDE.
Lastly, many people tell themselves they edit text all day long, so whatever helps to speed that up, even if it's just a few percent, is going to be worth it in the long run.
You can easily delete the last 3 words in a line in any other text editor just as fast.
Press End to move the cursor to the end. Then hold CTRL-SHIFT and hit left arrow 3 times to highlight the last three words. Press Delete or Backspace. It's just as fast as typing "$ 3b D" and is far more intuitive.
Press End to move the cursor to the end. Then hold CTRL-SHIFT and hit left arrow 3 times to highlight the last three words. Press Delete or Backspace. It's just as fast as typing "$ 3b D" and is far more intuitive.
Don't even need to highlight the words. Just hit the end-key and then press Ctrl+Backspace three times.
I know. It was just an example to illustrate the sort of syntax that you'll find more of.
If I myself actually properly knew Vim, I would have given you an example that by itself is most definitely quicker than normal keybindings, too. But I figured, if you actually care to understand, you'll see that it's just an example, if you don't, then you won't.
All I know, is that you can find videos of people using Vim well and they're most definitely faster than anyone I've ever seen with a normal text editor.
I know. It was just an example to illustrate the sort of syntax that you'll find more of.
If I myself actually properly knew Vim, I would have given you an example that by itself is most definitely quicker than normal keybindings, too. But I figured, if you actually care to understand, you'll see that it's just an example, if you don't, then you won't.
All I know, is that you can find videos of people using Vim well and they're most definitely faster than anyone I've ever seen with a normal text editor.
There's a lot more physical movement involved in the end/ctrl+backspace method, even though it's fewer keystrokes.
The big thing with Vim's modal editing is that it allows you to have keyboard shortcuts involving keys that aren't way off in the boonies. Some examples:
* / or ? to search for text
* dd to delete the current line
* Stuff like ciw or ci" will delete a word or the contents of a double-quoted string, and drop you into insert mode. I use this one constantly.
When prompted, people try to come up with really crazy complex things, but frankly the bigger thing is just being able to actually reach things.
If I tried to use shortcuts in other editors to the extent that I do in vim, my hands would constantly be in pain. This is why I never got into emacs, though I've seen some folks be terrifyingly fast with it as well.
The big thing with Vim's modal editing is that it allows you to have keyboard shortcuts involving keys that aren't way off in the boonies. Some examples:
* / or ? to search for text
* dd to delete the current line
* Stuff like ciw or ci" will delete a word or the contents of a double-quoted string, and drop you into insert mode. I use this one constantly.
When prompted, people try to come up with really crazy complex things, but frankly the bigger thing is just being able to actually reach things.
If I tried to use shortcuts in other editors to the extent that I do in vim, my hands would constantly be in pain. This is why I never got into emacs, though I've seen some folks be terrifyingly fast with it as well.
Developers are more committed to vi-keybindings than Vim.
Actual developers interact with live systems (see strace), which is exactly what medium is to vim.
I think it's very strange that it isn't actively developed anymore. It had some really gushing reviews. What's keeping people from taking over the implementation?
The thing where this fall apart is try to get away from imperative, predictable code.
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".
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".
One problem with literate programming: a large portion of the industry hates to document, and thinks that comments are EEEEVIL. Not me, but many.
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.
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.
The action-response mechanism reminds me of the Easel programming language:
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.
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.
it looks (superficially) a lot like Elm.
It's more in the logical programming paradigm than the functional paradigm, IIRC.
I really don't understand projects like this. Why can't people just learn to code, in an actual programming language? To me this is like instead of teaching people to read and write you teach them to draw pictures and use emojis instead.
This is something you posted 15 hours ago:
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.
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’m not sure if I’d generalize my own experiences to the general public. Even though I used simple drag and drop interfaces to create programs before, I was also tinkering with HTML and JavaScript, so they weren’t a gateway to real coding. My time spent with actual programming languages greatly accelerated my learning.
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.
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 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.
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.
Is this related to the eveonline game?
No.
You could have clicked the link and found out for yourself in like 5 seconds.
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)