Earlier quoted context omitted.
so basically Java?
Good tooling, easy to understand, unambiguous? Sounds like Java. Why can't people just use Java?
Java? What a horrible language.
Eve: Programming designed for humans
271–280 of 401 posts
Re: Eve: Programming designed for humans
#272Earlier quoted context omitted.
"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 your thoughts in a precise fashion." Non-programmer: OK, Eve sounds great, so, I want to search for a Slack message. How would I do that? Eve-programmer: Obviously, it's just: search @slack [#message from body…
This milestone is very much about making a programming environment, so you're right, that's still code. Though to address this strawman, compare that to what you would write in Java or even Python. Some of the best comments we've gotten is when we've shown people eve code and told them to ignore the symbols, just read the words. Their eyes really open up and they tell us pretty exactly what the block is doing. No, it…
The "ignore the symbols and just read the words" idea is part of Ruby's promise as well. In practice, I don't personally find it very satisfying, because it's easy to write things that read like they do one thing, but actually do something else. So you have to train yourself to ignore what it says until you figure out what it does.
I think the better metric to optimize for is how easy it is to go from seeing a piece of code for the first time to having a mental model for what its runtime behavior will be. Do you think Eve is strong on this in addition to its "readability"?
Re: Eve: Programming designed for humans
#273The 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.
What exactly is going to be the problem when all version control systems do is merge based on text differences? Also the block separation here could actually be used semantically and provide better merging than for existing languages.
Markup and storage semantics. Try merging .xls documents.
Re: Eve: Programming designed for humans
#274I 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…
Did we read the same article? Were you somehow mistaking the comments for code? The actual code is pretty clearly based around some well-defined deterministic semantics and still demands precision and consistency from the programmer.
And moreover its promise appears to be exactly "higher-level abstractions to allow humans to reason about programs more efficiently", in direct opposition to what you wrote here.
EDIT: Of course programming languages are designed for humans... they wouldn't exist otherwise. But they also tend to be pretty strongly influenced by the imperative nature of assembly language. The Eve team seems to be asking: What if we ignored that entirely? In a way this seems a lot like a spreadsheet - you can write a lot of little code blocks that aren't executed in any particular order and yet produce deterministic results.
Re: Eve: Programming designed for humans
#275Earlier 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
That comment I'd interpret as the requirements must be considered in this region; so if the law changes, the requirements still apply , it's just that the code needs to be updated. Requirements are usually exogenous to the code.
"PCI-DSS requirements apply" isn't adequate in a literate program for the same reason that "must work correctly" isn't adequate. Explaining the relevant requirements in detail is a crucial goal.
Re: Eve: Programming designed for humans
#276Earlier quoted context omitted.
The meat is that most programming languages are not designed for humans. Many weren't designed at all so much as hacked together for context they were originally used in with terrible consequences for learning or effective use by average person. C and early PHP probably lead that. Many others were affected by committee thinking, backward compatibility, preference of their designer, or the biases of people who previou…
Smalltalk was very consciously, and conscientiously, designed for humans.
That's a good point. It will be on the next version of that comment.
Re: Eve: Programming designed for humans
#277I 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…
"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 your thoughts in a precise fashion." Non-programmer: OK, Eve sounds great, so, I want to search for a Slack message. How would I do that? Eve-programmer: Obviously, it's just: search @slack [#message from body…
I don't understand your example. If you abstract away the hard part of searching a database and sending an email (as most programming languages do), then every language is as easy as the snippets you posted. In python:
messages = slack.search()
email.send(to='corey@kodowa.com', subject='hi', body='yo')
Re: Eve: Programming designed for humans
#278Earlier quoted context omitted.
"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 your thoughts in a precise fashion." Non-programmer: OK, Eve sounds great, so, I want to search for a Slack message. How would I do that? Eve-programmer: Obviously, it's just: search @slack [#message from body…
If we can eliminate software engineering as a profession our work will be done. There will be nothing left for humans to do, because at that point we will have invented a General AI. Up until that point, software engineering will be a well paid job. I really don't understand this attitude that everyone should be a programmer or that programming should be easy. It isn't easy. Obviously, we should remove unnecessary fr…
It's not unthinkable that a language, by design, facilitates or enforces precise definitions.
As a far-fetched example, think of Lego. You can't "fail to compile" your Lego bricks. You have a finite selection of bricks (all clearly visible and usually available within arm's reach), and your job is to just lay one at a time. Given any brick, it's "obvious" to a human how it fits with other bricks. The worst you can do is essentially create a crappy Lego design. As you noted going from a rough thought of
"Uhm I want to build a Dragon of about this size..."
to a finished build requires a powerful AI. But we don't need to go that far to be better than
"Place $brick1 in p=(32,17) at orientation o=(0,pi); place $brick2 in p=(38,15) at o=(-pi,0); ..."
The rigidity of the bricks inherently prevent you from overlapping them, but not the above declaration :)
Re: Eve: Programming designed for humans
#279I 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…
It's unfortunate the parent is the top comment here. There's a common thing that happens when a new idea shows up that doesn't easily fit into existing categories:(most) people give it a cursory look over, and then decide it's just another instance of boring category X.
This is especially common in discussions about humanizing programming. I think it's partly because people are invested in the current way of doing things, having spent so much time developing their particular skills; and partly because our attempts at serious alternatives have largely been failures, so far. That makes it easy to see any new idea in this space and automatically class it as already understood. But there is room between C++ and toy visual languages, and someone may find something good there yet—and this will illuminate things just that much more if nothing else.
Look into the lineage of ideas the Eve team have moved through to get where they are today, and you've got to admire their search process even if you don't like the results.
In any case, it's patently false that Eve's innovation is analogous to the algebra example given in the parent.
Re: Eve: Programming designed for humans
#280Earlier quoted context omitted.
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.
And thus it's important to also rename things when refactoring, or else you get awful confused when your Foobinator(x) function returns you a Splunkinated value, or your FrobbleTheFribbets() call also woggles the wiggles.