Eve language review
Today this Eve language popped up from somewhere and the last week was so much full of chaff from building my keyboard and from hacking my documentation tools. I think it's a good time to write a review this weekend.
The landing page of Eve holds so much more fluff than content that it was bothersome for those who try to figure out what this language actually is. That fluff looks like it was meant to attract non-programmers or otherwise gullible people.
I did a look a bit deeper, not much deeper though.
Evaluation
Eve programs behave like electric circuits. You can turn pieces on or off, whenever you write a new script it takes an effect immediately.
Every eve script is binding an action or deduction to an event or occurrence of a record. They propose this model is more intuitive and more familiar for non-programmers. People have been doing that kind of upselling since there has been declarative programming languages.
They tend to argue that programmers are weird and do weird decisions. Heck, Eve hints that programmers aren't humans. "Eve: Programming designed for humans" rather than for programmers.
Big problem in putting untrained people to programming is that in programming you have to maintain excrutiating detail and you are required to have deep understanding of the subject you are working on.
Eve as a language isn't completely without merits but it ignores this problem of detail. The ignorance isn't perhaps as bad in the earlier lineage of 'human friendly' systems before it.
The upside is they can really easily upsell their product with trivial examples. For example...
Here's a statement you might find comfortable to write in Eve:
If you thrust a pole at a bird then the bird will die.
There's some benefit in this kind of representation because the clause is immediate. It's got a condition and what happens when the condition is fullfilled. Erasing the clause causes birds refraining from dying when they're thrusted with poles.
It makes live programming easy as well, because you can keep introducing rules while the program is active. For example you might add:
If you thrust a pole at a bird and you are the rambo, the bird will explode.
It's a nice way of programming, as long as someone else has defined what thrusting, a pole, a bird, the rambo, exploding and die means. Otherwise it can get really hairy when you try to explain EVERYTHING in this mode.
For example, in that eve-style of scripts. If you stop birds from dying when they're thrusted with poles, but leave the rambo statement, does it mean that birds just explode and keep living on? Also if you implicitly say that bird dies when it explodes, does it mean that bird dies twice when the rambo thrusts a pole through it?
This is not necessarily "more human" than the traditional forms of programming. There's bit of truth in that claim because the programming model commonly used is related to how computers operate. But that doesn't mean the model is bad.
You could depict writing of Javascript as a form of speculative storytelling. The story unfolds when it is run. This is not a fundamentally worse way of describing programs.
For certain kind of scenarios storytelling becomes bit clumsy. For example, to describe the case of a bird and a pole, you would have to keep looping the following narrative:
The bird would die if pole was thrusted at it now, except that if that pole was thrown by the rambo, the bird would explode and die.
But storytelling can be really efficient as well. Here's an imperative explanation for how I do grocery shopping when I'm not lazy:
First I divide a shop into segments and remember which product was on which alley. I mark the alleys where there's a product that's in the shopping list.
Next I solve a problem similar to travelling salesman problem and determine shortest route through the shop and alleys which I have to visit.
Finally I go to the shop and start going through it. At each alley I pick the products that can be found from that alley in approximate order.
If a disaster strikes while I'm doing grocery shopping, I stop doing grocery shopping and panic.
I missed an important branch of that algorithm there. Well the point is the problems are in details, and it only gets worse if you try to explain certain things in inappropriate ways.
Relational model
One slightly interesting thing in Eve is its relational, record and logic programming features. I would feel a review would remain incomplete if I didn't tell about them.
In eve you can state that if you find a certain record, it means that there's also an another record that relates to the records you found. You can also do this over multiple items, for instance to create records that describe how many there are of some other records.
If you've used SQL, it shares similarities with relational databases. Though the concepts are originating from plain old logic programming languages.
How do they evaluate it is something I didn't bother to figure out yet. It's perhaps a search operation like it's in prolog, or then it maybe produces records until every non-unique record is produced, in fixed-point -manner. It's maybe more interesting later on so I may return to looking it up.
Anything of this isn't specifically new or exciting. Eve syntax had me confused for a while as it was not immediately obvious what specific meaning they convey.
I'm left bit interested about how logic programming and iteration constructs such as for-loops relate with each other. That kind of vibes came from elm and MiniKanren as well, the first time when I tried them out.
The take-away
Much of the Eve rhetoric goes to explain programming is hard because there are people making it harder than it should be. Although there are such people and they are working at large software companies, the overall rhetoric is wrong because the programming is difficult enough without anyone making it difficult. Programming isn't hard because the traditional programming is "ignoring human factors of software engineering". It's hard because it is.
Important thing to realise about this is that you can already have any form of programming model if you have the engine in your language for it. At any model of programming you are not restricted into accepting only one model.
For example, there is MiniKanren, which brings logic programming elements into scheme-like languages.
I'm inconclusive about whether Eve has a place in programming landscape or not. On superficial glance it looks like programming on stilts rather than programming for non-programmers. Even then I have my hopes up that languages like Eve popularize some new awesome ways to do programming. Give it a try if it seems like it'd be useful for your work.