Hacker News Reader

Comment by jbclements | Hacker News Reader

I think that Eve is tackling the wrong problem.

Allow me an analogy: "Bronk, the math designed for humans." Instead of dense algebraic expressions like "3x+49", you get to write "thrice the value of x plus 49." You may consider this a straw man, but I think that if you look hard at existing programming languages, you'll see that they are all designed for humans, and that the challenge in programming is in formulating your thoughts in a precise fashion. Should languages create higher-level abstractions to allow humans to reason about programs more efficiently? Yes! But that's not what this environment is about.

I do see one possible rebuttal to this, which would be an entirely different form of programming that is to traditional programming what google search is to the semantic web; that is, rather than specify programs precisely, we give examples to an approximate system and hope for the best. In many ways, that's how our biological systems work, and they've gotten us a long way. I don't see that happening in Eve, though.

View on HN

This seems to always happen when people try to make programming "more human". Programming languages succeed by walling off ambiguity. The better and faster they do it, the stronger the language, even if the syntax looks ugly.

Even your example shows it instantly. We know how to read 3x+49 but would have to ask of "thrice the value of x plus 49", "did you mean 3 times what you get from adding 49 and x or 49 more than 3 x's?".

Projects to humanize programming always seem to suffer from "magic genie" syndrome. When you ask a genie for $1mm you don't expect him to go rob a bank or kill your dad for his life insurance to get it. Human language makes tons of implicit assumptions about the recipient. It would take a general (strong) AI to make that work with a computer.

The ultimate expression of success would have your "program" simply read "I'd like a game just like Flappy Bird but with my logo instead of the bird".

Actually, we agree completely with this view. We tried going down this path [1], and ultimately concluded it was the wrong direction, for many of the reasons you point out here.

But Eve is a full programming language. The "humane" aspects are not about making the language more ambiguous, but about changing the focus of tooling from the machine to the human. It's about things as simple as Unicode support for language localization. Or rendering headers in your code. It's about making the syntax and semantics very small and easy to understand. It's about closing the write-compile-test loop, by showing the result of code /in/ the actual code. It's about debugging tools that work with you to solve a problem.

We're just saying we don't want to compromise. We want a beautiful, concise, easy to understand language AND we want humane tooling. In order to get that, we had to abandon the traditional imperative programming model, and that comes at a cost. But I think in the long term it will be worth it.

[1]: http://incidentalcomplexity.com/2016/06/14/nlqp/

I was initially confused by the "human" line too, but once I looked at the video and the examples I understood what you guys are trying to do.

There are a lot of really interesting approaches there. I really like the ideas!

I think a lot of service devs (read: stateless) won't get it. But people who code front end and deal with business logic daily might find something to love in here.

Worth discussing if nothing else! You got my star!

>changing the focus of tooling from the machine to the human

>It's about debugging tools that work with you to solve a problem.

>we want humane tooling

I know how hard it is to explain what exactly your product does. I myself constantly struggle with this. Eve is an interesting concept that is worth a closer look and discussion. But you guys need to learn how to explain its benefits using a less ambiguous language.

Well the linked page and videos explain the benefits of the current release pretty well. They should take less than 30 minutes to view. I think part of the reason they use ambiguous language is they see this programming language as the first step in achieving a series of more ambitious goals. They've also been writing specific prototypes which they also believe work toward these goals for the last two years.

...So, literate Smalltalk. Or literate Lisp.

so basically Java?

No, basically COBOL, which supposedly was a pogramming language so easy to use that managers could code the problems themselves without those pesky programmers that slow everything down all the time.

Good tooling, easy to understand, unambiguous? Sounds like Java.

Why can't people just use Java?

Must be a server-side dev. Java client-side trainwrecks include: struts, tempest, Java Server Faces, AWT, Swing.

True it's unfair to blame Java alone for these, because client side is more difficult-- we've been searching for solutions for decades in a variety of languages.

Modern front-end is a mush of dozens of tools/contexts, etc. Way more complex than TeX, and way less reliable and with minimal debugging context. But as the Eve guys have said, we're using the same layering of precompilers and interpreters we've always done. It's a mess because it's not just Java (or Python or Ruby) it's CSS HTML JS XML JSON, and the whole rest of the alphabet soup.

It's about time we reconsider platform as a whole again rather than merely a sum of fragments. That's why I find Eve interesting.

there's quite a lot of bad practices surrounding the language back from where the enterprise tooling was a mess and xml was the rage, we're ten years past that but the language hate has never ceased (see my comment: -1)

I get the hate from the frameworks craze, but if one is in a position of being forced a crazy bloated framework without recourse that's not Java fault.

apart from that, you can debug servers the other side of the world with ease, hot replace code as you execute it, walk the heap with a lot of different views available, it has recently got top notch profiling, a sane injection and inversion of control framework which you can still debug at runtime, all the libraries you can dream of and bridges to hardware for the most demanding tasks.

I have held out since I love the language. I started using Java when it was new and actually very pragmatic and useful. Hated the enterprise phase, got bogged down by it but rose from the ashes. Now I'm a strong proponent of simplicity and libs over frameworks. And Java has great speed and simplicity for most tasks when memory management isn't a problem. But it's a constant struggle against old values in the business. And it doesn't take many conservative and bureucratic people to ruin a creative crowd. So I am looking to jump ship to what I consider in many ways inferior languages just to be able to be part of a modern culture.

To be clear, I still work at a company which is extremely forward (in averyting in beta sort of way). But still these old values hold everyone back and cause endless discussions of frameworks, processes and control structures vs creativity and speed.

What do you think of Scala?

Java? What a horrible language.

How so? (Just genuinely curious as I always here this) I have asked the Java developers at my job if they have this common mindset and they don't seem to agree. I don't work with Java that much so I'm just honestly curious.

Java is a great virtual machine, a good collection of open source libraries, an ok language, and a nightmare collection of best practices and people who enforce them.

I don't have a beef with the language, it is the developers who have never programmed in another language and still think that FactoryBuilderImpls are a good idea. They have never ventured outside of an IDE, but insist that Python isn't a real programming language. I can program Java but I never want to program with "Java developers" if I can help it.

That in a nutshell is why I said Java is a horrible language.

That said, people with a strong preference for a particular language are comparable to religious fanatics. A good engineer doesn't let language preference and emotional attachment to something get in the way of building something better.

If learning something else is too uncomfortable or seems unecessary to you then you are no better than a religious person.

btw, before I get downvoted the "religious person" analogy was what a senior developer said of me when I was a .NET guy a long time ago.

note: the same applies to the religious sects who worship libraries and frameworks (Mostly front-end Javscript web developers)

Your message could still be effective (or even more effective) without putting down "religious people".

He said religious fanatics who are also people but a niche inside a religion. What is wrong with that as it rings through? Both defend something mostly without bases with extreme vigor and energy.

Yes! I program PHP because I feel it fills a spiritual void for me.

I'm a Zend-Buddhist.

Cannot edit the post for some reason, but sleepy this morning and not native English ; rings true of course.

There's certainly no shortage of crummy developers layering on useless abstractions for no reason other than dogma. Don't worry, soon all those young and thoughtless developers will be coding in nothing but JavaScript, and the crufty Java die-hards will be pumping prime contracts to migrate old Java business engines well into retirement.

Java is incredibly verbose and does not support many modern paradigms very well (see Rx and streams). For that sort of OOP language, C# is far better. The JVM is excellent, however.

> Or rendering headers in your code

Sorry, you lost me right there. If you need headers, you've already run off the rails (no pun intended) IMHO.

Headers as in document headlines and literate programming not as in header files.

Thanks for pointing that out. I was wondering why I was getting so many downvotes.

You seem to conflate "allowing ambiguity" with "not requiring specification of extraneous detail."

It is not a new mistake. Many people thought that programming with GC, or with high-level languages, or with generics, was just a kind of magic that couldn't lead to understandable programs. But these things succeed because, while they allow you to stop worrying about certain details, they do so while still remaining perfectly well-defined and unambiguous.

The fact that you no longer can know how the low-level details will be handled can be very uncomfortable. If there is most of what you have spent your programming career doing, it seems like it must produce ambiguity and inefficiency. But this isn't generally the case. Optimizing OCaml compilers can often produce code faster than C simply because the higher level of expression expected from the programmer leaves more room for the implementation to generate the right low-level code.

I won't say that I know Eve will be successful, but it certainly is possible. It produces unambiguous behavior which just happens to no longer specify lots of details most programming environments make you think about. When I think about the work I do, most of which involves providing live representations of data, and executing certain rules when it changes, I would guess that most of the details I worry about are extraneous and could be dealt with by a sufficiently-smart environment that encompassed both the database and the program.

I would say that GC, generics, and maybe even HLLs are useful because they are tools to constrain the set of possible states the program can possibly enter.

When your language and runtime provide good tooling for constraining the state space, then that allows you to elide specification of those extraneous details.

E.g., some form of GC is a basic runtime requirement for most of the HLLs today. They could almost not exist without it.

Absolutely agree. Similarly, I think we are finding that if you want to program reasonably on distributed hardware or over state spaces too large to hold in memory, you need a programming environment that constrains your ability to specify that things happen in sequential order, or to specify details about how you listen for events or get access to data directly.

Eve may not turn out to be the right abstraction away from details. But the parent comment complaining about the details it takes away from the programmer is probably on the wrong side of history.

I'd say that the details still exist but they've been handled with a very powerful idea which is sane defaults triumphing over endless required specification. In most cases you still can reach the minutia, you just usually don't need to.

There's a difference between producing unambiguous behavior given a specific input and making it easy to create that input in the first place.

I'm with you along the lines of embedding defaults to reduce the boilerplate code needed to get a minimum working app, but there comes a point where this may end up requiring advanced coders to learn how to go deeper in order to override those defaults to get novel results. This could result in a language thats easy for a beginner to get started in but difficult for the intermediate to progress any further.

That sounds like a good description of operating systems, programming languages, databases, or any of dozens of other abstractions that work great, enable people to use them as black boxes without worrying about the details, and also are rewarding to customize or hack on internally for the small subset so inclined.

If that's what this is, a new field outside "programming" that allows an order of magnitude more people to author behavior for simple systems, that'd be amazing.

There are improvements that can be made though - I think one of the best articles I've read about this was here: http://worrydream.com/#!/LearnableProgramming.

Lots of things that show tools and ideas that would make learning programming a lot easier.

> When you ask a genie for $1mm you don't expect him to go rob a bank or kill your dad for his life insurance to get it.

Well, maybe not the first time. But players in my campaigns tend to learn quickly.

It's unfortunate the parent is the top comment here. There's a common thing that happens when a new idea shows up that doesn't easily fit into existing categories:(most) people give it a cursory look over, and then decide it's just another instance of boring category X.

This is especially common in discussions about humanizing programming. I think it's partly because people are invested in the current way of doing things, having spent so much time developing their particular skills; and partly because our attempts at serious alternatives have largely been failures, so far. That makes it easy to see any new idea in this space and automatically class it as already understood. But there is room between C++ and toy visual languages, and someone may find something good there yet—and this will illuminate things just that much more if nothing else.

Look into the lineage of ideas the Eve team have moved through to get where they are today, and you've got to admire their search process even if you don't like the results.

In any case, it's patently false that Eve's innovation is analogous to the algebra example given in the parent.

After spending half an hour reading the article I feared the comments would be like this.

The concepts here are fantastic. Unfortunately, as intelligent as they are, many in this industry seem to have difficulty grasping the benefit of user-focused design, abstraction and simplicity.

UI design by CS engineers has always been terrible; programming languages are no exception to that.

It isn't virtuous to suffer unnecessary complexity. And programming shouldn't be complex just because we can manage it in spite of the complexity.

There's still code here, the text is just for people, so I wonder if this is maybe a misunderstanding.

The language presented is a variant of datalog and is as formal as any other language. If you're curious in the semantics, they boil down to Dedalus [1].

As a simple example of that, here's a clock: http://play.witheve.com/#/examples/clock.eve

[1]: https://www2.eecs.berkeley.edu/Pubs/TechRpts/2009/EECS-2009-...

For an introduction to Dedalus with less reading, Peter Alvaro's 2015 Strange Loop talk was fantastic.

https://www.youtube.com/watch?v=R2Aa4PivG0g

---

Edit: Actually Chris Granger gave an Eve talk at the same conference. It's interesting to see how Eve has evolved since.

https://www.youtube.com/watch?v=5V1ynVyud4M

I think the intent is clear for people with preexisting familiarity with the same ideas. A clojure dev with some datomic. I read declarative, set oriented, database of facts, pattern matching and thought 'the revenge of prolog then'.

This is really nice work. I mean this in the best possible way: I think I could teach my children to use this.

Actually Chris Granger was heavily involved with Clojure. David Nolen gives a great shoutout to Chris Granger and Eve's predecesor, Light Table at minute 17:00 a couple of weeks ago at the Clojure TRE conference:

https://www.youtube.com/watch?v=mty0RwkPmE8

Another implementation of the clock demo

http://www.red-lang.org/2016/07/eve-style-clock-demo-in-red-...

"You may consider this a straw man, but I think that if you look hard at existing programming languages, you'll see that they are all designed for humans, and that the challenge in programming is in formulating your thoughts in a precise fashion."

Non-programmer: OK, Eve sounds great, so, I want to search for a Slack message. How would I do that?

Eve-programmer: Obviously, it's just:

    search @slack
       [#message from body]

Non-programmer: Ummm...OK, great. So now if I wanted to, say, send an email.

Eve-programmer: Easy! In the same way, you just:

    commit @email
      [#email to: "corey@kodowa.com"
              subject: "It's party time!"
              body: "Hey Corey, the party starts this Friday."]

Non-programmer: ...

The challenge of programming has always been wrapping your head around very formal abstractions and "thinking like the machine". These Eve snippets still look very much like a programming language to me. I don't think they will mean anything to a non-Eve-programmer without training in the semantics of how Eve programs work and the syntax of how to build the expressions, and the model over which the operate.

Eve very well may be a big productivity advance over current development environments, but I don't see it eliminating programming as a profession anytime soon.

This milestone is very much about making a programming environment, so you're right, that's still code. Though to address this strawman, compare that to what you would write in Java or even Python. Some of the best comments we've gotten is when we've shown people eve code and told them to ignore the symbols, just read the words. Their eyes really open up and they tell us pretty exactly what the block is doing. No, it's not all the way there, but that's a big step forward.

In any case, check out our followup on what Eve is and isnt [1] - we're under no delusion that this is the end user story... yet :)

[1]: http://programming.witheve.com/deepdives/whateveis.html

The "ignore the symbols and just read the words" idea is part of Ruby's promise as well. In practice, I don't personally find it very satisfying, because it's easy to write things that read like they do one thing, but actually do something else. So you have to train yourself to ignore what it says until you figure out what it does.

I think the better metric to optimize for is how easy it is to go from seeing a piece of code for the first time to having a mental model for what its runtime behavior will be. Do you think Eve is strong on this in addition to its "readability"?

> I think the better metric to optimize for is how easy it is to go from seeing a piece of code for the first time to having a mental model for what its runtime behavior will be

Actually yes, we've seen some evidence of this. In one instance, I was demonstrating the syntax of Eve to someone who really only had experience programming HTML, and he was able to point out a bug in my code without even running the program.

I believe this is because the syntax is very minimal, there are very few core language operations (only 9), and the underlying data model is completely consistent throughout the language (everything is a record). You can only query and update records. When you only have a few consistent tools, you can wield each one with greater confidence.

Also, in Eve if you want to know what a block does you can just ask for the output right next to the block, so there's no guessing. You can look at it as text, a table, a chart, or any number of visualizations you can come up with. When you have the output and the source code right next to each other, updating in real time, and recompiling automatically as your code changes, you can get a better sense for what each individual part does in a block of code. You can even point at a specific element and ask "What draws this". We hope that all of these features will encourage new users to feel the freedom to explore, make mistakes, and build their own mental model of how Eve works, without having to understand set theory.

Thanks! I hoped that was the case.

Fair enough, but I thought an earlier goal of Eve was to bring programming to non-programmers? Did that change as Eve evolved, or am I just mis-remembering?

It is, but it's a multi-step process. :) Checkout the three milestones at the bottom of the post: http://programming.witheve.com/#justataste

If we can eliminate software engineering as a profession our work will be done. There will be nothing left for humans to do, because at that point we will have invented a General AI.

Up until that point, software engineering will be a well paid job. I really don't understand this attitude that everyone should be a programmer or that programming should be easy. It isn't easy. Obviously, we should remove unnecessary friction from the process, but framing your thoughts precisely takes discipline. Building maintainable systems takes practice and understanding. It takes years of study and work to become a good engineer.

I definitely think people should be exposed to programming in school, but we study physics and chemistry there too and nobody expects everyone to be a physicist or chemical engineer. Specialization is a good thing.

That said, I'm down to compete with whatever you people think can replace me. I love a good challenge.

nobody expects everyone to be a physicist or chemical engineer. Specialization is a good thing.

The difference with software engineers is that they have the power to build their own tools; physicists and chemical engineers largely don't, unless they themselves are also software engineers. You aren't going to use knowledge of chemistry to build general software but you can always find a use for software engineering in any domain. This puts it in the same category as literacy and mathematics, rather than strictly being a specialization pursued toward its own end.

Don't quote me out of context

I am saying that people should be taught programming in school, like literacy and mathematics, but that doing so is not going to prepare students to make production-grade software. We need actual engineers for that.

It's not unthinkable that a language, by design, facilitates or enforces precise definitions.

As a far-fetched example, think of Lego. You can't "fail to compile" your Lego bricks. You have a finite selection of bricks (all clearly visible and usually available within arm's reach), and your job is to just lay one at a time. Given any brick, it's "obvious" to a human how it fits with other bricks. The worst you can do is essentially create a crappy Lego design. As you noted going from a rough thought of

"Uhm I want to build a Dragon of about this size..."

to a finished build requires a powerful AI. But we don't need to go that far to be better than

"Place $brick1 in p=(32,17) at orientation o=(0,pi); place $brick2 in p=(38,15) at o=(-pi,0); ..."

The rigidity of the bricks inherently prevent you from overlapping them, but not the above declaration :)

Not at all. Good tools are very important, and we shouldn't stop working to make them better. What I disagree with is the idea that good enough tools can replace engineers without them becoming General AIs. Until we get to that point, there will be systems that need to be built that only professionals are qualified to work on. I'm not saying that we need licensing boards or any of that nonsense, just that nobody is going to merge poorly constructed code into an important project.

I don't think it was implied good enough tools can replace qualified engineers. But I feel sometimes engineers don't realize that tools can not only be valuable for beginners (itself worthwhile, imo) but actually make experienced professionals more reliable (less error-prone) and work faster.

Taking the Lego analogy further, even if I, an experienced Lego builder, can construct a set entirely in my head, and write a correct assembly script, building it physically is likely faster and certainly less error-prone.

Those kinds of goals are hard to achieve with software (especially considering what we have is already pretty good!), but I think they're a worthy pursuit.

Examples of language/interface design that seem strictly beneficial: (regardless of experience or project)

- Showing the result of [valid] code changes as soon as possible (a feedback problem);

- Disallowing invalid expressions (a consistency problem);

- Displaying relevant components (functions, libraries, APIs, variables, etc) (a visibility problem);

- Bringing documentation closer to code (making functionality obvious)

Eve tries to tackle some of those challenges, especially the documentation problem and the visibility problem.

Solving those issues can both improve productivity and bring more people into programming.

Okay, but who is your customer, the engineer or the layperson? At a certain point, our needs are going to pull in separate directions. Simple is good, but certain problems have a baseline of complexity that can't be eliminated. Who are you planning to side with?

You would be surprised how non obvious Legos actually are to people not familiar with them already.

This is akin to thinking doors are intrinsically intuitive. There is actually a ton of training that kids go through for that "intuition."

I don't understand your example. If you abstract away the hard part of searching a database and sending an email (as most programming languages do), then every language is as easy as the snippets you posted. In python:

    messages = slack.search()
    email.send(to='corey@kodowa.com', subject='hi', body='yo')

Are you saying that Eve removes the difficulty of interfacing with external programming systems? If so, I haven't seen that in their documentation... For one, you still need to know HTML to do anything useful.

On my first admittedly unfair impression I feel the same way, but I'd love to be proved wrong. Chris Granger is a serious programmer whose work deserves careful consideration.

This is just a dsl, you can write easily something equivalent or even better in other languages, but doesn't really tell you anything about the underlying language. What is the difference with:

    let messages = search slack_message body

to me this version seems more readable without the square brackets, hash and @ distractions. Why as a non programmer I would ever want to know when to use @ instead of # and when to put square brackets? I think that the F# version that I posted it's easier to read and to write for a non programmer.

No, it's more than just saying let messages = search, as in eve this is being run whenever search changes, whereas in other languages it is run when you explicitly call it

Now this sounds very dangerous - one of big problems of declarative style is that it's too easy to accidentally build a system that does much more than you intended, totally killing performance.

There is a very, very big difference between running a search once and re-running it whenever search changes; if you want it one way then you definitely don't want it the other way and that would be a serious problem.

That's not a "in this language" issue, you can do both ways in any language, but this choice you made should be (a) explicit and (b) obvious, which it doesn't seem to be in this case; where a reader can reasonably expect the search to be run once.

Actually in Eve it is explicit, there is bind and then there is commit:

http://docs.witheve.com/handbook/bind/

Did we read the same article? Were you somehow mistaking the comments for code? The actual code is pretty clearly based around some well-defined deterministic semantics and still demands precision and consistency from the programmer.

And moreover its promise appears to be exactly "higher-level abstractions to allow humans to reason about programs more efficiently", in direct opposition to what you wrote here.

EDIT: Of course programming languages are designed for humans... they wouldn't exist otherwise. But they also tend to be pretty strongly influenced by the imperative nature of assembly language. The Eve team seems to be asking: What if we ignored that entirely? In a way this seems a lot like a spreadsheet - you can write a lot of little code blocks that aren't executed in any particular order and yet produce deterministic results.

Is this a response to the literate programming aspect of Eve that's presented? The actual datalog code that is written seems quite succinct for what it accomplishes.

The math example is more informative when it's not something trivial. For example, take the following notion about a sequence of X:

∀ e, ∀ d, ∃ N : ∀ n > N, P(|Xn - Y| > e) < d.

A more human way to say this is that eventually, we will become arbitrarily confident that X is arbitrarily close to Y. This is the notion of convergence in probability, and the formalism of that concept is way easier to process with a little human explanation. Density of notation helps sometimes, but not always. When the math isn't trivial, it's the case here too.

"..rather than specify programs precisely, we give examples to an approximate system and hope for the best."

I agree with this, as it has the most potential to bring an entirely new paradigm to software development.

I've been working on a research project like this, using genetic algorithms to write programs. Unit tests are used to guide the fitness. The AI discovers a solution program that satisfies the test cases.

Using Artificial Intelligence to Write Self-Modifying/Improving Programs

http://www.primaryobjects.com/2013/01/27/using-artificial-in...

Eve's goal (or more correctly, "vision") is to "bring programming to the masses". [1]

>Should languages create higher-level abstractions to allow humans to reason about programs more efficiently? Yes! But that's not what this environment is about.

Uh, ok? It's certainly about more than that, but the language is built on high-level abstractions, making at least certain class of problems very efficient to reason about.

> ... that the challenge in programming is in formulating your thoughts in a precise fashion

Yes, one might say that the real problem[1] is how to teach people programming quickly. I'd say that a good environment is likely to be an important part of any solutions to that problem though.

It will not be the whole solution though. People will have to put in some work, and at some point improvements in environment/language will see diminishing returns. At that point you'll need better/new pedagogic techniques too reduce the learning time.

When that point is reached is unknown. I don't think it's there yet, but maybe it's not so distant.

If the we restate the problem to "how to make as many people as possible learn programming" some type of gameification is probably an efficient solution.

> Should languages create higher-level abstractions to allow humans to reason about programs more efficiently? Yes! But that's not what this environment is about.

I think it actually is. Under the hood, when you look beyond the "Literate programming is awesome" it seems to be more along the lines of terse reactive prolog?

I am not sure if they managed to do what they envisioned, but this might be the "next spread-sheet".

On the other hand, if density were no problem at all, everybody would be using APL/J/Kx, and that isn't the case either.

I don't think that's a fair characterization at all. This isn't just a wordier way to say the same thing. It's a much more declarative way of expressing what code should do.

The global invariant example is a good one. That's not just expressing the same thing less tersely.

> that the challenge in programming is in formulating your thoughts in a precise fashion

Were you thinking of Notation as a Tool of Thought?

http://www.jsoftware.com/papers/tot.htm

This is exactly the argument I give when people ask why programs can't be written in plain English. The first reason is obviously ambiguity - programming languages let us express computation precisely. But the other reason is also for general productivity in being a programmer.

There was a not-so-distant time when mathematical theorems were expressed in plain English, without any precise notation. With the introduction of more precise ways to express mathematical statements and logic, mathematics has proliferated, since there is a standard to express problems and results.

While I love toy models as toys, I don't think there is a real use case for toy models in a professional development workflow.

I'm sorry but your algebra as English prose analogy makes me think you haven read the article. I could be wrong of course, but i don't see how you could draw that analogy after seeing the Eve code snippets on the page.

You may consider this a straw man, but I think that if you look hard at existing programming languages, you'll see that they are all designed for humans, and that the challenge in programming is in formulating your thoughts in a precise fashion. Should languages create higher-level abstractions to allow humans to reason about programs more efficiently? Yes! But that's not what this environment is about.

I think you're on the right track when you said "thoughts in a precise fashion"

Humans don't think in a precise fashion. And that's why I think pattern-matching with "give examples and hope for the best" is a way forward.

Think about how we program. We are given requirements and we noodle about it for a bit and start writing some code that is nowhere close to what the final source will be.

When I think about pattern-matching within the context of Eve, I think of automating the way us, as humans, go about our programming. We have some idea of what we want to do, and typically we need to google stuff for APIs and examples. Let's automate that to a certain extent. Let's use the machine learning advances that have happened in the past decade to automate much of the "research" that we all do when we program.

As a programmer, I'm still surprised how luddite-like we are when it comes to our tools. Many of us still are still in the "programming language + text editor" = "programming".

But most of us use tools to help use look for definitions, to do refactoring, to explore our code base. We need to take that to the next level, where some fuzzy logic is used by our programming systems to say "yeah, I think I know what you mean, are any of these examples close to what you're getting at?"

I think it's all about the tooling these days. We need much more advanced tooling to help us out.

>Think about how we program. We are given requirements and we noodle about it for a bit and start writing some code that is nowhere close to what the final source will be.

That is not how one writes software...

That's exactly how I do it. Play around with the problem, and once I've messed with it a bit, take a step back and plan out the right way to do it. Sometimes my "proof of concept" doodling will have salvageable bits. Very rarely (or if it was an easy requirement) the play code will be close to ready. Sometimes, I have to throw it all away. Such is life.

OTOH, it is how one prototypes software. "Build one to throw away" is totally a thing.

The comments don't define the syntax, so your example doesn't provide much oomph. I don't consider it a strawman, I consider your argument to be based on a misapprehension.

I agree. I also think something like Unity3D came a lot closer to solving "programming for non-programmers". You can create quite complex projects without writing a single line of code.

Reply on news.ycombinator.com