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

211–220 of 401 posts

Re: Eve: Programming designed for humans

#211

Post by noonespecial »

asolove wrote: post #192
noonespecial wrote: post #171

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…

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

Re: Eve: Programming designed for humans

#212

Post by anotheryou »

lahardy wrote: post #183

It seems like you are aiming for two main things at once, 1) to create a "literate programming" environment (document structure, real-time visualization, etc) and (in service of that?) to use this "world as data" model. As a non-expert programmer, I have to say I don't quite understand the implications of the search/bind/commit approach, specifically whether it was necessary in order to implement the features of the…

> wiki-like overlay

so just a nice rendering of comment? sounds like it might be possible with syntax highlighting and markdown-enabled comments

Re: Eve: Programming designed for humans

#213

Post by tunesmith »

brianwawok wrote: post #202
pjc50 wrote: 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

That's sort of a different problem. I often think of comments as "why" and code as "how" (or "what" if you're declarative). If how breaks, then the code breaks, so you have immediate feedback. But if why breaks - like if your reasons for writing it that way no longer apply - then it's impossible to recognize immediately. If there were instead a way to codify the assumptions behind why, such that the why statements would break when the assumptions become false, that would be interesting.

But at any rate, why is relevant, and code doesn't express the why.

Re: Eve: Programming designed for humans

#214

Post by ygmelnikova »

leke wrote: post #206

The syntax reminds me of a language I played with many years ago called REBOL. Even some of the terminology is the same, like a "block".

Yeah, that's the first thing I thought of as well. Even Douglas Crawford had high praises for Rebol, but the language failed to go mainstream, and died a long and agonizing death. Lack of adoption = obscurity, lack of long term development and funding.

Re: Eve: Programming designed for humans

#215

Post by webmaven »

A lot of interesting ideas are implemented in this version of Eve, but there are two goals (both implied and made explicit in various places) for "programming designed for humans":

- Make it easier for non-programmers to program

- Make it easier for programmers to program

While I can see that the current roadmap advances toward both those goals, I don't see what the Eve team plans to do when those two goals start pulling in opposite directions.

Will Eve be kept simple and a second UI be created for programmers? Or will Eve continue to be the programmers' tool, and a second UI be created for non-programmers in mind?

The alternative of keeping a single tool for both audiences makes me shudder, as it will literally end up being "code in Word". It is precisely because Word tries to be all things to all people writing prose that it is such a bloated mess (granted, it isn't the only reason, but it is a major one).

I'm not even certain whether a UX for non-programmers would just a subset of the one for programmers, or if there are likely to be features specific to non-programmers.

Re: Eve: Programming designed for humans

#216

Post by soared »

>Target market is not programs

>Only place to try it out is on github

Github is the most terrifying place on the internet for 90% of users (non-developers). I cannot stand when a project is trying to market to regular users but hosts any content on github. I get that this is an early alpha, but come on..

Re: Eve: Programming designed for humans

#217

Post by squar1sm »

Anything that increases feedback and visualization is great. It's not about the storage of the code it's about the communication paths between the programmer and the computer and making that higher bandwidth and quick turn-around. I love what I see with saving the session (lisp state) and replaying it.

If not this, then this idea. Or this idea with more time and features. Impressive already.

Re: Eve: Programming designed for humans

#218

Post by gonehome »

noonespecial wrote: post #171
jbclements wrote: post #150

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

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.

Re: Eve: Programming designed for humans

#219

Post by computerphage »

eternalban wrote: post #209
posterboy wrote: post #189

Earlier quoted context omitted.

We use mnemonics, because we can't remember numbers as well, but to the compiler, addresses are pretty much like names.

It's a bit more than that. Function names are precisely encapsulation of the intent of the function. And unlike comments, function names are not subject to rot. Also addresses are not like names. As with names in general, a name can refer to more than one object. (Consider modules, for example.)

> function names are not subject to rot

I don't agree with this. I think often a function will drift from its name if functionality is added to an aspect of its implementation or because of refactoring.

Post reply on HN