Live data from Hacker News

Eve: Programming designed for humans

programming.witheve.com

231–240 of 401 posts

Re: Eve: Programming designed for humans

#231

Earlier quoted context omitted.

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…

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…

> 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.

Re: Eve: Programming designed for humans

#232

Earlier quoted context omitted.

As a counterpoint: the example of the document containing blocks of code inside what looked more like a word document, to me, exactly explains visually what "designed for humans" means in this context, and I think it's well put.

That's not revolutionary at all. You can do that already with tons of environments. Here's one for Javascript, based on Markdown: https://github.com/jostylr/litpro

Can you post a link so that I can try litpro? Or does it need a download and installation?

Re: Eve: Programming designed for humans

#233

Earlier quoted context omitted.

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 pe…

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 embeddi…

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.

Re: Eve: Programming designed for humans

#234
post #32

Earlier quoted context omitted.

As a counterpoint: the example of the document containing blocks of code inside what looked more like a word document, to me, exactly explains visually what "designed for humans" means in this context, and I think it's well put.

You can do this with Jupyter notebooks.

I just tried Jupyter... I couldn't figure it out. Could you post a link to a tutorial that I could use?

Re: Eve: Programming designed for humans

#235

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…

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.

Re: Eve: Programming designed for humans

#236
A suggestion to the designer of the language: do whatever it takes to get rid of those square brackets. They don't belong to a language for humans, not in that quantity. As a bonus, remove also @ and #.

All the rest looks good. Hopefully it will influence other languages to display their inner workings in a more visual way, maybe even the mainstream ones.

Re: Eve: Programming designed for humans

#237

Earlier quoted context omitted.

That's not revolutionary at all. You can do that already with tons of environments. Here's one for Javascript, based on Markdown: https://github.com/jostylr/litpro

Did someone make a rule that everything needs to be a revolution?

Yes, it's called advertising.

Re: Eve: Programming designed for humans

#238

Earlier quoted context omitted.

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…

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…

so basically Java?

Re: Eve: Programming designed for humans

#239
post #144

Earlier quoted context omitted.

So your defense of literate program gives, as a defense, what I would think of as an attack on literate programming: Take this strawman for instance, how could you find the bug in the following code without the accompanying comment? // Print every other line of the array to the console for (var i = 0; i Because the problem with that is that now you have two competing sources of authority -- the comment, and the code.…

This is why comments that specify what the code does are a "code smell". Comments should explain things that are not obvious from the code. Comments should be things like // Note: PCI-DSS requirements apply below // Must check status register and FIFO to determine completion due to flaky hardware // Algorithm below is modified Knuth-Morris-Pratt // This is O(scary), but seems quick enough in practice. (Now, if someon…

Agreed, so then most programming systems are wrong if things are not obvious?

Re: Eve: Programming designed for humans

#240
post #144

Earlier quoted context omitted.

This is why comments that specify what the code does are a "code smell". Comments should explain things that are not obvious from the code. Comments should be things like // Note: PCI-DSS requirements apply below // Must check status register and FIFO to determine completion due to flaky hardware // Algorithm below is modified Knuth-Morris-Pratt // This is O(scary), but seems quick enough in practice. (Now, if someon…

You didn't solve the OPs problem, you just moved it around. In his case, his algo said X, and his code did Y.. very easy to see the mistake. In your case, lets add a comment // Note: PCI-DSS requirements apply below Now 3 years later, the law changes and the requirements do not apply. So you are at the same situation. Code does X, comments say Y. Which is right? Not a very easy to keep comments and code in sync

My approach to this is that the comment can almost always be turned into a text. A test class called FooPCIDSSCompatibility with tests for all the bits both defines things more strongly and will start failing if you ever break it (either accidentally or because it is no longer required). Either way you need to update either code or test to get through the build process.

Comments can be useful for annotating algorithms or referencing stack overflow though.

Post reply on HN