Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Eve: Programming designed for humans

programming.witheve.com

Post reply on HN
Print view View original

121–130 of 401 posts

Re: Eve: Programming designed for humans

#121

Post by eternalban »

choward wrote: post #89
computerphage wrote: post #82

Earlier quoted context omitted.

This is the almost the same example. Function names also don't execute. The parent's point was that if the code has been tested or was considered working, and then you noticed this in the code, you should think twice before "fixing" the behavior to match the comment or function name.

Then why even name anything? Are you saying I should just name my functions and variables a, b, c, d, etc.?

Of course names are important to us, human programmers, but the compiler doesn't given an 'f'.

Re: Eve: Programming designed for humans

#122

Post by dsp1234 »

Pyxl101 wrote: post #48
zenobit256 wrote: post #14

Earlier quoted context omitted.

I'm sorry, but that doesn't give the connotation that it's "designed for humans". Perhaps if they could give a clear indication of what that means other than "it's in a word document", I'd be more inclined to look at it a little harder.

Watching the video is probably the best way to get an understanding of what it's about. It's hard to describe an "experience" with text. Their video made more sense to me than most of the written explanation.

It's hard to describe an "experience" with text.

That's kind of the the thing that literate programming is trying to solve[0]. But if the experts aren't able to do it for their own product, what chance does a random programmer have with their own code?

[0] - https://news.ycombinator.com/item?id=12818653

"When we communicate to one another face-to-face, we use gestures, expressions, intonation, etc. to articulate an idea. On the internet, when we communicate with just text, much of my meaning is lost forever and never apparent to anyone who reads this. Programming is much the same way."

Re: Eve: Programming designed for humans

#125

Post by 6DM »

ibdknox wrote: post #2

Hi All! Many of the folks here have been following us for a long time and we're really excited to finally pull everything together to show you all where our research has taken us. Eve is still very early [1], but it shows a lot of promise and I think this community especially will be interested in the ideas we've put together. As many of you were also big Light Table supporters, we wanted to talk about Eve's relation…

I don't know if you got this far, but what would deployment look like? You showed a flappy bird clone, does that mean this will produce mobile apps?

Re: Eve: Programming designed for humans

#126

Post by the_af »

choward wrote: post #89
computerphage wrote: post #82

Earlier quoted context omitted.

This is the almost the same example. Function names also don't execute. The parent's point was that if the code has been tested or was considered working, and then you noticed this in the code, you should think twice before "fixing" the behavior to match the comment or function name.

Then why even name anything? Are you saying I should just name my functions and variables a, b, c, d, etc.?

That's an extreme position. Function names are a valuable hint of what the function is supposed to do. But if the name doesn't match the implementation, which one is wrong? We don't know.

Re: Eve: Programming designed for humans

#127

Post by cmontella »

ifdefdebug wrote: post #87
CGamesPlay wrote: post #76

Earlier quoted context omitted.

Wait, what? The code is a translation of a requirement to an implementation. The comment describes the requirement. The only problem with competing sources of authority is when the comment disagrees with the real requirements of the programmer/business/whatever. As another example, what if it were a method name instead of a comment? function printEveryOtherLine(myStringArray) { for (var i = 0; i Is your argument that…

Well no, I think the argument is that this kind of comment gets outdated easily, so if the program works as expected, the comment is probably outdated (new requirement, the program was changed to print every line, forgetting about the comment). If the program does not work as expected, then it's a bug and the comment is still valid. This does not happen in your function name example: if the program requirement change…

> if the program requirement changed to print every line, no sane programmer would change the code in this function they'd write a new function printEveryLine() instead and use that.

I'm not sure I understand the distinction you are making here, so I'd like to try and understand. From my perspective, function names are just another form of comment. After all, in many languages, as soon as you press "compile", your function names are mangled into something a machine can understand.

So you feel that programmers are more inclined to treat the function name as an authority, as opposed to a comment. Is that an accurate? I'm curious what lead you to this conclusion.

Re: Eve: Programming designed for humans

#129

Post by eternalban »

sbuttgereit wrote: post #107
mkozlows wrote: post #36

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

I don't know that I really agree with this criticism. I don't think having the additional context gives you two authorities which you are helpless to reason about. The code will tell you what is happening regardless of what is intended, the comments will tell you what was intended regardless of what is happening. More often than not, having both of these pieces can tell you where inconsistencies in the larger picture…

The criticism is valid. I have yet to encounter a comment in production code that projects future intent for a piece of code, but having comments lag behind revised code is all too common. Comment rot is one of the motivating reasons behind 'sparse comments' school of thought.

Re: Eve: Programming designed for humans

#130

Post by the_af »

lnanek2 wrote: post #118
CGamesPlay wrote: post #76

Earlier quoted context omitted.

Wait, what? The code is a translation of a requirement to an implementation. The comment describes the requirement. The only problem with competing sources of authority is when the comment disagrees with the real requirements of the programmer/business/whatever. As another example, what if it were a method name instead of a comment? function printEveryOtherLine(myStringArray) { for (var i = 0; i Is your argument that…

It is possible to make the text a test spec that is then verified. See: http://jenisys.github.io/behave.example/tutorials/tutorial01... His complaint is that it isn't being done here, so all the prose is jut going to get out of date and incorrect, and meanwhile you have to write everything twice for no benefit.

The problem I see with verifying comments in English (that is, using English as a specification language) is that it's impossible in the general case. So you must, in practice, use a subset of English grammar/nouns which turns into a formal specification language. In turn, this becomes a programming language of sorts, and then we stray away from the goal of "programming languages for humans".

I'd love to be proven wrong, but I think the problem is that this goal itself is mistaken. If we can formally specify something using a language X, this necessarily becomes a language not "for humans" -- i.e. a formal language that doesn't follow the rules of natural language and that we must be trained in. Natural language is notoriously bad at unambiguous specification.

Post reply on HN