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?
Eve: Programming designed for humans
311–320 of 401 posts
Re: Eve: Programming designed for humans
#312Earlier quoted context omitted.
But you do know something might be off, which is better than not knowing when something is off.
I was thinking the same from the root of this argument: "redundant encoding" isn't a way to automatically fix errors, but rather only a way to detect errors. Like a one-bit Error Correcting Code: the fact that the parity bit is wrong tells you something is corrupt, but it doesn't let you know what the right value should be. There's one useful thing you can avoid doing in response to such an error being detected: not…
In fact, I was reading about the bitcoin redemption vulnerability in stripe, and how often times security bugs are discovered by "huh, that's weird" rather than by eureka, and this ECC (error correcting code, see the pun?) seems like it would help to provoke that, and likely validates the amount of effort that it takes.
Re: Eve: Programming designed for humans
#313Earlier quoted context omitted.
How so? (Just genuinely curious as I always here this) I have asked the Java developers at my job if they have this common mindset and they don't seem to agree. I don't work with Java that much so I'm just honestly curious.
Java is a great virtual machine, a good collection of open source libraries, an ok language, and a nightmare collection of best practices and people who enforce them. I don't have a beef with the language, it is the developers who have never programmed in another language and still think that FactoryBuilderImpls are a good idea. They have never ventured outside of an IDE, but insist that Python isn't a real programmi…
That in a nutshell is why I said Java is a horrible language.
That said, people with a strong preference for a particular language are comparable to religious fanatics. A good engineer doesn't let language preference and emotional attachment to something get in the way of building something better.
If learning something else is too uncomfortable or seems unecessary to you then you are no better than a religious person.
btw, before I get downvoted the "religious person" analogy was what a senior developer said of me when I was a .NET guy a long time ago.
note: the same applies to the religious sects who worship libraries and frameworks (Mostly front-end Javscript web developers)
Re: Eve: Programming designed for humans
#314Earlier 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…
A state transfer diagram would probably be more useful as a view on the code (similar to how the Smalltalk browser is a simple graphical representation/layout of code. Or indeed any IDE with advanced code folding (show me the class name and public methods only). But there's ways to mix the two: Python doctests is one. The lp approach is to "escape" the code, not the comments. I really do think some richer data struct…
I personally only see the utility of the notebook as a demonstration tool of a finished product. Kinda goes to your comment on the notebooks and code maintenance. It's a good teaching or presentation tool but not (IMO) a development tool.
Re: Eve: Programming designed for humans
#315Earlier quoted context omitted.
Check out our followup on that : http://programming.witheve.com/deepdives/whateveis.html 1) Eve is amazing at graph algorithms, not so much at writing quicksort. At the same time, you don't need to write quicksort in Eve - it has all of the things you'd get from something like a SQL database. In general, anything requiring strict sequential order will be just ok right now, but it turns out actually very few things do…
Is there a more precise description of the runtime semantics anywhere? “A variant of Datalog” is helpful but doesn’t say much. For instance, it looks like every “commit” is essentially a sequence point that produces a step in the “fixpointer”—and from that terminology I guess Eve is Turing-complete, unlike Datalog? Do you test all patterns at every commit, or only those whose dependencies have changed? And if the lat…
The semantics are similar to Dedalus, which is compared to Datalog here: https://www.youtube.com/watch?v=R2Aa4PivG0g
Re: Eve: Programming designed for humans
#316Earlier quoted context omitted.
I don't know that I really agree with this criticism. I don't think having the additional context gives you two authorities which you are helpless to reason about. The code will tell you what is happening regardless of what is intended, the comments will tell you what was intended regardless of what is happening. More often than not, having both of these pieces can tell you where inconsistencies in the larger picture…
> The code will tell you what is happening regardless of what is intended, the comments will tell you what was intended regardless of what is happening. Unless you write the comment, then the code, then change the code and don't update the comment. Now if the code is wrong, both the comment and code are wrong. In current languages letting code handle the 'what', and comments handle the 'why' works well enough. Not sa…
I agree with you point in some cases and not others. I would characterize my position that you should comment just enough that someone other than you (or your distant, future self) and understand what the goal is; why being more important than what, what being more important than how.
If you're working with a relatively simple application where the information the application deals with is conceptually simple: you're absolutely right, explaining what and then having code that has a finite set of possible intents would just be wordy. On the other hand, I gave an example of ERP system inventory costing algorithms in another answer in this general thread where the complexity is different: cost can mean different things under different circumstances and different processes. We try to generalize these algorithms into lower lever functions, but you have to understand the what to know how it's appropriate to use the function... or if it is actually achieving it's goal: it may be coded in a way to be valid in all but the use cases targeted. There simply is no one size fits all answer to how to appropriately comment code (or if to do it at all).
As for bad comments and comment rot... any code, commented or not, can be written poorly or not maintained properly. Yes it's an extra moving part, and if you're not going to be as diligent about documentation as the code then, yes, often times your better without it. I think, however, it's better to force the issue. I don't think you need freestanding documents but by god if you have comments and I see code in a code review where the comments have been neglected: reject that submission.
Re: Eve: Programming designed for humans
#317From first look, looks like rubyish types of languages. Maybe it strikes a cord with someone else.
After 15 years I've learned to hate languages like these for building anything slightly complex.
However...
The great thing about all these languages is there's choice for everyone. There are as many pet peeves and ways of thinking as there are developers. There is a language for (almost) every type of case needed.
So use whatever the hell makes you love programming the most (or hate it the least), gets the job done right and makes your business(or employer) money or does something helpful for your users.
I might like like the flavor you like but, you might not like mine either. And guess what, we might both be totally right about the requirements met by the languages we use for our own work.
Re: Eve: Programming designed for humans
#318Earlier quoted context omitted.
Java is a great virtual machine, a good collection of open source libraries, an ok language, and a nightmare collection of best practices and people who enforce them. I don't have a beef with the language, it is the developers who have never programmed in another language and still think that FactoryBuilderImpls are a good idea. They have never ventured outside of an IDE, but insist that Python isn't a real programmi…
That in a nutshell is why I said Java is a horrible language. That said, people with a strong preference for a particular language are comparable to religious fanatics. A good engineer doesn't let language preference and emotional attachment to something get in the way of building something better. If learning something else is too uncomfortable or seems unecessary to you then you are no better than a religious perso…
Your message could still be effective (or even more effective) without putting down "religious people".
Re: Eve: Programming designed for humans
#319Underwhelming so far. Literate programming sounds good, but sometimes it's too much text and you want to quickly scan a few lines of code and guess what's going on without reading that wall of text. I wonder if this is for regular programming or for occasional programmers (non-programmers really) to try "stuff" out.
Maybe I've just never written anything difficult enough to benefit from it, but I also feel like literate programming would only slow me down. A programming language is a language, just like human languages. To me, literate programming would be akin to wrapping paragraphs of French with paragraphs of English to explain it. Sure, that might be helpful if you don't know French (well), but for people with decent competency it's redundant and just a distraction, and only likely to cause confusion when there is disagreement between the two.
But the beauty of programming languages over human languages is that because machines need to execute them, there is no room for ambiguity. Ambiguity is not just bad for computers, it's bad for humans too - misunderstanding requirements is a huge cause for delay, bugs and dissatisfaction of customers. The downside of writing for machines rather than humans though is that there is also no need for explanation of purpose or assumptions, which is the only thing I still add inline comments for. But even then, these can often be expressed in the language, and where possible they absolutely should be. If your code assumes some property or invariant, assert it! Or use the type system or tests to state and verify it. This way, the assumptions are constantly re-validated automatically by your build system, so the second they no longer hold you will know to reassess the code in question.
I hate maintaining old code written in a convoluted way with a comment explaining that the purpose is to improve efficiency, and then realising that the code in question is no longer a bottleneck and the efficiency is irrelevant. If literate programming helps me understand the convoluted code, great, but what I really want is something that helps me validate that it even needs to be so convoluted in the first place, and lets me know the second I can simplify it again.
Re: Eve: Programming designed for humans
#320Earlier quoted context omitted.
Is there a more precise description of the runtime semantics anywhere? “A variant of Datalog” is helpful but doesn’t say much. For instance, it looks like every “commit” is essentially a sequence point that produces a step in the “fixpointer”—and from that terminology I guess Eve is Turing-complete, unlike Datalog? Do you test all patterns at every commit, or only those whose dependencies have changed? And if the lat…
The semantics are similar to Dedalus, which is compared to Datalog here: https://www.youtube.com/watch?v=R2Aa4PivG0g
That was an excellent talk, thanks. It cleared up a lot of details about the paradigm for me. That said, now I’m more interested in Dedalus/bloom than Eve. :P