I think what they mean by "human" is non-professional.

All programming tools are for humans. But they're also almost exclusively designed with the expectation that the user will be able to devote afternoons, weeks, months, years to learning the tool. That's a fair expectation if your target audience is programming professionals... If it's your job, you can amortize those learning costs over some months of paychecks.

But that a) creates a high barrier to entry for people to get into the biz. And b) mostly locks out people who want to do just a little programming. I.e. the Excel crowd.

The field Eve is in, so called "end-user programming" is still trying to advance beyond spreadsheets, which were the last big win for non-(professional programmers). Well, HTML was probably in there too. WordPress templates, etc. But spreadsheets were probably the last quantum leap in the field.

We're overdue for another.

> But spreadsheets were probably the last quantum leap in the field.

> We're overdue for another.

I'm working on it, and do think I have a solution. Unlike Eve, for example, you can (and we do) create (almost said "write", but there's no textual code) an OS kernel in it.

And it's nothing like the approach Eve is taking, which I consider to be nothing like why spreadsheets were (and are) successful.

To me, Eve is nothing more than textual datalog programming + a high-level stdlib + a UI wrapper.

The only area we agree is that logic programming is an underutilized paradigm, and in my visual programming environment, I do use it for business rules (where it absolutely excels).

I tend to agree that Eve isn't quite the right direction. The REPL is important, so that's good. And one-click deployment, one-click forking of development environment, those things are critically important. But from there...

I agree the high-level stdlib is a problem. I think what we need is an easy-to-dip-your-toes-into environment that provides a path down into "real programming" and ideally down to metal.

I think the big problem isn't exactly UI or language or high enough level APIs, it's the way the APIs are structured. The two big issues I see with most tools are:

1) tendency to layer opaque frameworks on top of opaque frameworks which makes debugging down into the system difficult, if not impossible. (i.e. React) In this sense I think it's interesting that Eve is trying to build on top of itself. Anywhere there's an opaque layer you are putting a massive learning curve for anyone who is grappling with the finer details of that API.

2) declarative interfaces. (i.e. Ember) These require the programmer to have detailed knowledge of the inner workings of the runtime. Feels like we need tools that are made of primitives that the consumers of the tools have a clear path to understanding. There is this idea that the user will never have to understand how the tool works, but my experience is that you always eventually do. You always need to understand the layer below you, so the task is to make those layers easy to dip into... not to try to insulate your users from the details.

Eve seems to partly fail on both of these.

What does your approach look like?

I agree with you that APIs are where things fail, and without a good solution for that, you're not going to make much progress. I've spent a ridiculous amount of time working on that problem (and do believe I have a solution).

I'll be sure to post to HN when my visual programming environment is ready to use.

Today is Eve's day. :)

That's what I was thinking. I'm a human, I like my Vim and C.

The main limitation of a language like that is that, if you care about performance at all, you have to program for the machine first, not for humans.

You're always writing for both to some extent. For me this is the main challenge of programming; writing code that executes efficiently and correctly, and that is legible to humans.

I love Python and other high concept languages but if I want to code for performance I need to understand what the machine is doing. The tower of abstraction is so high with these languages, at the end of the day it's easier to go, eff it, I'll do it in C, than to try to understand exactly how this code will be executed down at the bottom of the tower.

Yup, and even if you don't care much about performance, you still have higher level languages which are good enough.

That's why I wonder where Eve fits in. Most people don't want to program. And this is NOT because they're stupid. It's because they have tons of other important things to worry about. Most people don't want to build their own TV set. They buy it because their expertise is in other things. Maybe they're a doctor. Maybe they're a fields medal winning mathematician. Heck, I'm a programmer and deal with all kinds of programming languages but don't want to know what's going on inside my TV set.

I haven't looked in depth at Eve, but it sounds like it's a bridge for the people that _do_ want to program but don't want (or even need) to understand the underlying complexity. As a close to home example, I've had several game ideas I've wanted to program for a while. Simple things, I've had notebooks describing behaviors and what should happen when in the game for years. My day job is software development, but I haven't been able to grok a game engine enough to implement playable versions of these games.

In other words, I don't want to build my own TV set but I do want the favorite channels menu on my TV set to behave slightly differently.... perhaps it has profiles for each family member. Conceptually simple but hard as hell to execute from scratch.

I've seen a few of the "excel crowd" comments so far. Could you imagine the performance of this system if they really let a few of the "excel people" make their own charts and graphs like are in that video? It would destroy the system in short order, I'm guessing.

It could be useable, I don't want to dismiss it entirely without even trying it, but honestly the website's text has really turned me off, so I probably won't.

I'm not so sure. Granted, I might write html in vim, but I'd prefer writing Markdown or ReStructuredText. We could have a (subset of) full html in the hn comments - but it'd likely get in the way, rather than be helpful. Medium is a nice way to publish some text with images. Note the "with images" part. Vim is a much better text editor, but I don't think it's a very good hypertext editor. I don't necessarily need WYSIWYG all the time, but an object oriented/rich graphical editing environment certainly has its place.

I'm reminded of the original MVC paper[1] - about presenting an interface that matches the users mental model, through the interactive graphics and back into the computers internal data model.

Earlier it occurred to me how crazy it is that so many of our popular languages work on such primitive data structures still. The most obvious being null-terminated ascii strings in a globalized world - where ascii is effectively always the wrong choice (or at least, "not best"). But I'm thinking more about using any other structure than images, 3d models, databases. Why do we work so often with bare variables? I mean, in embedded programming, I guess it's interesting to think about two's compliment, overflow etc - but really. If we can't even handle numbers, vectors in a natural way - aren't we doing something terribly wrong?

The more I think about it, the more I come to believe that many of the ideas of hypertext, Smalltalk/Object Orientation, HyperCard, CAD/3D programs and 2d drawing packages (as well as decent DTP programs) are on the right track: let us use type information and other meta-data to manipulate structures - both "code" and "data" in richer ways. Let me see my code as a graphical finite state machine/diagaram. Allow me to work with my generated matrix as a heightfield in 3d and as a greyscale image. Let me visualize the steps of my sort algorithm, not just look at assembler in a debugger. Why not show me my stack(s) as 2d or 3d stack(s)? Not all the time, but when I want to?

I do like vim, for editing text, and working with our rather dumb programming languages, that might be considered "text+". But they're not really rich, they are hard to visualize, listen to, paint on. And for some things, that's fine. All we need is some text.

But I would argue most good history books has a few images, and maps. Rich media. Even math books do. Maybe the problem with fourth generation languages have been that they wanted to "fix" programming. Rather than just fix some parts, like Elm, with its natural integration of stepping back and forth in time.

Vim is a great tool - but it may be overspecialized on manipulating text: text objects, lines and letters. Those are not generally the semantic objects of programming (excepting perhaps those that make a living coding in brainfuck). I view lisp as a way to simplify "down" to text. And something like hypercard, smalltalk or the lively kernel project as attempts at simplifying "upward" -- to work with the structure. But that requires something beyond simple, human-readable text. You need to save a workspace, and a memory image. The systems acquire a lot of complexity in order to realize their simplicity.

But in case of lisp, the system is generally rather complex underneath. There's still compilation to machine code. There's still some kind of graphical interface, font rendering. Maybe what amounts to a different operating system who's only job is to boot your operating system that runs your lisp environment...

Personally I don't really think C is particularly simple. I still have to look at the assembly to know what's going on. And if the code ends up running on an Arm, or a CPU not yet invented, I'm still kind of lost. I don't really understand the details of how the assembly I can read, interacts with hyperthreading. In the end, what I really care about is the effect of the code - and that is really something I need to test and measure in the context of a running system. And the complexity of that, is likely so that I end up with sampling under various conditions, and doing some timing runs.

This "eagle view" approach doesn't mean I don't ever think about memory layout, algorithm complexity and such. But it does mean I rather rarely think about what actually happens deep inside the machine and the three cache layers.

[1] http://heim.ifi.uio.no/~trygver/themes/mvc/mvc-index.html

God bless you for being the only one on this comments page (as of right now) to mention HyperCard.

> What's wrong with Vim?

Emacs is better ;) But the comparison is a bit disingenuous. Medium is a blogging platform, VIM is an extensible text editor.

I think they were trying to emphasize that their strength in "readability", hence Medium.

I watched the video, and immediately realized I would never want to program in that kind of environment. The "literate programming" would get in my way.

It would be like having someone follow me all the time and translate my words in realtime right next to me whenever I speak something. (Actually it's more like me saying something in English AND having to translate after every sentence) It's super distracting because I can't focus on what I'm saying because I lose my train of thought.

I would say its closer to the reason we include emoticons in text messages. Text alone loses something from the original intent, so we add emoticons as a way to bring some of that back. Plain code as well cannot express softer yet still crucial aspects of software design like "intent" or "audience" of the subsequent code.

Emacs vs Vim in an unrelated thread, obligatory on HN :) // I concur