Many of the folks here have been following us for a long time and we're really excited to finally pull everything together to show you all where our research has taken us. Eve is still very early [1], but it shows a lot of promise and I think this community especially will be interested in the ideas we've put together. As many of you were also big Light Table supporters, we wanted to talk about Eve's relationship to it as well [2].
We know that traditionally literate programming has gotten a bad rap and so we laid out our reasoning for it here. [3]
Beyond that, we expect there will be a lot of questions, so we'll be around all day to try and answer them. We'll also been doing a bunch of deep dives over the next several weeks talking about the research that went into what you're seeing here, how we arrived at these designs, and what the implications are. There was just way too much to content to try and squeeze it all into this page.
Also, a neat fact that HN might be interested in:
Eve's language runtime includes a parser, a compiler, an incremental fixpointer, database indexes, and a full relational query engine with joins, negation, ordered choices, and aggregates. You might expect such a thing would amount to 10s or maybe 100s of thousands of lines of code, but our entire runtime is currently ~6500 lines of code. That's about 10% the size of React's source folder. :)
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 < myStringArray.length; i++) {
console.log(myStringArray[i]);
}
This shows how important intent is to a program. Yes, the
example is trivial, but without that comment, how would we know
that it's wrong?
Because the problem with that is that now you have two competing sources of authority -- the comment, and the code. One of them is right and one of them is wrong. But which is the right one?
In the real world, the answer is almost always "the code that's actually been executing, rather than the comment that hasn't," which is why it's a good idea to minimize commentry of that type, to prevent confusion on the part of the reader.
So if you're doubling-down on literate programming, how do you address that problem? That article says, "Inconsistencies between the code and the prose are themselves errors in the program and they should be treated as seriously as a buffer overflow," but does Eve actually do that? It's hard for me to see how it could, in the examples given.
(If the idea is simply that this is extra work for the programmer to do -- that they need to describe every implementation twice, once in code and once in English -- I submit that it's not very human-focused at all, if those humans are programmers.)
Wait, what? The code is a translation of a requirement to an implementation. The comment describes the requirement. The only problem with competing sources of authority is when the comment disagrees with the real requirements of the programmer/business/whatever.
As another example, what if it were a method name instead of a comment?
function printEveryOtherLine(myStringArray) {
for (var i = 0; i < myStringArray.length; i++) {
console.log(myStringArray[i]);
}
}
Is your argument that the method name is incorrect because the code dictates a different behavior?
This is the almost the same example. Function names also don't execute. The parent's point was that if the code has been tested or was considered working, and then you noticed this in the code, you should think twice before "fixing" the behavior to match the comment or function name.
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.)
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.
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.
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 rely blindly on either the implementation or the specification being correct, but instead check them both.
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.
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:
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.
Well no, I think the argument is that this kind of comment gets outdated easily, so if the program works as expected, the comment is probably outdated (new requirement, the program was changed to print every line, forgetting about the comment). If the program does not work as expected, then it's a bug and the comment is still valid.
This does not happen in your function name example: if the program requirement changed to print every line, no sane programmer would change the code in this function, they'd write a new function printEveryLine() instead and use that. So you can be pretty sure this is a bug.
> If the program requirement changed to print every line, no sane programmer would change the code in this function, they'd write a new function printEveryLine() instead and use that. So you can be pretty sure this is a bug.
Unfortunately many programmers seem not to be sane.
> if the program requirement changed to print every line, no sane programmer would change the code in this function they'd write a new function printEveryLine() instead and use that.
I'm not sure I understand the distinction you are making here, so I'd like to try and understand. From my perspective, function names are just another form of comment. After all, in many languages, as soon as you press "compile", your function names are mangled into something a machine can understand.
So you feel that programmers are more inclined to treat the function name as an authority, as opposed to a comment. Is that an accurate? I'm curious what lead you to this conclusion.
A function can be called from different places, maybe it will be used in code not yet written. So a programmer has a need to print every line. The code to be changed calls printEveryOtherLine. They won't change that function to print every line, because they know that would break things elsewhere.
>So you feel that programmers are more inclined to treat the function name as an authority, as opposed to a comment. Is that an accurate? I'm curious what lead you to this conclusion.
I think this is a reasonable claim, even though as you've said there's nothing strictly enforcing this behavior. Function names are generally highlighted by the editor/IDE, and the developer is forced to stare at them and at least begin to type them out while calling them. They're brief and repeated over and over again in the source code. They're just harder to ignore. Comments on the other hand only appear once per comment, tend to be italicized and greyed out by IDEs, are generally at least one sentence in length and can span multiple paragraphs, and are never going to be directly referenced from within the code itself. It's still very possible to change a function without updating its name to suit its new purpose. But I know for me personally I'm much more prone to missing comments that I need to now delete or reword. I have to acknowledge the function name when I write code calling it or read code referencing it, but comments are just sort of there, hovering in the background. It's easier to read them once and then tune them out and forget that they're there.
People have to call a function, using its name. The function name is the mental-model handle you have on the function. If the name is a bad representation of what the function does, then the function probably just won't ever get called, because nobody will be able to build a mental model of it.
Indeed, someone else will probably end up duplicating the effort of writing the same function over again—but with an accurate name this time—because they aren't aware that the functionality they want exists in the codebase already.
And this is all an implicit consideration made by every programmer, every time they define—or later modify—a function. We all know that we'll "lose track of" functions if we don't call them something memorable for their purpose. So we put thought into naming functions, and put effort into renaming functions when they change. (Or, with library code, to copy-pasting functions to create new names for the new variant of the functionality; and then factoring out the commonalities into even more functions. We go to that effort because the alternative—a misnamed function—is almost effectively beyond contemplation.)
His complaint is that it isn't being done here, so all the prose is jut going to get out of date and incorrect, and meanwhile you have to write everything twice for no benefit.
The problem I see with verifying comments in English (that is, using English as a specification language) is that it's impossible in the general case. So you must, in practice, use a subset of English grammar/nouns which turns into a formal specification language. In turn, this becomes a programming language of sorts, and then we stray away from the goal of "programming languages for humans".
I'd love to be proven wrong, but I think the problem is that this goal itself is mistaken. If we can formally specify something using a language X, this necessarily becomes a language not "for humans" -- i.e. a formal language that doesn't follow the rules of natural language and that we must be trained in. Natural language is notoriously bad at unambiguous specification.
And then you'd need to describe the specification language and how would that be verified?
I suppose that English is imperfect and could use improvements. Ideally those two would converge. That would solve problems about the interpretation of laws, as well. How would that convergence work? To answer that you'd have to know how language is acquired in the first place. I suppose some form of self-reference in the language that mirrors some of Chomskie's stipulated universal grammar, if it exists.
I think there's one kind of "specification language" that works completely unlike programming itself—and that's the interactive form of specification known as requirements-gathering that occurs in the conversation between a contract programmer and their client.
I could see potential in a function-level spec in the form of an append-only transcript, where only one line can be added at a time. So you (with your requirements-specifier hat on) write a line of spec; and then you (as the programmer) write a function that only does what the spec says, in the stupidest way possible; and then you put on the other hat and add another line to the spec to constrain yourself from doing things so stupidly; and on and on. The same sort of granularity as happens when doing TDD by creating unit tests that fail; but these "tests" don't need to execute, human eyes just need to check the function against them.
---
On another tangent: I've never seen anyone just "bite the bullet" on this, acknowledge that what they want is redundant effort, and explicitly design a programming language that forces you to program everything twice in two separate ways. It seems to me that it'd actually be a useful thing to have around, especially if it enforced two very different programming paradigms for the two formalisms—one functional and one procedural, say; or one dataflow-oriented ala APL or J, and the other actor-modelled ala Erlang.
Seems like something NASA would want to use for high-assurance systems, come to think of it. They get part-way there by making several teams write several isolated implementations of their high-assurance code—but it will likely end up having the same flaws in the same places, given that there's nothing forcing them to use separate abstractions.
I agree, if I'm writing a paragraph of english followed by a paragraph of code... what's the point? Comments at the moment are generally one liners and can quickly get outdated if not maintained.
Right, this is exactly the argument we are making. Given just the block of code above, we don't know enough to make the determination. Who is right? We can't possibly no without more. That's why commenting code is not enough, and that's why literate program is important.
Imagine if you came across this in actual code. You might first check if the code was changed recently and by whom, and whether the comment or the code came first. But that still wouldn't tell the whole story. To get it all, you would find out who checked in the code, and what their original intent was.
What we're advocating is to treat source code more like a design document. It's a collection of thousands of design decisions all informing the specification of the final product, the program.
> If the idea is simply that this is extra work for the programmer to do -- that they need to describe every implementation twice, once in code and once in English
Right, so the point is that prose is not redundant. As Knuth put it literate programming is "a mixture of formal and informal methods that reinforce each other." When we communicate to one another face-to-face, we use gestures, expressions, intonation, etc. to articulate an idea. On the internet, when we communicate with just text, much of my meaning is lost forever and never apparent to anyone who reads this.
Programming is much the same way. The code only tells you so much about the program. Without any context, readers are often disoriented and confused by new codebases. If no one is willing to read your code, no one will ever contribute to it. GitHub and SourceForge are veritable graveyards of amazing yet abandoned projects that will never see another contribution, because their codebases are so inscrutable. I know I'm guilty of this as well; when I revisit old codebases, I hardly know even what I was thinking.
Anyway, I think there's a lot to explore here. I think what you raise is an issue, and it will always be important to address, but I really believe that literate programming is important and can lead to better code. So we're going to see where we can take it with Eve, and I hope you'll give it a shot!
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 it, and discrepancies will be resolved sooner. In most programming environments, a comment might describe a part of a much larger function. But the output of this code is far removed from the actual source. So discrepancies between comment and source are harder to spot.
It Eve, we intend these documents to be for more than just programmers. Who again, might not understand your code, but would understand the written prose and see the output /right there in the code/ that contradicts it. A bug like this would be brought to your attention much sooner than if your code was simply hosted as on GitHub.
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.
Every company needs a human-readable definition of what a product does. There is no way to eliminate the problem of keeping prose and code in sync. Traditionally, we just hide the problem by keeping the prose and code entirely separate. Keeping them together makes it harder for them to drift apart.
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.
Python is just "ugly" C underneath, containing for example a 1500 line switch statement, but this does not in any way change the fact that it's a great piece of software.
Your example doesn't make sense to me.
If I see a comment that says something different from what the code does I assume that the comment is wrong and I do a simple blame that will show me the jira that has been implemented in that code to double check.
For sure I don't need to read all that is specified in the Jiras whenever I look at any piece of code.
The code explains itself quite well.
If you write code that is not understandable then that is the problem, and adding thousands of comments in the form of documents will only make the things worse instead of solving your problem.
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 have arisen and you can use your own judgement to figure out what it all means and what you might do next. Maybe I'm biased because I'm pretty proficient in the business domains I specialize in, so I can understand, conceptually, what the application is suppose to support and consider the validity of the programmer's intent as well as the code's function.
But I'm not sure why it would be considered beneficial to withhold knowledge of intent in favor of purely what's happening; except maybe to junior/support staff that aren't likely to understand the motivation behind a developer's intent. Perhaps, because of the concern that code gets maintained and related commentary doesn't?
The criticism is valid. I have yet to encounter a comment in production code that projects future intent for a piece of code, but having comments lag behind revised code is all too common. Comment rot is one of the motivating reasons behind 'sparse comments' school of thought.
> 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 saying it is a perfect system, but the idea of the comment being expanded to include the 'what' as well doesn't seem like progress in the right direction to me.
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.
>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 pretty proficient in the business domains I specialize in, so I can understand, conceptually, what the application is suppose to support and consider the validity of the programmer's intent as well as the code's function.
Given that, why do you need these kinds of comments at all? 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?
> 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):
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.
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.
Most coding editors (even the "deprecated since the 70ies" Vim) shall let you follow links you put in comments.
For someone who likes to have as much code as possible on a single screen, this is the best option.
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 structure than flat text files is needed - simple multi-/hyper-text seems like a minimum. Not only links (most ides have this: hoover to display help, click to goto definition etc).
Why so few seem to successfully add vector graphics and diagrams I don't know. I guess jupyter / ipython might be a rare breath of air. But who really wants to maintain 10k locs of code and 15k locs of tests in ipython notebooks?
We need something more (lively kernel might be more interesting here - webdav for persistence Web browser for run/edit/view - I'm not sure if the required power Canberra realised any simpler).
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.
The main question is if there's any fundamental reason for why we can't have both: a rich, versioned, distributed data store for our logic and data - and a number of views that allow us to inspect and modify it.
The best example I'm aware of is probably Smalltalk coupled with monticello version control and a solid object database like gemstone/s (I'm not aware of a real open/free workalike for the last part).
That's not not say relational or logic databases aren't useful - but it's more difficult to manage the data, query code and program code in one integrated system if the database takes the form of an external server. That said, Ms visual studio and the SQL db gui does a pretty good job of presenting a somewhat coherent environment.
I used to be strongly in the Linux/Unix camp - thinking that the datastore we call the filsystem is a good abstraction. But I've come to believe that even the strong legacy of user familiarity isn't a good enough reason to stick with it. Even if we were a little bit more serious and at least went all plan9 - rather than the half-hearted state of Linux/Unix (everything is a file, or a database file, or a binary file or an archive of a filsystem or...).
That said a "filsystem" might very well still be a decent building block for a higher level system (with decent search, for example).
But yeah, I don't think jupyter is the be all, end all of development. But it is an interesting way to move legacy programming environments forward in a low friction manner.
That's sort of a different problem. I often think of comments as "why" and code as "how" (or "what" if you're declarative). If how breaks, then the code breaks, so you have immediate feedback. But if why breaks - like if your reasons for writing it that way no longer apply - then it's impossible to recognize immediately. If there were instead a way to codify the assumptions behind why, such that the why statements would break when the assumptions become false, that would be interesting.
But at any rate, why is relevant, and code doesn't express the why.
My approach to this is that the comment can almost always be turned into a text. A test class called FooPCIDSSCompatibility with tests for all the bits both defines things more strongly and will start failing if you ever break it (either accidentally or because it is no longer required). Either way you need to update either code or test to get through the build process.
Comments can be useful for annotating algorithms or referencing stack overflow though.
My approach to this is that the comment can almost always be turned into a text. A test class called FooPCIDSSCompatibility with tests for all the bits both defines things more strongly and will start failing if you ever break it (either accidentally or because it is no longer required). Either way you need to update either code or test to get through the build process.
Comments can be useful for annotating algorithms or referencing stack overflow though.
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.
"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.
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 be displayed in a different way to warn the reader that things are potentially not in sync. How to do that: check if the links point to the latest version. The maintainers have to update the links to remove the warnings.
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 ...)
Well, it's just a code smell. Smelly code isn't necessarily wrong, it's just more likely to be wrong.
Sometimes a piece of code needs to be highly optimized to the point of being basically unreadable, at that point it's probably worth adding explanatory comments that you would normally avoid.
I think the literate in literate programming is too formal. Maybe it should have been conversational programming.
The comments should be the things that you would tell a new team member during a pair programming session. You assume she knows what the syntax of the language is, but you don't assume she knows the business intent behind the code or the history of trial and error that led to its current state.
> Now, if someone lets me put images in comments, that would be amazing. Good for state transition diagrams and random scribbles
That's exactly what JetBrains MPS (https://www.jetbrains.com/mps/) does. Even better: the state transition diagram is the code. Some of my colleagues are playing with it - not sure if it's used in production yet.
Eve places the source of truth clearly in the document surrounding the code. The code disagrees with the description, the code should be changed unless there is some evidence in git that the code functions as intended.
I've been following Eve for awhile and I'm impressed with the progress!
A bug: that flappy bird program listing caused the page to flicker for me. It seems like the content is being repainted over and over. I'm on a Nexus 5x using the stock Chrome. Scrolling that block a ways off the screen made the flickering stop, but it came back when I scrolled back up. Hope this is helpful!
Hi, I apologize if this is off topic but I just thought you should know the site does not display properly in my browser.
Maybe this is just an unsupported use case but I think it's because the browser window isn't wide enough so the text on the left gets cut off. I have my browser window filling up half of the screen.
EDIT: Also: base.js:7035 Blocked a frame with origin "https://www.youtube.com" from accessing a frame with origin "http://programming.witheve.com". The frame requesting access has a protocol of "https", the frame being accessed has a protocol of "http". Protocols must match.
EDIT2: Why does opening the chrome console fix the text cut off issue.... this is so weird.
It certainly isn't off-topic. There's a lot of UX work to do now that we've gotten a solid foundation out of the way. Finding a good way to pack a solid Eve editing experience into smaller screens is high on that list.
I opened the quickstart in Chrome and went all the way through without a hitch until the very end - the last code block doesn't appear to do anything. Clicking submit doesn't update the visible output, nor does it clear the form as the code shows it should.
I'm thoroughly liking the environment other than the hiccups though. I'm not familiar with datalog, but have dabbled a bit in prolog and always liked the way unification felt.
Every time I delve into Xerox PARC and ETHZ papers, along side my own experience, I envision the days when our programming environments would be all like this, even for systems programming like tasks.
They are immutable after a search action, but you can mutate records and values after a bind or commit action. Here is one of the docs on the "add operator", which adds values to a record: http://docs.witheve.com/handbook/add/
I was just listening to DHH's interview [0] on Tim Ferriss's podcast. On the question of beautiful code DHH said among other things "I open up any piece of code in Basecamp and it kind of reads like a great table of contents..." That immediately made me think of the work being done with Eve based on recent screenshots. Can't wait to try it out.
This looks cool! Always like seeing what idbknox comes up with.
I'm still reading stuff, so apologies if this is answered elsewhere, but what is the plan / workflow / constraints to handle prose getting out of line with code? In current software I read / write it's already an issue, I feel like the more you take out of code and put into prose the more this could become a challenge.
We really take two approaches to this. The first is we're trying to build tooling to convince you that this is a good idea. For instance, something as simple as a table of contents generated from headings in your code. It's a great overview of your program, a convenient form of navigation, and it takes hardly any time write. I mean, I've seen tons of programmers do this anyway, with fancy ascii headings. Let's just make stuff like that easy for programmers, and I think that our propensities to keep things organized and logical will work in our favor. So in terms of keeping code in sync, we're hoping these tools will convince you that you want to do it. There is value in doing it. Not just feel-good value of well documented code, but tangible value in easily and logically navigable code, for instance.
So the tooling is the first part. The second part is the actual design of the language. Eve programs are written as a series of code blocks, each one with a very specific purpose of querying data, and then doing a transformation on that data. You create computations just by chaining together these interconnected blocks, each data from another and reshaping it in some way. It's this design that leads to writing very short, single purpose blocks of code. In Eve, you don't reference blocks of code, you only reference the data they create. So blocks don't have names. If you write an Eve program without writing any prose at all, it will be kind of confusing. We find that our users so far tend to write a simple declarative sentence before each block, explaining its purpose. They treat it kind of like an extended function name.
If this becomes convention, you could imagine tooling that actually attempts to keep code and prose in check, by noting changes in code and a lack of change in the associated description. Even further down the line, I'm imagining integrating some of our previous NLP research [1] into the editor. Imagine if the editor itself could tell you that your code isn't doing what you think it is.
Anyway, I think the bottom line for me is this: if we're going to get more people to code, we need to treat programming as a more human-centric endeavor. What if a programmer and an accountant could write accounting software together. Not just with the accountant advising the program, but actually participating in the design and development of the program. Sure, he might not be able to understand all of your code, but he can read the paragraph you wrote and see the output of the code underneath, and with his domain expertise he can understand that the output isn't quite right.
This is interesting. I have one follow up question:
If Eve gets smart enough to understand that the code and the prose diverge from each other, shouldn't it also be able to generate the correct code from the prose? That way you'd eliminate the duplication that is happening. It also should allow you to modify the generated code by modifying either the prose or the code, whatever the programmer prefers.
Pretty neat (understatement). From a quick glance, blend of notebook/literate with smalltalkish introspection.
Kudos for keeping at the idea for long (I remember when you left LT and talked about possible ideas a while back) and delivering something that simple yet inspiring.
ps: the team bug fixing interactions reminds me of IBM Jazz days, it seemed so heavy, and here it seems so light.
Sorry, but what about this is "designed for humans"?
What do the keywords mean? What's the language paradigm? Why do I want this when it's essentially coalescing a lot of APIs into a language that you've provided no spec for?
Why would I want my language to work with slack?!
I'm not impressed. It just looks like another functional language with a bunch of addons tacked on to make things "easier" or "for humans".
As a counterpoint: the example of the document containing blocks of code inside what looked more like a word document, to me, exactly explains visually what "designed for humans" means in this context, and I think it's well put.
I'm sorry, but that doesn't give the connotation that it's "designed for humans". Perhaps if they could give a clear indication of what that means other than "it's in a word document", I'd be more inclined to look at it a little harder.
>I'm sorry, but that doesn't give the connotation that it's "designed for humans". Perhaps if they could give a clear indication of what that means other than "it's in a word document", I'd be more inclined to look at it a little harder.
To be fair, this can easily be read as bitter. "I'm sorry, but", "Perhaps if they could ... I'd be more inclined to look" both come off that way.
No, he's absolutely right; it's not clear at all how this is supposed to be human-friendly. I think it's incredibly hard to read and looks like it's going to be an unmaintainable mess by throwing random APIs like Slack into the standard library. I wouldn't say I'm salty, but I'm certainly confused as to why this is what it claims to be, rather than just a very specific beginner web dev language.
Watching the video is probably the best way to get an understanding of what it's about. It's hard to describe an "experience" with text. Their video made more sense to me than most of the written explanation.
That's kind of the the thing that literate programming is trying to solve[0]. But if the experts aren't able to do it for their own product, what chance does a random programmer have with their own code?
"When we communicate to one another face-to-face, we use gestures, expressions, intonation, etc. to articulate an idea. On the internet, when we communicate with just text, much of my meaning is lost forever and never apparent to anyone who reads this.
Programming is much the same way."
While I like the idea, the problem with the demo is that it has about 10 files, with a bunch of small code blocks. What does it look like in a real-world application with 1000s lines in 100s of files?
There are also instructions on that page you can follow (installation via pip) if you already have a reasonably modern version of Python installed, and you have an appropriate C compiler available. This is a pain to configure if you are using a Windows machine.
Assuming the 'jupyter notebook' command succeeds, a browser window should pop up, displaying a UI for manipulating individual notebooks.
If you have already successfully completed the installation, and are instead looking for guidance on using Jupyter Notebook itself, then your best bet would be to look at some of the examples: https://try.jupyter.org/
That's not revolutionary at all. You can do that already with tons of environments. Here's one for Javascript, based on Markdown: https://github.com/jostylr/litpro
I guess if you approach it as a "programming language" it's odd. I understood nothing of the syntax nor the semantics. But you have to admit that the way it relates different dimensions of a "program" is much more approachable than any IDE out there, in a way that is more "humane" I guess.
How I see it, languages are only one projection of what a program is. The missing part is what confuses "normal" people (unlike people who spent long hours learning how to map things in their head). This project reminds me of AOP, old IBM multidimensional orthogonal concerns projects. You can go back and forth between different views of the program, that helps tremendously.
It does more of the heavy lifting automatically. For example, rather than having to explicitly build a data structure to keep track of events that have happened, or build some message bus to receive and react to them, Eve allows you to express the fact that you want to react to them, and its runtime takes care of the rest.
How well this scales and remains available, well, that's an implementation challenge, but the user interface looks very convenient. It is potentially a higher level of abstraction over current "high level programming", just as high level programming was over assembly.
What you describe is normally handled by any number of perfectly good libraries. The selling point here seems to be "we've thrown a bunch of random libraries together in the standard library", which isn't a super compelling argument to me.
Could you share an example library or framework that allows a programming model similar to what they demonstrate in the video? I'd like to learn more.
I am aware of frameworks that can pass information around in similar ways, but only with a lot more ceremony of the sort that's not necessarily a benefit. Observe specifically the code blocks with "search" that react to events without needing to be connected in any direct way with event production; and event production doesn't need to involve data structures or storage.
Maybe this model won't work in applications of meaningful scale, but maybe it will.
Here, I think you are wrong. I strongly suspect that while the high-level features of programming languages are chosen for human consumption, the implementation details and tooling are often chosen arbitrarily, or for machine-convenience. For example, I don't generally consider language environments where the leading white space on a line matters, or languages where trailing white space matters to be "designed for humans." Computers might be good at counting spaces, but we're mediocre at visually estimating the width of a blank area in text. Such an environment asks the user to develop more machine-like skills rather than attempting to accommodate their weaknesses.
Or it asks the user to use tabs? Or an editor that inserts spaces when you press tab? Indentation has never been a stumbling block for anyone but the most junior of programmers.
Sure, there are all sorts of ways to lessen the pain of syntactically significant indentation. Indeed, I'd say that the annoyance can be made sufficiently small that by the time someone is an experienced enough coder to recognize that the pain has always been communally self-inflicted, they're too used to it to care.
Do also note that I'm not saying that indentation is by itself bad.
There's plenty of meat in the blog post, on the Github etc. I suspect it's for "humans" because it's literate, functional programming with a REPL and a natural approach to how data is managed. It's a lot more than just a functional programming language. When did it become cool to make uninformed claims about how worthless other people's work is?
Sorry, we're not trying to call you an alien, quite the contrary! We appreciate that you are a human, and we feel a lot of our tools aren't designed for people like you and me. Our argument is that even our best tools today are built with constraints imposed by the earliest computers (isolated, single core). We've moved past these limitations technically, but our ability to program to the best of our ability on these new, more capable machines (connected, multi-core) is hamstrung by restrictions still imposed by even the newest languages. Look at Swift, a brand new language that can only offer time-travel debugging in a special playground context.
What we're saying is that it's time to move past writing code for the consumption of the machine. If we want the power of computing (not necessarily programming as it exists today) to be more collaborative, and more inclusive; and to reach a wider, more diverse audience, then our tools need to start being designed for humans. Right now Eve is focusing on a table of contents, readable and relevant error messages, and clean, consistent, simple semantics. It's a modest start, but that's where we are. :)
So again, I'm very sorry we offended you, and I hope this explanation helps make our view clearer.
I think "for humans" is just intended to convey that the language and environment are based on research into human cognitive traits: how we think and learn.
The basic premise is we Humans are cognitively build to remember and follow stories. Eve supports Literate Programming, so you can write code like a story.
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 previously used hacked-together languages. There's few languages where someone or a group sat down to carefully engineer them to meet specific objectives with proven success in the field at doing those. Examples include ALGOL, COBOL, Ada, ML for theorem proving, BASIC/Pascal for learning imperative, and some LISP's.
So, if we're designing for humans, what does that mean? It means it should easily map to how humans solve problems so they can think like humans instead of bit movers (aka machines). BASIC, some 4GL's and COBOL were early attempts at this that largely succeeded because they looked like pseudo code users started with. Eve appears to take it further in a few ways.
They notice people write descriptions of the problem and solution then must code them. The coding style has same pattern. They notice people have a hard time managing formal specs, the specifics of computation, error handling, etc. So, they change the style to eliminate as much of that as possible while keeping rest high-level. They noticed declarative, data-oriented stuff like SQL or systems for business records were simple enough that laypeople picked it up and used it daily without huge problems. They built language primitives that were similarly declarative, simple, and composable. They noticed people like What You See Is What You Get so did that. Getting code/data for something onscreen, being able to instantly go to it, modify with computer doing bookkeeping of effects throughout program, and seeing results onscreen is something developers consistently love. Makes iterations & maintenance easier. They added it. Their video illustrated that changes on simple apps are painless and intuitive compared to text-based environments with limited GUI support. Their last piece of evidence was writing their toolchain in Eve with it being a few thousand lines of code. Shows great size vs functionality delivered ratio with the quip about JavaScript libraries being bigger illustrating it further.
So, there's your meat. Years of doing it the common way, which wasn't empirically justified to begin with, showed that people just don't get it without too much effort. Then they keep spending too much effort maintaining stuff. Languages like COBOL, BASIC, and Python showed changes to syntax & structure could dramatically improve learning or maintenance by even laypersons. Visual programming systems, even for kids like with Scratch, did even better at rapidly getting people productive. The closer it matched the human mind the easier it is for humans to work with. (shocker) So, they're just doing similar stuff with a mix of old and new techniques to potentially get even better results in terms of effective use of the tool with least, mental effort possible by many people as possible with better results in maintenance phase due to literate programming.
That's my take as a skeptic about their method who just read the article, watched the video, and saw the comment here by one of project's people. I may be off but it all at least looks sensible after studying the field for over a decade.
I did Smalltalk in school and once you peel away a few layers it doesn't feel like it was designed for humans at all. Perl is also said be designed for humans but takes a very different approach.
This is a neat idea. But I'm wary of the pitch, at least a little. I like to know what my code is doing, at least in general. So when they said "programming designed for humans," that worried me: I don't like magic, that that's usually what "programming for humans" entails.
Underwhelming 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.
Personally I find literate programming helpful not for simple programming tasks, but for really hard ones; if you can quickly scan a few lines of code and figure out what's going on, then you probably don't need it. But if it's the kind of code where I know even future-me is going to have a hard time understanding what I've implemented without copious comments, then I really like literate programming.
And it's more than just a different notation for comments. I find it psychologically elevates the narrative in a way that makes it feel like at least equal to the code in importance, therefore I end up being a lot more thoughtful and deliberate in writing the narrative.
For code maintenance I've long since given up on assuming the comments are correct and simply read code and try to understand what is going on (and maybe read the comments later to see if they correlate to my understanding of the code). Many times I see that when fixing code, people don't update comments and a few times I've seen the comment indicates good intentions, but the code doesn't live up to the intentions :-).
But I do see your point about it for more complex programs and maybe more complex programs of your own (that a future you will have to maintain).
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.
How is this significantly different from something like Light Table? (edit: didn't realize it was build by the people who built Light Table). It feels like a rehash of that + Python notebooks, with a bit of Xcode's playground thrown in.
Problem is that despite those tools being available, I literally never use them. Ever. Nor do I have a need for them.
I kind of like the idea of being able to find bits of code in a larger codebase in a document-like format. That's actually a pretty neat innovation here.
But beyond that, I don't think I'd use this (edit: per comment thread conversation below, I'm upgrading this to not being sure if I'd used this, but it's a maybe). I need an IDE that will help me through the Battle of Stalingrad, not a basic case like a police offer pulling someone over for a speeding ticket, which is what many of these kinds of next-gen UIs always seem to show.
Basic stuff is easy enough to accomplish right now. I don't need a new IDE to help me add a button to each row in a list any quicker than I currently can with existing tools, and I feel like a core problem with these types of efforts are that they start with basic cases and never really progress from there - many engineering problems simply do not reduce down to adding a button to a screen.
That all said - I think if you pivoted and built a wiki-like overlay that could be dropped over an arbitrary codebase (e.g. extrapolate out the document-like overlay over code to document and organize a codebase), holy crap, I would instantly pay money for that, especially if it was distributed team-friendly.
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 graphics and even some basic MIDI sound effects.
I think "looks excellent for children" is a sign that it might be excellent for experts. We want something that can represent a system in the clearest simplest way possible. So simple a child could see how it works and so simple that mistakes are obvious. The question becomes "Will Eve scale to systems that solve real-world problems and not just toy examples for kids?" Will an Eve solution for a real-world problem look simpler and easier to understand than it does now in the languages we're using today? One data point in its favor is how much they've accomplished in so few lines of code if the IDE, the compiler, and a relational database are implemented in 6500 lines of code.
Eve's language runtime includes a parser, a compiler, an incremental fixpointer, database indexes, and a full relational query engine with joins, negation, ordered choices, and aggregates. You might expect such a thing would amount to 10s or maybe 100s of thousands of lines of code, but our entire runtime is currently ~6500 lines of code. That's about 10% the size of React's source folder. :)
Agree completely, although I’m a little less excited about documenting code structure than the use of real-time feedback for code.
I’m a firm believer that minimizing the feedback-loop is directly correlated with productivity and code quality. Just taking the time to set up robust debugging tools (breakpoints, data inspection/manipulation) in my projects has given me more than one “wow you work fast” in my short career,
That's fair. We don't talk about it in here because there was already way too much to discuss, but we've done a few non-trivial things in Eve. All of the inspector interactions are actually written in Eve [1], as is the program analyzer that provides the intelligence to make it work [2]. An important thing to keep in mind as well is that Eve does a lot with very little. 10kLoC of Eve would implement most systems twice over. So the programs will always be pretty short.
The intent is to handle anything you could imagine writing in python. As this is 0.2.0 of a language pretty unlike anything currently mainstream, we're nowhere near there, but with engineering there's no reason we can't be. The IDE is only one portion of the story here, the languge is another one. It's a variant of Datalog that has far reaching implications on how we can work in teams (global correctness), how software evolves (complete compositionality), and how we think about larger scale systems (orderless and distributed). The latter will be the highlight of our second milestone where we'll do another big release like this one, but for the rest we'll be doing deep dives over the next couple weeks about how we believe this language scales much better to the realities of software today.
And that's fair too. Honestly I'm happy to see where you guys go and reevaluate whether or not I'd used it as you guys make progress. There are definitely some very interesting innovations in what you're doing, and hopefully that point came across in my comments (despite some initial scoffing on my part).
I never said I've never used them. I've used them and decided they were not useful for me based on those experiences. So no, in this case, I do in fact know.
Except you describe the kinds of problems you typically solve (placing a button in a row) which are the smallest/simplest case of the problems that we're talking about, so it seems that you might not know about the problems that other devs face in composition of business logic, layering of complex build chains, etc or see a reason why solutions to these problems would ever be useful. Fair enough, but then you probably aren't the target market, so it doesn't make much sense to ask for a pivot to something else.
I really think you guys are misunderstanding my comment. Placing a button in a row is not a complex thing and frankly not something I spend a lot of time doing or worrying about. Look, it's just not. Does it require a new type of tool? IMO, no, it really doesn't.
I'm quite aware of the kinds of problems "other devs face", and they are far more complex than plopping a glorified view inside of another view and hooking up an action when someone taps it.
I simply do not see enough in Eve to convince me that it will significantly help with much more complicated things - things like what you describe - composition of complex business logic, layering complex build chains, etc - and here's a few other common things I don't see it providing significantly new and interesting support for:
- creation and management of complex data models and how they map down to SQL or NoSQL persistence
- orchestrating complex, multithreaded processes
- API design and management
- cloud infrastructure architecture, design and management
- container design and management
- transaction processing
- analytics
etc...
Could something like Eve progress to encompass those types of activities? Possibly (and frankly I'd love to see it - imagine something like Eve's UI for seamlessly managing infrastructure across Azure, AWS, Google Cloud and on-prem infrastructure - that would be amazing). But IMO, it's starting by solving the wrong kinds of problems by reinventing the wheel (new language).
Like I've said before, I don't need or want a new IDE or language to help me with trivial problems. I want tools that help with the harder stuff.
Actually it is the other way around. Apple Playgrounds in XCode and SWIFT were inspired by Light Table. Chris Lattner, the creator of SWIFT even publicly acklowledges Light Table as inspiration on his blog:
I think there's potentially a lot of ways we can improve our programming environments. I like moon shots, people willing to explore new ways that are unconventional, approaching problems in different ways. I've followed Light Table and have been looking forward to seeing what Chris and friends come up with for Eve.
That said, this is feeling very grandiose. I'd like to understand more clearly where they see Eve being useful — and where Eve would not be useful. For example:
- how does one implement new algorithms? A simple example, how do I write Quicksort?
- can Eve be written in Eve?
Admittedly, I haven't thought about this nearly as much as the Eve team has. And perhaps I'm just lacking the required imagination at this point. That said, I'd like to see these types of questions addressed. There's nothing wrong with a tool that's useful in a particular set of circumstances. I'd like to know what the Eve team thinks those circumstances are.
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.
2) sure and we have written some of it in Eve, check some of my other comments for links :)
Thanks for the follow-up. Indeed, the link you provided is exactly what I was asking for. (And I see that it's there in your initial post as well.) Cheers!
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 latter, then how do you track such dependencies? Are they fully specified declaratively by queries? And what is the granularity—per term, per database?
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
This smells like a game maker app, in the sense that it's hiding "all that messy coding stuff" behind "a simple friendly interface."
Programming isn't about syntax. It's about telling the computer exactly what you want it to do, in every possible situation. The hard part isn't the language you use to tell the computer what to do. The hard part is making sure the instructions you're giving match what you want to happen.
I'm not saying it's impossible, but every time I've encountered something that's meant to 'make programming easier', once you get beyond 'hello world' all it does is get in the way. You still have to communicate the same amount of information to the computer, but now you're doing it with duplo blocks instead of a milling machine.
You're not wrong, but I don't think they're interested in that kind of criticism about the fundamental purpose or goal of the project. I imagine they want more higher-level kind of feedback. I mean, they've already invested quite a lot of time into the basic premise, they probably can't or won't really want to change it at this point.
Hey Taneq,
The fear of over-simplification is totally reasonable. Programs like Game Maker certainly gain their shallow learning curves at the expense of overall power, precision, and depth. We don’t think that tradeoff is acceptable either. Luckily, there is a difference between architectural simplicity and “kid-friendliness”. That’s a big part of why we had to start from scratch and build a new language -- we needed something that was simple from its core if we wanted to make it simple to use without losing expressibility. Rather than rehash the specifics of our architectural decisions (though I encourage you to check out the blog and the upcoming deep dives if you’re interested!) let me describe briefly some problems I don’t have to deal with anymore when I use Eve.
- Asynchrony is pain-free (no imposed cost, no alternative syntaxes, no callback hell).
- Programs are live by default -- there’s no need manually listen for changes all over the place, and no falling out of sync.
- Programs are easily extensible -- because of the above, anything that conforms to the pattern for a block will get picked up by that block.
- Mocks, shims, and other injection patterns are free -- making testing and experimenting very easy.
- Refactoring is trivial -- If a block changes, I only ever need to change its immediate downstream users to get back to a working state. Eve can find those for me.
- Everything is data, so state sharing is trivial. When a coworker finds a bug in my code they can save their exact state and send it to me with a single command.
- The number of classes of bug are drastically reduced. This doesn’t mean they aren’t occasionally perplexing, but because there are so few ways for a program to fail, I can literally run through a checklist of possibilities while debugging. This is the premise that powers the inspector.
This certainly isn’t a complete list, but it’s a few of my favorite quality of life improvements that I think sets this project apart. If you do get the chance to use it, I’d love to hear your thoughts on what works and what doesn’t for you.
Well it's kind of like SQL, in some ways. With enough building blocks it can significantly make game development easier (reminds me a bit of Director's Lingo too). That said the problem arises when one wants to add functionality to the DSL, it's often extremely messy.
First impressions: I like the look of this language/IDE. It's not general purpose but it seems to be good at what it does. I think live programming - where you make changes to your code and immediately see the effect without having to recompile and restart your system - is the way forward. The adoption of literate programming is interesting - I think commenting code is unsatisfactory for a variety of reasons and am looking for an alternative, and Knuth's idea might be worth building on. The other idea I like is the ability to point at a widget and find out the code that draws it - that makes debugging a lot easier.
A possible reason you were initially downvoted is that your interpretation doesn't seem terribly likely because the team gives off no air of looking down on anyone.
Your edit sure won't help anything, the aggression is just uncalled for.
Maybe some people here are sensitive to bad words and their favorite language being called out. Another possibility about why you're being downvoted is maybe your comments aren't as funny as you think?
BTW, went through your post history and it seems you just comment telling people how to behave and telling everyone how sensitive you are while contributing nothing of value whatsoever. What a clown.
If it wasn't already clear, I don't really give much consideration to opinions of me formed via the internet.
I'm still not sure what you hope to actually accomplish, but I assume that like all trolls, you get a minor emotional boost from people taking you seriously, so you're welcome.
I had no idea one had to involve the UN to unlock the downvote button! Serious business that.
I've avoided it myself as you seem to be quite "triggered" over losing a few meaningless points on the internet. I hope the rest of your day goes better.
Instead of thousands of debugger options, let's have a magic tool where you click on the thing that's going wrong.
There are reasons for the thousands of options though! Like, "debug this specific object" or "breakpoint when this condition is satisfied" exist as primitives already; there's more complexity there than just "what is the data backing this UI element". If Eve has indeed managed to get away from needing them, that is laudable, but it would be achieved by the full set of things you might want to do being blindingly obvious, not "magic" special-cases for "I was expecting something here and I don't see it"
The application renderer and editor are wholly separate, though for this release we don't yet provide an end-user way to access the former separately. With respect to distribution (in the rolling out to users sense), we plan to start working on that story over the next few months. To get there, we need to finalize our policy system (which lets you secure your program against malicious users), improve performance, and get the basis of our horizontal scaling story in place. If you're interested, keep an eye out for posts about the world scale computer milestone on our blog!
Seems to me it will have some good uses. The promo of it being "more human" is a stretch, yes, esp. given the actual programming language didn't look any friendlier than any other language imo (e.g. world<-[#div style: [user-select: "none" -webkit-user-select: "none" -moz-user-select: "none" children ...)
But it's nice of them to make a valiant effort at trying to create a new method of doing things. Reading the "What Eve Is" page is helpful:
Heh, as another commenter said below, "i see the first problem is that you're generating HTML". The nice thing is, that is in no way intrinsic to Eve. The @browser DB is a regular DB like any other that we happen to sync to the client, and the client has a bit of code (which users will be able to extend in the future with other functionality) that takes HTML-shaped records and turns them into actual DOM on the screen.
Since we are targeting programmers first right now, it seemed better to focus on other aspects of the editing experience than to try and re-invent document markup to start with. That said, we're not opposed to exploring that possibility down the road. If you have any thoughts on the subject I'd love to strike up a conversation on the mailing list [1].
LightTable was not updated for a year now. I actually backed it and now the IDE seems abandoned never to reach 1.0. I've lost trust in the developers and I won't recommend Eve to anyone because of the fear that they will abandon it as well and start chasing the next big dream.
Just for context: 0.8.0 and 0.7.0 were both release near the end of the year with one year between them[0] (2015 and 2014 respectively). If there is a 0.9.0 coming up I'd expect it in late November or December this year, accordingly.
However there has been barely any progress[1] on the GitHub repo since February (compared to the previous years), the last commit was 20 days ago and even before that there were typically several days in between commits. So it's fair to say the IDE seems abandoned.
However, the LightTable devs have stated that they see Eve as the logical continuation of the idea behind LightTable[2]. While the promise that "LightTable will continue to go on strong" seems to be the typical startup pivot lie I don't think their behaviour is quite as erratic as you make it seem.
By the way, I'm also a Kickstarter backer and I have the shirt to prove it. I was hoping for a nicer JavaScript IDE and would have been very satisfied with their original promise but I can see the appeal of going a step further. The move from LT to Eve feels a lot like a bait and switch to those who just wanted a better IDE for the languages they currently get to work with.
Seeing Eve's development out in the open is inspiring. Many of the commenters are coming from positions of extreme skepticism towards new approaches to programming, probably justified by the history of the field, but I'd recommend to spend some more time looking into the research idbknox and his team have been conducting (see https://www.youtube.com/watch?v=VZQoAKJPbh8, for instance) and how much they have iterated based on user experimentation.
A few questions come to mind now:
1 - This new demo, with the messaging app sample, and references to "my pm wants this or that" seems to point a change in positioning, from targeting non-programmers to professional programmers. Is this accurate?
2 - Is there a plan to integrate the grid-style or the adlibs style UI into this new iteration?
3 - If non-programmers are still a target, it seems to me that the ease of importing data from external sources would important to reach broad usage. Any research here?
4 - Html and css might be a hurdles for new users, any way Eve will help on this front?
1. We could be more clear about this, but expanding to suit the needs of non-programmers is still very much in the cards. It falls under the umbrella of milestone 3 [1].
2. We're very interested in improving the process of generating UI. To start with, that will mean expanding our library of views (essentially Eve's version of web components) to cover a wider range of common use cases. Beyond that though, HTML is pretty crufty with layers upon layers of of additions and legacy support, it would be very interesting to explore alternative markup models.
3. It certainly is very important. Our model for interacting with the external world is pretty simple. For the most part You can use our first party modules (like `@http` for web requests) to pull the requisite data into Eve where you can transform it into whatever shape is appropriate. For cases where you need entirely new transport systems (like connecting Eve to USB devices), you can create a new module just like the first party ones and side load it in. Since the runtime is currently written in Typescript, that's the language of choice for these extensions. We may support others in the future.
4. For users unfamiliar with HTML and CSS, the best we can do is insulate them from it, as in #2. If it's a subject that personally interests you, I'd love to strike up a conversation on the mailing list about how we can improve the markup process [2].
400 comments
[ 1.3 ms ] story [ 285 ms ] threadMany of the folks here have been following us for a long time and we're really excited to finally pull everything together to show you all where our research has taken us. Eve is still very early [1], but it shows a lot of promise and I think this community especially will be interested in the ideas we've put together. As many of you were also big Light Table supporters, we wanted to talk about Eve's relationship to it as well [2].
We know that traditionally literate programming has gotten a bad rap and so we laid out our reasoning for it here. [3]
Beyond that, we expect there will be a lot of questions, so we'll be around all day to try and answer them. We'll also been doing a bunch of deep dives over the next several weeks talking about the research that went into what you're seeing here, how we arrived at these designs, and what the implications are. There was just way too much to content to try and squeeze it all into this page.
Also, a neat fact that HN might be interested in:
Eve's language runtime includes a parser, a compiler, an incremental fixpointer, database indexes, and a full relational query engine with joins, negation, ordered choices, and aggregates. You might expect such a thing would amount to 10s or maybe 100s of thousands of lines of code, but our entire runtime is currently ~6500 lines of code. That's about 10% the size of React's source folder. :)
[1]: http://programming.witheve.com/deepdives/whateveis.html
[2]: http://programming.witheve.com/deepdives/lighttable.html
[3]: http://programming.witheve.com/deepdives/literate.html
In the real world, the answer is almost always "the code that's actually been executing, rather than the comment that hasn't," which is why it's a good idea to minimize commentry of that type, to prevent confusion on the part of the reader.
So if you're doubling-down on literate programming, how do you address that problem? That article says, "Inconsistencies between the code and the prose are themselves errors in the program and they should be treated as seriously as a buffer overflow," but does Eve actually do that? It's hard for me to see how it could, in the examples given.
(If the idea is simply that this is extra work for the programmer to do -- that they need to describe every implementation twice, once in code and once in English -- I submit that it's not very human-focused at all, if those humans are programmers.)
As another example, what if it were a method name instead of a comment?
Is your argument that the method name is incorrect because the code dictates a different behavior?Also addresses are not like names. As with names in general, a name can refer to more than one object. (Consider modules, for example.)
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.
that's a rosy way to say, names entail a message.
An Address can also be computed, your argument is invalid.
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.
"Proven in use" and backwards compatibility is a bitch.
So the name definitely helps, but it's not conclusive.
This does not happen in your function name example: if the program requirement changed to print every line, no sane programmer would change the code in this function, they'd write a new function printEveryLine() instead and use that. So you can be pretty sure this is a bug.
If this were only true.
Unfortunately many programmers seem not to be sane.
I'm not sure I understand the distinction you are making here, so I'd like to try and understand. From my perspective, function names are just another form of comment. After all, in many languages, as soon as you press "compile", your function names are mangled into something a machine can understand.
So you feel that programmers are more inclined to treat the function name as an authority, as opposed to a comment. Is that an accurate? I'm curious what lead you to this conclusion.
I think this is a reasonable claim, even though as you've said there's nothing strictly enforcing this behavior. Function names are generally highlighted by the editor/IDE, and the developer is forced to stare at them and at least begin to type them out while calling them. They're brief and repeated over and over again in the source code. They're just harder to ignore. Comments on the other hand only appear once per comment, tend to be italicized and greyed out by IDEs, are generally at least one sentence in length and can span multiple paragraphs, and are never going to be directly referenced from within the code itself. It's still very possible to change a function without updating its name to suit its new purpose. But I know for me personally I'm much more prone to missing comments that I need to now delete or reword. I have to acknowledge the function name when I write code calling it or read code referencing it, but comments are just sort of there, hovering in the background. It's easier to read them once and then tune them out and forget that they're there.
Indeed, someone else will probably end up duplicating the effort of writing the same function over again—but with an accurate name this time—because they aren't aware that the functionality they want exists in the codebase already.
And this is all an implicit consideration made by every programmer, every time they define—or later modify—a function. We all know that we'll "lose track of" functions if we don't call them something memorable for their purpose. So we put thought into naming functions, and put effort into renaming functions when they change. (Or, with library code, to copy-pasting functions to create new names for the new variant of the functionality; and then factoring out the commonalities into even more functions. We go to that effort because the alternative—a misnamed function—is almost effectively beyond contemplation.)
His complaint is that it isn't being done here, so all the prose is jut going to get out of date and incorrect, and meanwhile you have to write everything twice for no benefit.
I'd love to be proven wrong, but I think the problem is that this goal itself is mistaken. If we can formally specify something using a language X, this necessarily becomes a language not "for humans" -- i.e. a formal language that doesn't follow the rules of natural language and that we must be trained in. Natural language is notoriously bad at unambiguous specification.
I suppose that English is imperfect and could use improvements. Ideally those two would converge. That would solve problems about the interpretation of laws, as well. How would that convergence work? To answer that you'd have to know how language is acquired in the first place. I suppose some form of self-reference in the language that mirrors some of Chomskie's stipulated universal grammar, if it exists.
I could see potential in a function-level spec in the form of an append-only transcript, where only one line can be added at a time. So you (with your requirements-specifier hat on) write a line of spec; and then you (as the programmer) write a function that only does what the spec says, in the stupidest way possible; and then you put on the other hat and add another line to the spec to constrain yourself from doing things so stupidly; and on and on. The same sort of granularity as happens when doing TDD by creating unit tests that fail; but these "tests" don't need to execute, human eyes just need to check the function against them.
---
On another tangent: I've never seen anyone just "bite the bullet" on this, acknowledge that what they want is redundant effort, and explicitly design a programming language that forces you to program everything twice in two separate ways. It seems to me that it'd actually be a useful thing to have around, especially if it enforced two very different programming paradigms for the two formalisms—one functional and one procedural, say; or one dataflow-oriented ala APL or J, and the other actor-modelled ala Erlang.
Seems like something NASA would want to use for high-assurance systems, come to think of it. They get part-way there by making several teams write several isolated implementations of their high-assurance code—but it will likely end up having the same flaws in the same places, given that there's nothing forcing them to use separate abstractions.
Imagine if you came across this in actual code. You might first check if the code was changed recently and by whom, and whether the comment or the code came first. But that still wouldn't tell the whole story. To get it all, you would find out who checked in the code, and what their original intent was.
What we're advocating is to treat source code more like a design document. It's a collection of thousands of design decisions all informing the specification of the final product, the program.
> If the idea is simply that this is extra work for the programmer to do -- that they need to describe every implementation twice, once in code and once in English
Right, so the point is that prose is not redundant. As Knuth put it literate programming is "a mixture of formal and informal methods that reinforce each other." When we communicate to one another face-to-face, we use gestures, expressions, intonation, etc. to articulate an idea. On the internet, when we communicate with just text, much of my meaning is lost forever and never apparent to anyone who reads this.
Programming is much the same way. The code only tells you so much about the program. Without any context, readers are often disoriented and confused by new codebases. If no one is willing to read your code, no one will ever contribute to it. GitHub and SourceForge are veritable graveyards of amazing yet abandoned projects that will never see another contribution, because their codebases are so inscrutable. I know I'm guilty of this as well; when I revisit old codebases, I hardly know even what I was thinking.
Anyway, I think there's a lot to explore here. I think what you raise is an issue, and it will always be important to address, but I really believe that literate programming is important and can lead to better code. So we're going to see where we can take it with Eve, and I hope you'll give it a shot!
I'd also like to say that if code is easier to read in the first place, there will be more eyes on it, and discrepancies will be resolved sooner. In most programming environments, a comment might describe a part of a much larger function. But the output of this code is far removed from the actual source. So discrepancies between comment and source are harder to spot.
It Eve, we intend these documents to be for more than just programmers. Who again, might not understand your code, but would understand the written prose and see the output /right there in the code/ that contradicts it. A bug like this would be brought to your attention much sooner than if your code was simply hosted as on GitHub.
Actual thing that will happen, if you're not lucky: Same as above, but they don't delete the obsolete paragraphs.
Why? Where is the prose? What makes programs supposed to be written in Eve different from Eve itself?
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].
[1]:http://programming.witheve.com/deepdives/literate.html
[2]: https://github.com/witheve/Eve/blob/master/src/runtime/join....
[3]: http://play.witheve.com/#/examples/editor.eve
Python is just "ugly" C underneath, containing for example a 1500 line switch statement, but this does not in any way change the fact that it's a great piece of software.
But I'm not sure why it would be considered beneficial to withhold knowledge of intent in favor of purely what's happening; except maybe to junior/support staff that aren't likely to understand the motivation behind a developer's intent. Perhaps, because of the concern that code gets maintained and related commentary doesn't?
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 saying it is a perfect system, but the idea of the comment being expanded to include the 'what' as well doesn't seem like progress in the right direction to me.
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.
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 pretty proficient in the business domains I specialize in, so I can understand, conceptually, what the application is suppose to support and consider the validity of the programmer's intent as well as the code's function.
Given that, why do you need these kinds of comments at all? 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?
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.
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 someone lets me put images in comments, that would be amazing. Good for state transition diagrams and random scribbles)
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 structure than flat text files is needed - simple multi-/hyper-text seems like a minimum. Not only links (most ides have this: hoover to display help, click to goto definition etc).
Why so few seem to successfully add vector graphics and diagrams I don't know. I guess jupyter / ipython might be a rare breath of air. But who really wants to maintain 10k locs of code and 15k locs of tests in ipython notebooks?
We need something more (lively kernel might be more interesting here - webdav for persistence Web browser for run/edit/view - I'm not sure if the required power Canberra realised any simpler).
The best example I'm aware of is probably Smalltalk coupled with monticello version control and a solid object database like gemstone/s (I'm not aware of a real open/free workalike for the last part).
That's not not say relational or logic databases aren't useful - but it's more difficult to manage the data, query code and program code in one integrated system if the database takes the form of an external server. That said, Ms visual studio and the SQL db gui does a pretty good job of presenting a somewhat coherent environment.
I used to be strongly in the Linux/Unix camp - thinking that the datastore we call the filsystem is a good abstraction. But I've come to believe that even the strong legacy of user familiarity isn't a good enough reason to stick with it. Even if we were a little bit more serious and at least went all plan9 - rather than the half-hearted state of Linux/Unix (everything is a file, or a database file, or a binary file or an archive of a filsystem or...).
That said a "filsystem" might very well still be a decent building block for a higher level system (with decent search, for example).
But yeah, I don't think jupyter is the be all, end all of development. But it is an interesting way to move legacy programming environments forward in a low friction manner.
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
But at any rate, why is relevant, and code doesn't express the why.
Comments can be useful for annotating algorithms or referencing stack overflow though.
Comments can be useful for annotating algorithms or referencing stack overflow though.
Requirements are usually exogenous to the code.
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 be displayed in a different way to warn the reader that things are potentially not in sync. How to do that: check if the links point to the latest version. The maintainers have to update the links to remove the warnings.
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 ...)
Sometimes a piece of code needs to be highly optimized to the point of being basically unreadable, at that point it's probably worth adding explanatory comments that you would normally avoid.
The comments should be the things that you would tell a new team member during a pair programming session. You assume she knows what the syntax of the language is, but you don't assume she knows the business intent behind the code or the history of trial and error that led to its current state.
That's exactly what JetBrains MPS (https://www.jetbrains.com/mps/) does. Even better: the state transition diagram is the code. Some of my colleagues are playing with it - not sure if it's used in production yet.
The odd or even lines? I don't think English is going to replace programming languages anytime soon.
A bug: that flappy bird program listing caused the page to flicker for me. It seems like the content is being repainted over and over. I'm on a Nexus 5x using the stock Chrome. Scrolling that block a ways off the screen made the flickering stop, but it came back when I scrolled back up. Hope this is helpful!
Maybe this is just an unsupported use case but I think it's because the browser window isn't wide enough so the text on the left gets cut off. I have my browser window filling up half of the screen.
EDIT: works now!
EDIT: Also: base.js:7035 Blocked a frame with origin "https://www.youtube.com" from accessing a frame with origin "http://programming.witheve.com". The frame requesting access has a protocol of "https", the frame being accessed has a protocol of "http". Protocols must match.
EDIT2: Why does opening the chrome console fix the text cut off issue.... this is so weird.
Fix confirmed!
Awesome stuff though, excited to see where it goes.
I opened the quickstart in Chrome and went all the way through without a hitch until the very end - the last code block doesn't appear to do anything. Clicking submit doesn't update the visible output, nor does it clear the form as the code shows it should.
I'm thoroughly liking the environment other than the hiccups though. I'm not familiar with datalog, but have dabbled a bit in prolog and always liked the way unification felt.
Firefox 49.0.2
Makes it very hard to read.
Every time I delve into Xerox PARC and ETHZ papers, along side my own experience, I envision the days when our programming environments would be all like this, even for systems programming like tasks.
All the best for the road ahead.
The set operator sets a value on a record: http://docs.witheve.com/handbook/set/
These values can be literals, or even other records.
[0] http://fourhourworkweek.com/2016/10/27/david-heinemeier-hans...
I'm still reading stuff, so apologies if this is answered elsewhere, but what is the plan / workflow / constraints to handle prose getting out of line with code? In current software I read / write it's already an issue, I feel like the more you take out of code and put into prose the more this could become a challenge.
I'll keep digging and reading, awesome work!
So the tooling is the first part. The second part is the actual design of the language. Eve programs are written as a series of code blocks, each one with a very specific purpose of querying data, and then doing a transformation on that data. You create computations just by chaining together these interconnected blocks, each data from another and reshaping it in some way. It's this design that leads to writing very short, single purpose blocks of code. In Eve, you don't reference blocks of code, you only reference the data they create. So blocks don't have names. If you write an Eve program without writing any prose at all, it will be kind of confusing. We find that our users so far tend to write a simple declarative sentence before each block, explaining its purpose. They treat it kind of like an extended function name.
If this becomes convention, you could imagine tooling that actually attempts to keep code and prose in check, by noting changes in code and a lack of change in the associated description. Even further down the line, I'm imagining integrating some of our previous NLP research [1] into the editor. Imagine if the editor itself could tell you that your code isn't doing what you think it is.
Anyway, I think the bottom line for me is this: if we're going to get more people to code, we need to treat programming as a more human-centric endeavor. What if a programmer and an accountant could write accounting software together. Not just with the accountant advising the program, but actually participating in the design and development of the program. Sure, he might not be able to understand all of your code, but he can read the paragraph you wrote and see the output of the code underneath, and with his domain expertise he can understand that the output isn't quite right.
[1]: http://incidentalcomplexity.com/2016/06/14/nlqp/
Kudos for keeping at the idea for long (I remember when you left LT and talked about possible ideas a while back) and delivering something that simple yet inspiring.
ps: the team bug fixing interactions reminds me of IBM Jazz days, it seemed so heavy, and here it seems so light.
What do the keywords mean? What's the language paradigm? Why do I want this when it's essentially coalescing a lot of APIs into a language that you've provided no spec for?
Why would I want my language to work with slack?!
I'm not impressed. It just looks like another functional language with a bunch of addons tacked on to make things "easier" or "for humans".
Drop the buzzwords and get to the meat please.
I fear for your bullshitometer. You should get it repaired.
To be fair, this can easily be read as bitter. "I'm sorry, but", "Perhaps if they could ... I'd be more inclined to look" both come off that way.
That's kind of the the thing that literate programming is trying to solve[0]. But if the experts aren't able to do it for their own product, what chance does a random programmer have with their own code?
[0] - https://news.ycombinator.com/item?id=12818653
"When we communicate to one another face-to-face, we use gestures, expressions, intonation, etc. to articulate an idea. On the internet, when we communicate with just text, much of my meaning is lost forever and never apparent to anyone who reads this. Programming is much the same way."
There are also instructions on that page you can follow (installation via pip) if you already have a reasonably modern version of Python installed, and you have an appropriate C compiler available. This is a pain to configure if you are using a Windows machine.
Assuming the 'jupyter notebook' command succeeds, a browser window should pop up, displaying a UI for manipulating individual notebooks.
If you have already successfully completed the installation, and are instead looking for guidance on using Jupyter Notebook itself, then your best bet would be to look at some of the examples: https://try.jupyter.org/
Programming languages by design are for human consumption. In what way is this "special" or "designed" for them?
How well this scales and remains available, well, that's an implementation challenge, but the user interface looks very convenient. It is potentially a higher level of abstraction over current "high level programming", just as high level programming was over assembly.
I am aware of frameworks that can pass information around in similar ways, but only with a lot more ceremony of the sort that's not necessarily a benefit. Observe specifically the code blocks with "search" that react to events without needing to be connected in any direct way with event production; and event production doesn't need to involve data structures or storage.
Maybe this model won't work in applications of meaningful scale, but maybe it will.
Do also note that I'm not saying that indentation is by itself bad.
http://1060nm.com/42/en/
When did it become fashionable to call everybody else some variant of insane or delusioned and tout your own solution?
What we're saying is that it's time to move past writing code for the consumption of the machine. If we want the power of computing (not necessarily programming as it exists today) to be more collaborative, and more inclusive; and to reach a wider, more diverse audience, then our tools need to start being designed for humans. Right now Eve is focusing on a table of contents, readable and relevant error messages, and clean, consistent, simple semantics. It's a modest start, but that's where we are. :)
So again, I'm very sorry we offended you, and I hope this explanation helps make our view clearer.
The basic premise is we Humans are cognitively build to remember and follow stories. Eve supports Literate Programming, so you can write code like a story.
EDIT: all program has to do is to 1) get data 2) transform data 3) output data
Anything that allows to express these 3 steps using less idioms is more "human" language IMO
So, if we're designing for humans, what does that mean? It means it should easily map to how humans solve problems so they can think like humans instead of bit movers (aka machines). BASIC, some 4GL's and COBOL were early attempts at this that largely succeeded because they looked like pseudo code users started with. Eve appears to take it further in a few ways.
They notice people write descriptions of the problem and solution then must code them. The coding style has same pattern. They notice people have a hard time managing formal specs, the specifics of computation, error handling, etc. So, they change the style to eliminate as much of that as possible while keeping rest high-level. They noticed declarative, data-oriented stuff like SQL or systems for business records were simple enough that laypeople picked it up and used it daily without huge problems. They built language primitives that were similarly declarative, simple, and composable. They noticed people like What You See Is What You Get so did that. Getting code/data for something onscreen, being able to instantly go to it, modify with computer doing bookkeeping of effects throughout program, and seeing results onscreen is something developers consistently love. Makes iterations & maintenance easier. They added it. Their video illustrated that changes on simple apps are painless and intuitive compared to text-based environments with limited GUI support. Their last piece of evidence was writing their toolchain in Eve with it being a few thousand lines of code. Shows great size vs functionality delivered ratio with the quip about JavaScript libraries being bigger illustrating it further.
So, there's your meat. Years of doing it the common way, which wasn't empirically justified to begin with, showed that people just don't get it without too much effort. Then they keep spending too much effort maintaining stuff. Languages like COBOL, BASIC, and Python showed changes to syntax & structure could dramatically improve learning or maintenance by even laypersons. Visual programming systems, even for kids like with Scratch, did even better at rapidly getting people productive. The closer it matched the human mind the easier it is for humans to work with. (shocker) So, they're just doing similar stuff with a mix of old and new techniques to potentially get even better results in terms of effective use of the tool with least, mental effort possible by many people as possible with better results in maintenance phase due to literate programming.
That's my take as a skeptic about their method who just read the article, watched the video, and saw the comment here by one of project's people. I may be off but it all at least looks sensible after studying the field for over a decade.
As for Perl, it was hacked together to automate some work Larry Walls was doing on BLACKER VPN at TRW.
http://play.witheve.com/#/examples/http.eve
https://news.ycombinator.com/newsguidelines.html
And it's more than just a different notation for comments. I find it psychologically elevates the narrative in a way that makes it feel like at least equal to the code in importance, therefore I end up being a lot more thoughtful and deliberate in writing the narrative.
But I do see your point about it for more complex programs and maybe more complex programs of your own (that a future you will have to maintain).
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.
Problem is that despite those tools being available, I literally never use them. Ever. Nor do I have a need for them.
I kind of like the idea of being able to find bits of code in a larger codebase in a document-like format. That's actually a pretty neat innovation here.
But beyond that, I don't think I'd use this (edit: per comment thread conversation below, I'm upgrading this to not being sure if I'd used this, but it's a maybe). I need an IDE that will help me through the Battle of Stalingrad, not a basic case like a police offer pulling someone over for a speeding ticket, which is what many of these kinds of next-gen UIs always seem to show.
Basic stuff is easy enough to accomplish right now. I don't need a new IDE to help me add a button to each row in a list any quicker than I currently can with existing tools, and I feel like a core problem with these types of efforts are that they start with basic cases and never really progress from there - many engineering problems simply do not reduce down to adding a button to a screen.
That all said - I think if you pivoted and built a wiki-like overlay that could be dropped over an arbitrary codebase (e.g. extrapolate out the document-like overlay over code to document and organize a codebase), holy crap, I would instantly pay money for that, especially if it was distributed team-friendly.
Well, it's effectively 'Light Table version 2'.
It's written by the same people that wrote Light Table.
iPython, tonicdev... and now this.
I’m a firm believer that minimizing the feedback-loop is directly correlated with productivity and code quality. Just taking the time to set up robust debugging tools (breakpoints, data inspection/manipulation) in my projects has given me more than one “wow you work fast” in my short career,
The intent is to handle anything you could imagine writing in python. As this is 0.2.0 of a language pretty unlike anything currently mainstream, we're nowhere near there, but with engineering there's no reason we can't be. The IDE is only one portion of the story here, the languge is another one. It's a variant of Datalog that has far reaching implications on how we can work in teams (global correctness), how software evolves (complete compositionality), and how we think about larger scale systems (orderless and distributed). The latter will be the highlight of our second milestone where we'll do another big release like this one, but for the rest we'll be doing deep dives over the next couple weeks about how we believe this language scales much better to the realities of software today.
More is coming. :)
[1]: https://github.com/witheve/Eve/blob/master/examples/editor.e... [2]: https://github.com/witheve/Eve/blob/master/examples/analyzer...
You don't know what you don't know.
I'm quite aware of the kinds of problems "other devs face", and they are far more complex than plopping a glorified view inside of another view and hooking up an action when someone taps it.
I simply do not see enough in Eve to convince me that it will significantly help with much more complicated things - things like what you describe - composition of complex business logic, layering complex build chains, etc - and here's a few other common things I don't see it providing significantly new and interesting support for:
- creation and management of complex data models and how they map down to SQL or NoSQL persistence - orchestrating complex, multithreaded processes - API design and management - cloud infrastructure architecture, design and management - container design and management - transaction processing - analytics
etc...
Could something like Eve progress to encompass those types of activities? Possibly (and frankly I'd love to see it - imagine something like Eve's UI for seamlessly managing infrastructure across Azure, AWS, Google Cloud and on-prem infrastructure - that would be amazing). But IMO, it's starting by solving the wrong kinds of problems by reinventing the wheel (new language).
Like I've said before, I don't need or want a new IDE or language to help me with trivial problems. I want tools that help with the harder stuff.
http://www.nondot.org/sabre/
That said, this is feeling very grandiose. I'd like to understand more clearly where they see Eve being useful — and where Eve would not be useful. For example:
- how does one implement new algorithms? A simple example, how do I write Quicksort?
- can Eve be written in Eve?
Admittedly, I haven't thought about this nearly as much as the Eve team has. And perhaps I'm just lacking the required imagination at this point. That said, I'd like to see these types of questions addressed. There's nothing wrong with a tool that's useful in a particular set of circumstances. I'd like to know what the Eve team thinks those circumstances are.
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.
2) sure and we have written some of it in Eve, check some of my other comments for links :)
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 latter, then how do you track such dependencies? Are they fully specified declaratively by queries? And what is the granularity—per term, per database?
Programming isn't about syntax. It's about telling the computer exactly what you want it to do, in every possible situation. The hard part isn't the language you use to tell the computer what to do. The hard part is making sure the instructions you're giving match what you want to happen.
I'm not saying it's impossible, but every time I've encountered something that's meant to 'make programming easier', once you get beyond 'hello world' all it does is get in the way. You still have to communicate the same amount of information to the computer, but now you're doing it with duplo blocks instead of a milling machine.
- Asynchrony is pain-free (no imposed cost, no alternative syntaxes, no callback hell).
- Programs are live by default -- there’s no need manually listen for changes all over the place, and no falling out of sync.
- Programs are easily extensible -- because of the above, anything that conforms to the pattern for a block will get picked up by that block.
- Mocks, shims, and other injection patterns are free -- making testing and experimenting very easy.
- Refactoring is trivial -- If a block changes, I only ever need to change its immediate downstream users to get back to a working state. Eve can find those for me.
- Everything is data, so state sharing is trivial. When a coworker finds a bug in my code they can save their exact state and send it to me with a single command.
- The number of classes of bug are drastically reduced. This doesn’t mean they aren’t occasionally perplexing, but because there are so few ways for a program to fail, I can literally run through a checklist of possibilities while debugging. This is the premise that powers the inspector.
This certainly isn’t a complete list, but it’s a few of my favorite quality of life improvements that I think sets this project apart. If you do get the chance to use it, I’d love to hear your thoughts on what works and what doesn’t for you.
In the mind of the author it probably means 'Designed for reasonable humans and not those dirty nerds who write Haskell and shit.'
Edit: Jesus, why the fuck is everyone getting triggered over this? HN has the most sensitive snowflakes out of any discussion forum.
Your edit sure won't help anything, the aggression is just uncalled for.
Ok bud, shall we call an emergency UN meeting to discuss my 'aggression'?
What do you hope to accomplish with the antagonistic tone?
I'm still not sure what you hope to actually accomplish, but I assume that like all trolls, you get a minor emotional boost from people taking you seriously, so you're welcome.
I've avoided it myself as you seem to be quite "triggered" over losing a few meaningless points on the internet. I hope the rest of your day goes better.
http://programming.witheve.com/deepdives/whateveis.html "Being explicitly designed for data transformation, there are somethings that Eve will particularly excel at..." (after beta stage, of course)
That said, it'll be interesting to see what software people decide to create with it and where this system excels.
Since we are targeting programmers first right now, it seemed better to focus on other aspects of the editing experience than to try and re-invent document markup to start with. That said, we're not opposed to exploring that possibility down the road. If you have any thoughts on the subject I'd love to strike up a conversation on the mailing list [1].
[1] https://groups.google.com/forum/#!forum/eve-talk
However there has been barely any progress[1] on the GitHub repo since February (compared to the previous years), the last commit was 20 days ago and even before that there were typically several days in between commits. So it's fair to say the IDE seems abandoned.
However, the LightTable devs have stated that they see Eve as the logical continuation of the idea behind LightTable[2]. While the promise that "LightTable will continue to go on strong" seems to be the typical startup pivot lie I don't think their behaviour is quite as erratic as you make it seem.
By the way, I'm also a Kickstarter backer and I have the shirt to prove it. I was hoping for a nicer JavaScript IDE and would have been very satisfied with their original promise but I can see the appeal of going a step further. The move from LT to Eve feels a lot like a bait and switch to those who just wanted a better IDE for the languages they currently get to work with.
[0]: http://lighttable.com/blog/
[1]: https://github.com/LightTable/LightTable/graphs/contributors...
[2]: http://www.chris-granger.com/2014/10/01/beyond-light-table/
[1] http://www.red-lang.org/2016/07/eve-style-clock-demo-in-red-...
A few questions come to mind now: 1 - This new demo, with the messaging app sample, and references to "my pm wants this or that" seems to point a change in positioning, from targeting non-programmers to professional programmers. Is this accurate?
2 - Is there a plan to integrate the grid-style or the adlibs style UI into this new iteration?
3 - If non-programmers are still a target, it seems to me that the ease of importing data from external sources would important to reach broad usage. Any research here?
4 - Html and css might be a hurdles for new users, any way Eve will help on this front?
(edited for formatting)
1. We could be more clear about this, but expanding to suit the needs of non-programmers is still very much in the cards. It falls under the umbrella of milestone 3 [1].
2. We're very interested in improving the process of generating UI. To start with, that will mean expanding our library of views (essentially Eve's version of web components) to cover a wider range of common use cases. Beyond that though, HTML is pretty crufty with layers upon layers of of additions and legacy support, it would be very interesting to explore alternative markup models.
3. It certainly is very important. Our model for interacting with the external world is pretty simple. For the most part You can use our first party modules (like `@http` for web requests) to pull the requisite data into Eve where you can transform it into whatever shape is appropriate. For cases where you need entirely new transport systems (like connecting Eve to USB devices), you can create a new module just like the first party ones and side load it in. Since the runtime is currently written in Typescript, that's the language of choice for these extensions. We may support others in the future.
4. For users unfamiliar with HTML and CSS, the best we can do is insulate them from it, as in #2. If it's a subject that personally interests you, I'd love to strike up a conversation on the mailing list about how we can improve the markup process [2].
[1] http://programming.witheve.com/#justataste [2] https://groups.google.com/forum/#!forum/eve-talk