Live data from Hacker News

Eve: Programming designed for humans

programming.witheve.com

381–390 of 401 posts

Re: Eve: Programming designed for humans

#381
post #328
post #126

Earlier quoted context omitted.

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.

> We don't know. I don't know about you but I certainly know that if a printLine function accidentally does something else, it's definitely the code that's wrong and not the function name.

Well, if it's a library function like printLine and it does something else instead of printing to the console, that's probably a mistake (though if it does something so wildly different it cannot be simply a bug, for example logging to a file, I'd still wonder if the name is wrong). The problem is that you can't generalize this reasoning. For example:

  def sumAllNumbers(nums: List[Int]): Int = {
    nums.filter(_ % 2 == 0).sum
  }
Is the function name wrong or is the implementation? We can't tell without looking at how the function is used, and maybe not even then! Maybe we have to ask the person who made the last change. Maybe they changed the implementation for a valid reason and forgot to change the name. It happens!

So the name definitely helps, but it's not conclusive.

Re: Eve: Programming designed for humans

#382

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…

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.

Re: Eve: Programming designed for humans

#383
post #294

Earlier quoted context omitted.

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

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…

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?

Re: Eve: Programming designed for humans

#384
post #284

Earlier quoted context omitted.

I humbly disagree. My kid is going to get something totally straight forward imperative and easy to begin with, something in the realm of «one print "I am the best", two goto one». I strongly believe these are the basic building blocks which make everything else easy to understand, and they give you a good feeling about how the things work at the bare metal.

I think it's a shame that QBasic isn't bundled with Windows anymore. That was how I got started, on some old 486s in my chemistry/programming teacher's classroom, and it was really a fantastic integrated programming experience, very simple, but with room to do some really cool things. I remember that by the end of a year, a friend and I made a really terrible, but mostly working, version of Slime Volleyball, with gra…

Doesn't come with windows but here is Microsoft small basic

Re: Eve: Programming designed for humans

#385

Earlier quoted context omitted.

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

What about this: 1. Specs&design docs and code should be in separate files, because I believe the separation of concerns should be applied there. That's indeed the opposite of literate programming. 2. There should be two-way links between documentation and code: in the code, one should have links to the spec; and from the spec, one should have links to the code. 3. If the specs or the code changes, those links should…

With respect, I disagree.

Specification and design/implementation are not separate concerns. They are dual.

A sufficiently detailed specification is an implementation. Prolog does this (and Eve has a very similar feel).

As engineers, we traditionally work declaratively at the top of the "V" and imperatively at the bottom of the "V" -- but the reasons for this are largely historical/cultural.

We could (in theory) carry out the analysis/refinement process using entirely declarative notation.

The problem domain has primacy. Analysis separates problem-domain concerns and the duality takes care of the translation between problem and solution domains.

(OK -- so this is basically just a reiteration of the thesis of good old-fashioned AI -- that with a sufficiently powerful theorem prover and a sufficiently large and detailed knowledge base -- solutions will just pop out of a largely mechanical analysis process -- and I'm pretty sure this isn't at all trendy right now ... so I should relegate this to the "thinking out loud" bucket ...)

Re: Eve: Programming designed for humans

#386

I absolutely loved the semantic wiki stuff that was shown towards the end of the "In search of tomorrow" video. This seems fairly different to that system. Is there a write up/talk about why you changed? Is there anything like that semantic wiki thing available for me to use? https://youtu.be/VZQoAKJPbh8?t=46m20s

Yeah, Chris wrote up something on this a couple months ago.

http://www.chris-granger.com/2016/07/21/two-years-of-eve/

Re: Eve: Programming designed for humans

#387
Some great approaches here!

I like the medium-like bar on the left to browse blocks. Checking the boxes next to the blocks you want to show is a neat way to make a view of just the functions you want to look at. Putting it in a browser, like iPython/Jupyter improves accessibility for people whose main job is not developing software (the Eve demo makes a good example of being able to pass an analytics view to a teammate in marketing).

I do find myself wondering how a literate programming system like this would scale for a large project (I expect the Eve team have thought about this more than I can imagine).

Great polish on the demo, too :)

Re: Eve: Programming designed for humans

#388
post #354

This looks cool, but can somebody point me towards the details? As in, I'm a semantics / pl-theory person and want to know wtf is going on...

We will be publishing more docs about the inner workings of the language in the coming weeks... There was just so much to do here and we wanted to get things out the door. The short explanation is Eve is a datalog variant. If you are really interested, you can read some of our blog posts to get more of an idea: Www.incidentalcomplexity.com

Re: Eve: Programming designed for humans

#389

Any attempt to re-imagine programming is refreshing, but it's unclear to me if this is more than a domain specific language (DSL). Is it possible to implement, for example, the bar graph from lower primitives?

Yes, you can actually see where the bar graph is implemented here: http://play.witheve.com/#/examples/view.eve

You can build charts like this in svg or html right now. Basically, in Eve we are just generating the records necessary to render these views. We have a separate process that's tied to the browser that takes these records and turns them into something the browser can understand. So Eve isn't tied to html; if you write your own translation layer (and we will have many more by default in the future) then Eve can generate whatever you want.

Re: Eve: Programming designed for humans

#390
post #145

Earlier quoted context omitted.

> What's wrong with Vim? Emacs is better ;) But the comparison is a bit disingenuous. Medium is a blogging platform, VIM is an extensible text editor.

I think they were trying to emphasize that their strength in "readability", hence Medium. I watched the video, and immediately realized I would never want to program in that kind of environment. The "literate programming" would get in my way. It would be like having someone follow me all the time and translate my words in realtime right next to me whenever I speak something. (Actually it's more like me saying somethi…

I would say its closer to the reason we include emoticons in text messages. Text alone loses something from the original intent, so we add emoticons as a way to bring some of that back. Plain code as well cannot express softer yet still crucial aspects of software design like "intent" or "audience" of the subsequent code.
Post reply on HN