Eve: Programming designed for humans • Hacker News Board

Re: Eve: Programming designed for humans

#241

Post by FrancoDiaz » Fri, Oct 28, 2016, 9:25 PM UTC

king_magic wrote: post #28

How is this significantly different from something like Light Table? (edit: didn't realize it was build by the people who built Light Table). It feels like a rehash of that + Python notebooks, with a bit of Xcode's playground thrown in. Problem is that despite those tools being available, I literally never use them. Ever. Nor do I have a need for them. I kind of like the idea of being able to find bits of code in a l…

I hate being preachy, but Problem is that despite those tools being available, I literally never use them. Ever. Nor do I have a need for them.

You don't know what you don't know.

Re: Eve: Programming designed for humans

#242

Post by PJDK » Fri, Oct 28, 2016, 9:25 PM UTC

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

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.

Re: Eve: Programming designed for humans

#243

Post by imh » Fri, Oct 28, 2016, 9:28 PM UTC

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…

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

Re: Eve: Programming designed for humans

#244

Post by dboreham » Fri, Oct 28, 2016, 9:29 PM UTC

Someone needs to be given a lollipop?

Re: Eve: Programming designed for humans

#245

Post by jhomedall » Fri, Oct 28, 2016, 9:29 PM UTC

I've just started following along with the quick-start tutorial, and I have to say that the presentation is quite fantastic.

Combining the source, tutorial documentation and program output along with the ability to selectively enable blocks of code makes for a unique experience that I haven't seen elsewhere (Jupyter Notebook comes quite close, however). I recommend anyone reading this to give it a shot: http://play.witheve.com/#/examples/quickstart.eve

It's a shame the majority of the posters here seem to be preoccupied with the tagline, rather than the actual project.

Re: Eve: Programming designed for humans

#246

Post by erichocean » Fri, Oct 28, 2016, 9:33 PM UTC

erikpukinskis wrote: post #198

cocktailpeanuts wrote: post #104

"An IDE like Medium, not Vim" What's wrong with Vim? I think they're trying to cater to "the non-programmer crowd" with this, but by trying so hard it's alienating real programmers. I love vim, and I hate Medium with passion. I'm sure there are a lot of other HN people who are not so much a fan of the types of people who just write meta posts, rant posts, listicle posts, self help posts, growth hacking posts on Mediu…

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

Re: Eve: Programming designed for humans

#247

Post by [deleted] » Fri, Oct 28, 2016, 9:39 PM UTC

erichocean wrote: post #246

erikpukinskis wrote: post #198

Earlier quoted context omitted.

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

[deleted]

Re: Eve: Programming designed for humans

#248

Post by hinkley » Fri, Oct 28, 2016, 9:40 PM UTC

The first question I always ask, and often the most deadly:

How do you handle version control, and merge conflicts?

If you don't have that figured out, none of the rest of this matters. Because a programming language designed for one developer isn't designed for building software.

Re: Eve: Programming designed for humans

#249

Post by marshray » Fri, Oct 28, 2016, 9:43 PM UTC

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

Re: Eve: Programming designed for humans

#250

Post by ljw1001 » Fri, Oct 28, 2016, 9:43 PM UTC

zenobit256 wrote: post #41

lopatin wrote: post #29

Earlier quoted context omitted.

There's plenty of meat in the blog post, on the Github etc. I suspect it's for "humans" because it's literate, functional programming with a REPL and a natural approach to how data is managed. It's a lot more than just a functional programming language. When did it become cool to make uninformed claims about how worthless other people's work is?

So if this is "programming for humans", all of us are just writing in some alien language because we're aliens? When did it become fashionable to call everybody else some variant of insane or delusioned and tout your own solution?

I think "for humans" is just intended to convey that the language and environment are based on research into human cognitive traits: how we think and learn.