1. 21
  1. 4

    [Repost of my review on Hacker News article on Eve. An Eve developer emailed me saying I pretty much nailed what they’re doing. So, I repost as is except adding Smalltalk as promised.]

    The meat is that most programming languages are not designed for humans. Many weren’t designed at all so much as hacked together for context they were originally used in with terrible consequences for learning or effective use by average person. C and early PHP probably lead that. Many others were affected by committee thinking, backward compatibility, preference of their designer, or the biases of people who previously used hacked-together languages. There’s few languages where someone or a group sat down to carefully engineer them to meet specific objectives with proven success in the field at doing those. Examples include ALGOL, COBOL, Ada, ML for theorem proving, BASIC/Pascal for learning imperative, and some LISP’s.

    So, if we’re designing for humans, what does that mean? It means it should easily map to how humans solve problems so they can think like humans instead of bit movers (aka machines). BASIC, some 4GL’s, COBOL, and Smalltalk were early attempts at this that largely succeeded because they looked like pseudo code users started with. Eve appears to take it further in a few ways.

    They notice people write descriptions of the problem and solution then must code them. The coding style has same pattern. They notice people have a hard time managing formal specs, the specifics of computation, error handling, etc. So, they change the style to eliminate as much of that as possible while keeping rest high-level. They noticed declarative, data-oriented stuff like SQL or systems for business records were simple enough that laypeople picked it up and used it daily without huge problems. They built language primitives that were similarly declarative, simple, and composable. They noticed people like What You See Is What You Get so did that. Getting code/data for something onscreen, being able to instantly go to it, modify with computer doing bookkeeping of effects throughout program, and seeing results onscreen is something developers consistently love. Makes iterations & maintenance easier. They added it. Their video illustrated that changes on simple apps are painless and intuitive compared to text-based environments with limited GUI support. Their last piece of evidence was writing their toolchain in Eve with it being a few thousand lines of code. Shows great size vs functionality delivered ratio with the quip about JavaScript libraries being bigger illustrating it further.

    So, there’s your meat. Years of doing it the common way, which wasn’t empirically justified to begin with, showed that people just don’t get it without too much effort. Then they keep spending too much effort maintaining stuff. Languages like COBOL, Smalltalk, BASIC, and Python showed changes to syntax & structure could dramatically improve learning or maintenance by even laypersons. Visual programming systems, even for kids like with Scratch, did even better at rapidly getting people productive. The closer it matched the human mind the easier it is for humans to work with. (shocker) So, they’re just doing similar stuff with a mix of old and new techniques to potentially get even better results in terms of effective use of the tool with least, mental effort possible by many people as possible with better results in maintenance phase due to literate programming.

    That’s my take as a skeptic about their method who just read the article, watched the video, and saw the comment here by one of project’s people. I may be off but it all at least looks sensible after studying the field for over a decade.

    1. 1

      Every time I see a piece about Eve, I get a little more excited. But at the same time, since I haven’t played with it yet, it sounds almost too good to be true.

      Am I alone in this feeling?

      1. 4

        It’s a beautiful language, and I’m impressed with everything they’ve accomplished, but it definitely still has some rough edges: there’s no data-type conversion functions, no way to define your own functions without falling back to JS, and other quirks like that.

        (This is true of the last version I played around with. Someone please correct me if I’m wrong.)

        1. 6

          [Eve member]

          That’s absolutely true. It’s pretty rough around the edges. There’s a whole heck of a lot that still needs to be done and we won’t claim it’s anything but 0.2.* at the moment. :) We’re working through these things as we start to build bigger/more real examples.

          here’s no data-type conversion functions

          We’ve added a couple via convert[value: some-string to: "number"]

          no way to define your own functions without falling back to JS

          That’s true at the moment, but you end up wanting functions pretty rarely in the language so it hasn’t been a priority for us.

          1. 1

            Thanks for pointing out some rough edges. I guess my biggest gripe is that the articles that keep getting posted seem to make it out like it’s all roses and sunshine.

            1. 1

              I’ll email them to see what they say about that. And/or send a developer an invite. Might be interesting people to have in discussions here.