Live data from Hacker News

Eve: Programming designed for humans

programming.witheve.com

201–210 of 401 posts

Re: Eve: Programming designed for humans

#202
post #144

Earlier quoted context omitted.

So your defense of literate program gives, as a defense, what I would think of as an attack on literate programming: Take this strawman for instance, how could you find the bug in the following code without the accompanying comment? // Print every other line of the array to the console for (var i = 0; i Because the problem with that is that now you have two competing sources of authority -- the comment, and the code.…

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

Re: Eve: Programming designed for humans

#203

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

That's what I was thinking. I'm a human, I like my Vim and C. The main limitation of a language like that is that, if you care about performance at all, you have to program for the machine first, not for humans. You're always writing for both to some extent. For me this is the main challenge of programming; writing code that executes efficiently and correctly, and that is legible to humans. I love Python and other hi…

[deleted]

Re: Eve: Programming designed for humans

#204

Earlier quoted context omitted.

You didn't address at all what forces the programmer to keep the prose and code in sync. If you still have code that's read and translated by the compiler, and prose that's ignored by the compiler completely, how have you actually changed anything?

Well, I don't think anything can force the programmer to keep the prose and code in sync. The best we can do is give you an incentive to do so. The argument that was presented is that comments will get out of sync with code, but we're trying to provide tooling that will incentivize you to keep code and comments in sync. I'd also like to say that if code is easier to read in the first place, there will be more eyes on…

Actual thing that will happen, if you're lucky: Dev changes the code to fix a bug, tests it, modifies it etc., finally gets it done. Deletes loving paragraphs of now obsolete text and writes in a one-liner description ("handle gravity effects")

Actual thing that will happen, if you're not lucky: Same as above, but they don't delete the obsolete paragraphs.

Re: Eve: Programming designed for humans

#205

Earlier quoted context omitted.

Well, I did skim a little bit through Eve's source code, specifically the files in https://github.com/witheve/Eve/tree/master/src and subs, and the first thing that stroke me was: it's not literate. As a matter of fact, it doesn't have more comments than an average code base, maybe even less. Why? Where is the prose? What makes programs supposed to be written in Eve different from Eve itself?

Trying to do literate programming in traditional languages is pretty crappy [1]. Some heroic effort ended up having to go into this release as well so things aren't as commented as we wanted, but that will improve. There are a few files that are pretty good though [2]. Our Eve source on the other hand is wonderfully literate and it's been a really great experience. Here's the code that makes the inspector work [3]. […

I only looked at 2.. but honestly, that looked like the kind of code I got delivered from offshore teams. 3 lines of comments saying what a for loop will do, then 1 line to do the for loop. I would -1 most of that on a code review, and ask for comments that just describe what the code is doing to be removed.

Re: Eve: Programming designed for humans

#207

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…

"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's not all the way there, but that's a big step forward.

In any case, check out our followup on what Eve is and isnt [1] - we're under no delusion that this is the end user story... yet :)

[1]: http://programming.witheve.com/deepdives/whateveis.html

Re: Eve: Programming designed for humans

#208
Well, I think this sounds quite good, in fact it sounds so good that it is probably not true. And reading to the page, I stumble over the sentence

> An IDE like Medium, not Vim

Thing is, vim is not complicated because of some misplaced elitism, vim is complicated because it helps with complicated problems. (I am a zealot for the church of Emacs, when I say something "nice" about vim, it is because honesty or pointy objects force me.)

Unfortunately it goes downhill from there, it is nice that there is a way to visualize memory in five lines of code, but what about the memory of the following three processes (and the one thread in red and the others in some other color?) In my experience, there is a trade off between the power of a language and the impressiveness of the examples. (A better example would probably be the twitter api, does that mean I need to beg the core developers to talk to the next "slack for dogs" api?)

Then there is the "zoom" feature, I have not the slightest idea what that is supposed to mean. (Actually I have, I just don't think that this side of a strong AI coworker it is possible to hide information in any useful way. (Hiding information is just the inverse of zoom.)

And to top it of, there is a link to the demo and the first thing I notice is, scrolling is broken. (Arch, Firefox, NoScript with in this case all JS sources allowed) Well, the first thing a IDE should allow me to do is to display text in the most reliable way possible, even if that means more than one page. (Plus it is in a browser, which may or may not be only for demonstration purposes, but at the very least the browser uses the right mouse button to display browsery options not IDE options.)

After having fired up chromium, there the IDE works and it actually works kind of well. To keep with the overall negative tone of the comment, almost as good as Jupyter. The first thing I notice, is that one can switch code blocks on and off, but the output depends non linearly on the set of switched on code blocks. For this one would likely need some kind of toggles for sets of code blocks if it should be usable at all. (So to switch on extra test cases, or to test only one part of the program, etc.)

In conclusion, it is a nice project and I wish the devs all the best. Hopefully one of these days someone manages to get literate programming to work. But I think that there are quite a few things which make me doupt that this is, what makes literate programming work in the end.

Re: Eve: Programming designed for humans

#209

Earlier quoted context omitted.

Of course names are important to us, human programmers, but the compiler doesn't given an 'f'.

We use mnemonics, because we can't remember numbers as well, but to the compiler, addresses are pretty much like names.

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

Re: Eve: Programming designed for humans

#210

Earlier 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. The comments will tell you what was intended at some point regardless of what is happening. In any mature code base that includes these "what not why" comments, the comments will inevitably document old intents that have since changed. > Maybe I'm biased because I'm p…

> Given that, why do you need these kinds of comments at all?

Because in large, logically complex systems, especially large complex systems that are sold to many customers like my area of expertise, ERP systems implementation & development, there are many, many right answers (there are many wrong answers, too). Take inventory costing; my current project is adding an industry specific inventory handling methodology to an existing ERP system. Consider the inventory unit costing: there are multiple methods (standard, weighted average, FIFO, retail method, etc.), there can be different derivations and components (purchase cost, landed costs, material costs, direct overhead cost, indirect overhead costs) and to top things off, not only do systems implement more than one of these at a time, sometimes different of these can be useful concurrently depending on context: if I'm analyzing my vendor costs per item, I might not want my overhead costs in the picture, but I still need overheads in the capitalized cost of the item when determining Cost of Goods Sold when I ship product out, for example. In software, if I see a function like (not real, way oversimplified pseudo-code):

function calc_item_trans_cost() { total_item_trans_cost = item_cost + item_freight_cost return total_item_trans_cost }

I might not know exactly where or how to use this properly, even having some expertise. Was the developer trying to get at a landed cost? Are they expecting that this would only be used in the invoice matching process and shouldn't really be used outside of that? I might get that contextually from surrounding code or from the (various) contexts that the function is called in, but now I have a research project trying to figure out why they created this so that I don't use it in inappropriate contexts... or I can re-invent the wheel (not a good strategy). My professional knowledge will tell me where to look for other telltale signs to figure out the answer, but not immediately just from looking at the code since there are multiple valid answers. If I had:

// Function for determining item costs for three way matching. // We record freight costs separately from item material costs, // but invoices have no such breakout, so we do the math here // to facilitate the matching process.

function calc_item_purch_cost() { total_item_purch_cost = item_cost + item_freight_cost return total_item_purch_cost }

now I get it. It's not that the system has a simplified view of landed costing, but there is a specific purpose that was trying to be accomplished by this function.

> You already know what the code is supposed to do anyway, why introduce a comment that you might later forget to update, leaving less knowledgeable colleagues confused?

Most of the time the comments in the code I work with really don't change much in regard to intent. If the comments get too close to describing the logic, then yes, the comments don't age well as the logic that achieves that intent is improved, but those are the comments that are probably not needed. The contextual comments, however, are important (even for me to understand what I wrote after some time has passed).

Even so, I was speculating/rationalizing on why people might hold that somehow "ignorance is bliss" when I spoke of junior staff. I don't hold that belief myself. I haven't found that withholding information even from junior/support staff is better than giving more complete pictures. I find the informed person much more useful that the person guessing at what it could all possibly mean and fit together.

Post reply on HN