Allow me an analogy: "Bronk, the math designed for humans." Instead of dense algebraic expressions like "3x+49", you get to write "thrice the value of x plus 49." You may consider this a straw man, but I think that if you look hard at existing programming languages, you'll see that they are all designed for humans, and that the challenge in programming is in formulating your thoughts in a precise fashion. Should languages create higher-level abstractions to allow humans to reason about programs more efficiently? Yes! But that's not what this environment is about.
I do see one possible rebuttal to this, which would be an entirely different form of programming that is to traditional programming what google search is to the semantic web; that is, rather than specify programs precisely, we give examples to an approximate system and hope for the best. In many ways, that's how our biological systems work, and they've gotten us a long way. I don't see that happening in Eve, though.
Even your example shows it instantly. We know how to read 3x+49 but would have to ask of "thrice the value of x plus 49", "did you mean 3 times what you get from adding 49 and x or 49 more than 3 x's?".
Projects to humanize programming always seem to suffer from "magic genie" syndrome. When you ask a genie for $1mm you don't expect him to go rob a bank or kill your dad for his life insurance to get it. Human language makes tons of implicit assumptions about the recipient. It would take a general (strong) AI to make that work with a computer.
The ultimate expression of success would have your "program" simply read "I'd like a game just like Flappy Bird but with my logo instead of the bird".
But Eve is a full programming language. The "humane" aspects are not about making the language more ambiguous, but about changing the focus of tooling from the machine to the human. It's about things as simple as Unicode support for language localization. Or rendering headers in your code. It's about making the syntax and semantics very small and easy to understand. It's about closing the write-compile-test loop, by showing the result of code /in/ the actual code. It's about debugging tools that work with you to solve a problem.
We're just saying we don't want to compromise. We want a beautiful, concise, easy to understand language AND we want humane tooling. In order to get that, we had to abandon the traditional imperative programming model, and that comes at a cost. But I think in the long term it will be worth it.
There are a lot of really interesting approaches there. I really like the ideas!
I think a lot of service devs (read: stateless) won't get it. But people who code front end and deal with business logic daily might find something to love in here.
Worth discussing if nothing else! You got my star!
>It's about debugging tools that work with you to solve a problem.
>we want humane tooling
I know how hard it is to explain what exactly your product does. I myself constantly struggle with this. Eve is an interesting concept that is worth a closer look and discussion. But you guys need to learn how to explain its benefits using a less ambiguous language.
Sorry, you lost me right there. If you need headers, you've already run off the rails (no pun intended) IMHO.
It is not a new mistake. Many people thought that programming with GC, or with high-level languages, or with generics, was just a kind of magic that couldn't lead to understandable programs. But these things succeed because, while they allow you to stop worrying about certain details, they do so while still remaining perfectly well-defined and unambiguous.
The fact that you no longer can know how the low-level details will be handled can be very uncomfortable. If there is most of what you have spent your programming career doing, it seems like it must produce ambiguity and inefficiency. But this isn't generally the case. Optimizing OCaml compilers can often produce code faster than C simply because the higher level of expression expected from the programmer leaves more room for the implementation to generate the right low-level code.
I won't say that I know Eve will be successful, but it certainly is possible. It produces unambiguous behavior which just happens to no longer specify lots of details most programming environments make you think about. When I think about the work I do, most of which involves providing live representations of data, and executing certain rules when it changes, I would guess that most of the details I worry about are extraneous and could be dealt with by a sufficiently-smart environment that encompassed both the database and the program.
When your language and runtime provide good tooling for constraining the state space, then that allows you to elide specification of those extraneous details.
E.g., some form of GC is a basic runtime requirement for most of the HLLs today. They could almost not exist without it.
There's a difference between producing unambiguous behavior given a specific input and making it easy to create that input in the first place.
I'm with you along the lines of embedding defaults to reduce the boilerplate code needed to get a minimum working app, but there comes a point where this may end up requiring advanced coders to learn how to go deeper in order to override those defaults to get novel results. This could result in a language thats easy for a beginner to get started in but difficult for the intermediate to progress any further.
Lots of things that show tools and ideas that would make learning programming a lot easier.
Well, maybe not the first time. But players in my campaigns tend to learn quickly.
This is especially common in discussions about humanizing programming. I think it's partly because people are invested in the current way of doing things, having spent so much time developing their particular skills; and partly because our attempts at serious alternatives have largely been failures, so far. That makes it easy to see any new idea in this space and automatically class it as already understood. But there is room between C++ and toy visual languages, and someone may find something good there yet—and this will illuminate things just that much more if nothing else.
Look into the lineage of ideas the Eve team have moved through to get where they are today, and you've got to admire their search process even if you don't like the results.
In any case, it's patently false that Eve's innovation is analogous to the algebra example given in the parent.
The concepts here are fantastic. Unfortunately, as intelligent as they are, many in this industry seem to have difficulty grasping the benefit of user-focused design, abstraction and simplicity.
UI design by CS engineers has always been terrible; programming languages are no exception to that.
It isn't virtuous to suffer unnecessary complexity. And programming shouldn't be complex just because we can manage it in spite of the complexity.
The language presented is a variant of datalog and is as formal as any other language. If you're curious in the semantics, they boil down to Dedalus [1].
As a simple example of that, here's a clock: http://play.witheve.com/#/examples/clock.eve
[1]: https://www2.eecs.berkeley.edu/Pubs/TechRpts/2009/EECS-2009-...
https://www.youtube.com/watch?v=R2Aa4PivG0g
---
Edit: Actually Chris Granger gave an Eve talk at the same conference. It's interesting to see how Eve has evolved since.
This is really nice work. I mean this in the best possible way: I think I could teach my children to use this.
http://www.red-lang.org/2016/07/eve-style-clock-demo-in-red-...
Non-programmer: OK, Eve sounds great, so, I want to search for a Slack message. How would I do that?
Eve-programmer: Obviously, it's just:
search @slack
[#message from body]
Eve-programmer: Easy! In the same way, you just:
commit @email
[#email to: "corey@kodowa.com"
subject: "It's party time!"
body: "Hey Corey, the party starts this Friday."]
The challenge of programming has always been wrapping your head around very formal abstractions and "thinking like the machine". These Eve snippets still look very much like a programming language to me. I don't think they will mean anything to a non-Eve-programmer without training in the semantics of how Eve programs work and the syntax of how to build the expressions, and the model over which the operate.
Eve very well may be a big productivity advance over current development environments, but I don't see it eliminating programming as a profession anytime soon.
In any case, check out our followup on what Eve is and isnt [1] - we're under no delusion that this is the end user story... yet :)
[1]: http://programming.witheve.com/deepdives/whateveis.html
Up until that point, software engineering will be a well paid job. I really don't understand this attitude that everyone should be a programmer or that programming should be easy. It isn't easy. Obviously, we should remove unnecessary friction from the process, but framing your thoughts precisely takes discipline. Building maintainable systems takes practice and understanding. It takes years of study and work to become a good engineer.
I definitely think people should be exposed to programming in school, but we study physics and chemistry there too and nobody expects everyone to be a physicist or chemical engineer. Specialization is a good thing.
That said, I'm down to compete with whatever you people think can replace me. I love a good challenge.
The difference with software engineers is that they have the power to build their own tools; physicists and chemical engineers largely don't, unless they themselves are also software engineers. You aren't going to use knowledge of chemistry to build general software but you can always find a use for software engineering in any domain. This puts it in the same category as literacy and mathematics, rather than strictly being a specialization pursued toward its own end.
As a far-fetched example, think of Lego. You can't "fail to compile" your Lego bricks. You have a finite selection of bricks (all clearly visible and usually available within arm's reach), and your job is to just lay one at a time. Given any brick, it's "obvious" to a human how it fits with other bricks. The worst you can do is essentially create a crappy Lego design. As you noted going from a rough thought of
"Uhm I want to build a Dragon of about this size..."
to a finished build requires a powerful AI. But we don't need to go that far to be better than
"Place $brick1 in p=(32,17) at orientation o=(0,pi); place $brick2 in p=(38,15) at o=(-pi,0); ..."
The rigidity of the bricks inherently prevent you from overlapping them, but not the above declaration :)
messages = slack.search()
email.send(to='corey@kodowa.com', subject='hi', body='yo')
let messages = search slack_message body
And moreover its promise appears to be exactly "higher-level abstractions to allow humans to reason about programs more efficiently", in direct opposition to what you wrote here.
EDIT: Of course programming languages are designed for humans... they wouldn't exist otherwise. But they also tend to be pretty strongly influenced by the imperative nature of assembly language. The Eve team seems to be asking: What if we ignored that entirely? In a way this seems a lot like a spreadsheet - you can write a lot of little code blocks that aren't executed in any particular order and yet produce deterministic results.
∀ e, ∀ d, ∃ N : ∀ n > N, P(|Xn - Y| > e) < d.
A more human way to say this is that eventually, we will become arbitrarily confident that X is arbitrarily close to Y. This is the notion of convergence in probability, and the formalism of that concept is way easier to process with a little human explanation. Density of notation helps sometimes, but not always. When the math isn't trivial, it's the case here too.
I agree with this, as it has the most potential to bring an entirely new paradigm to software development.
I've been working on a research project like this, using genetic algorithms to write programs. Unit tests are used to guide the fitness. The AI discovers a solution program that satisfies the test cases.
Using Artificial Intelligence to Write Self-Modifying/Improving Programs
http://www.primaryobjects.com/2013/01/27/using-artificial-in...
>Should languages create higher-level abstractions to allow humans to reason about programs more efficiently? Yes! But that's not what this environment is about.
Uh, ok? It's certainly about more than that, but the language is built on high-level abstractions, making at least certain class of problems very efficient to reason about.
> ... that the challenge in programming is in formulating your thoughts in a precise fashion
Yes, one might say that the real problem[1] is how to teach people programming quickly. I'd say that a good environment is likely to be an important part of any solutions to that problem though.
It will not be the whole solution though. People will have to put in some work, and at some point improvements in environment/language will see diminishing returns. At that point you'll need better/new pedagogic techniques too reduce the learning time.
When that point is reached is unknown. I don't think it's there yet, but maybe it's not so distant.
If the we restate the problem to "how to make as many people as possible learn programming" some type of gameification is probably an efficient solution.
I think it actually is. Under the hood, when you look beyond the "Literate programming is awesome" it seems to be more along the lines of terse reactive prolog?
I am not sure if they managed to do what they envisioned, but this might be the "next spread-sheet".
The global invariant example is a good one. That's not just expressing the same thing less tersely.
Were you thinking of Notation as a Tool of Thought?
There was a not-so-distant time when mathematical theorems were expressed in plain English, without any precise notation. With the introduction of more precise ways to express mathematical statements and logic, mathematics has proliferated, since there is a standard to express problems and results.
While I love toy models as toys, I don't think there is a real use case for toy models in a professional development workflow.
I think you're on the right track when you said "thoughts in a precise fashion"
Humans don't think in a precise fashion. And that's why I think pattern-matching with "give examples and hope for the best" is a way forward.
Think about how we program. We are given requirements and we noodle about it for a bit and start writing some code that is nowhere close to what the final source will be.
When I think about pattern-matching within the context of Eve, I think of automating the way us, as humans, go about our programming. We have some idea of what we want to do, and typically we need to google stuff for APIs and examples. Let's automate that to a certain extent. Let's use the machine learning advances that have happened in the past decade to automate much of the "research" that we all do when we program.
As a programmer, I'm still surprised how luddite-like we are when it comes to our tools. Many of us still are still in the "programming language + text editor" = "programming".
But most of us use tools to help use look for definitions, to do refactoring, to explore our code base. We need to take that to the next level, where some fuzzy logic is used by our programming systems to say "yeah, I think I know what you mean, are any of these examples close to what you're getting at?"
I think it's all about the tooling these days. We need much more advanced tooling to help us out.
That is not how one writes software...
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. :)
[1]: http://programming.witheve.com/deepdives/whateveis.html
[2]: http://programming.witheve.com/deepdives/lighttable.html
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?
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.)
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)
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]);
}
}
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.
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.
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!
Why? Where is the prose? What makes programs supposed to be written in Eve different from Eve itself?
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 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?
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.
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!
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.
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!
Firefox 49.0.2
Makes it very hard to read.
Awesome stuff though, excited to see where it goes.
The set operator sets a value on a record: http://docs.witheve.com/handbook/set/
These values can be literals, or even other records.
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.
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.
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.
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.
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
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.
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...
Well, it's effectively 'Light Table version 2'.
It's written by the same people that wrote Light Table.
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,
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. :)iPython, tonicdev... and now this.
You don't know what you don't know.
What's wrong with Vim? I think they're trying to cater to "the non-programmer crowd" with this, but by trying so hard it's alienating real programmers. I love vim, and I hate Medium with passion. I'm sure there are a lot of other HN people who are not so much a fan of the types of people who just write meta posts, rant posts, listicle posts, self help posts, growth hacking posts on Medium and call themselves a "maker" without actually building anything meaningful. So, you've lost me there Eve. Anyway, that aside, looking more into how this tool really works, this is NOT something an everyday Joe will use like they speak English. This is an actual programming language. The language itself is no easier than python or ruby (actually subjectively speaking the syntax is less intuitive than python for example).
Also I think they're imagining that Excel users will just eat this up, since it's kind of like how people run pseudo-programs on excel documents. But people used those because Excel was the most popular app that lets them work with numbers back then. Now there are many ways to achieve what Eve is trying to do, plus Excel. Why would any lay person jump on an obscure technology doesn't do anything significantly new?
Overall I think there's a problem with assuming that this is for "humans" just because it's "literate programming". "Humans" don't want all this literate programming stuff exposed. They just want to push a button and take care of things. On the other hand, programmers (I guess we should call them "non-humans") don't need all this literate programming stuff. They are trained to understand how programming languages work. They may think this is neat at first, but very soon will start to think all these comments are getting in the way.
I have personally never seen any programming related technology titled "... for humans" actually work for "humans". Perhaps because these tend to be built by extremely talented programmers who are too talented that they are out of touch with how their grandma uses computers, they probably think their creations are easy enough for "humans".
Sorry if this sounded too negative. I am willing to discuss and correct my comments if I am wrong about anything.
All programming tools are for humans. But they're also almost exclusively designed with the expectation that the user will be able to devote afternoons, weeks, months, years to learning the tool. That's a fair expectation if your target audience is programming professionals... If it's your job, you can amortize those learning costs over some months of paychecks.
But that a) creates a high barrier to entry for people to get into the biz. And b) mostly locks out people who want to do just a little programming. I.e. the Excel crowd.
The field Eve is in, so called "end-user programming" is still trying to advance beyond spreadsheets, which were the last big win for non-(professional programmers). Well, HTML was probably in there too. WordPress templates, etc. But spreadsheets were probably the last quantum leap in the field.
We're overdue for another.
> We're overdue for another.
I'm working on it, and do think I have a solution. Unlike Eve, for example, you can (and we do) create (almost said "write", but there's no textual code) an OS kernel in it.
And it's nothing like the approach Eve is taking, which I consider to be nothing like why spreadsheets were (and are) successful.
To me, Eve is nothing more than textual datalog programming + a high-level stdlib + a UI wrapper.
The only area we agree is that logic programming is an underutilized paradigm, and in my visual programming environment, I do use it for business rules (where it absolutely excels).
I agree the high-level stdlib is a problem. I think what we need is an easy-to-dip-your-toes-into environment that provides a path down into "real programming" and ideally down to metal.
I think the big problem isn't exactly UI or language or high enough level APIs, it's the way the APIs are structured. The two big issues I see with most tools are:
1) tendency to layer opaque frameworks on top of opaque frameworks which makes debugging down into the system difficult, if not impossible. (i.e. React) In this sense I think it's interesting that Eve is trying to build on top of itself. Anywhere there's an opaque layer you are putting a massive learning curve for anyone who is grappling with the finer details of that API.
2) declarative interfaces. (i.e. Ember) These require the programmer to have detailed knowledge of the inner workings of the runtime. Feels like we need tools that are made of primitives that the consumers of the tools have a clear path to understanding. There is this idea that the user will never have to understand how the tool works, but my experience is that you always eventually do. You always need to understand the layer below you, so the task is to make those layers easy to dip into... not to try to insulate your users from the details.
Eve seems to partly fail on both of these.
What does your approach look like?
The main limitation of a language like that is that, if you care about performance at all, you have to program for the machine first, not for humans.
You're always writing for both to some extent. For me this is the main challenge of programming; writing code that executes efficiently and correctly, and that is legible to humans.
I love Python and other high concept languages but if I want to code for performance I need to understand what the machine is doing. The tower of abstraction is so high with these languages, at the end of the day it's easier to go, eff it, I'll do it in C, than to try to understand exactly how this code will be executed down at the bottom of the tower.
That's why I wonder where Eve fits in. Most people don't want to program. And this is NOT because they're stupid. It's because they have tons of other important things to worry about. Most people don't want to build their own TV set. They buy it because their expertise is in other things. Maybe they're a doctor. Maybe they're a fields medal winning mathematician. Heck, I'm a programmer and deal with all kinds of programming languages but don't want to know what's going on inside my TV set.
I'm reminded of the original MVC paper[1] - about presenting an interface that matches the users mental model, through the interactive graphics and back into the computers internal data model.
Earlier it occurred to me how crazy it is that so many of our popular languages work on such primitive data structures still. The most obvious being null-terminated ascii strings in a globalized world - where ascii is effectively always the wrong choice (or at least, "not best"). But I'm thinking more about using any other structure than images, 3d models, databases. Why do we work so often with bare variables? I mean, in embedded programming, I guess it's interesting to think about two's compliment, overflow etc - but really. If we can't even handle numbers, vectors in a natural way - aren't we doing something terribly wrong?
The more I think about it, the more I come to believe that many of the ideas of hypertext, Smalltalk/Object Orientation, HyperCard, CAD/3D programs and 2d drawing packages (as well as decent DTP programs) are on the right track: let us use type information and other meta-data to manipulate structures - both "code" and "data" in richer ways. Let me see my code as a graphical finite state machine/diagaram. Allow me to work with my generated matrix as a heightfield in 3d and as a greyscale image. Let me visualize the steps of my sort algorithm, not just look at assembler in a debugger. Why not show me my stack(s) as 2d or 3d stack(s)? Not all the time, but when I want to?
I do like vim, for editing text, and working with our rather dumb programming languages, that might be considered "text+". But they're not really rich, they are hard to visualize, listen to, paint on. And for some things, that's fine. All we need is some text.
But I would argue most good history books has a few images, and maps. Rich media. Even math books do. Maybe the problem with fourth generation languages have been that they wanted to "fix" programming. Rather than just fix some parts, like Elm, with its natural integration of stepping back and forth in time.
Vim is a great tool - but it may be overspecialized on manipulating text: text objects, lines and letters. Those are not generally the semantic objects of programming (excepting perhaps those that make a living coding in brainfuck). I view lisp as a way to simplify "down" to text. And something like hypercard, smalltalk or the lively kernel project as attempts at simplifying "upward" -- to work with the structure. But that requires something beyond simple, human-readable text. You need to save a workspace, and a memory image. The systems acquire a lot of complexity in order to realize their simplicity.
But in case of lisp, the system is generally rather complex underneath. There's still compilation to machine code. There's still some kind of graphical interface, font rendering. Maybe what amounts to a different operating system who's only job is to boot your operating system that runs your lisp environment...
Personally I don't really think C is particularly simple. I still have to look at the assembly to know what's going on. And if the code ends up running on an Arm, or a CPU not yet invented, I'm still kind of lost. I don't really understand the details of how the assembly I can read, interacts with hyperthreading. In the end, what I really care about is the effect of the code - and that is really something I need to test and measure in the context of a running system. And the complexity of that, is likely so that I end up with sampling under various conditions, and doing some timing runs.
This "eagle view" approach doesn't mean I don't ever think about memory layout, algorithm complexity and such. But it does mean I rather rarely think about what actually happens deep inside the machine and the three cache layers.
[1] http://heim.ifi.uio.no/~trygver/themes/mvc/mvc-index.html
Emacs is better ;) But the comparison is a bit disingenuous. Medium is a blogging platform, VIM is an extensible text editor.
I watched the video, and immediately realized I would never want to program in that kind of environment. The "literate programming" would get in my way.
It would be like having someone follow me all the time and translate my words in realtime right next to me whenever I speak something. (Actually it's more like me saying something in English AND having to translate after every sentence) It's super distracting because I can't focus on what I'm saying because I lose my train of thought.
It's ironic, being a programmer that automates things that people used to do manually, and kind of doing good but leaving someone unemployed. How fitting it will be to suddenly become mostly obsolete as a profession, due to programming being very easy or even done by AI. Dogfooding, anyone?
The problems are working with now are so much more difficult and will continue to be more difficult as software makes our job easier.
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?
The 'story-like' literate programming is the direction in which programming will (should) move in the future imho.
Visually, you could explore the idea of 'literal-visual' programming (just invented), something like:
commit [#imageFor #student "student-icon.jpg"]
Then have a button to toggle between rendering records as text and 'visual' records, in which "[#student ] is replaced with a pictogram. Now you have a more 'abstract' look at the algorithm - could be interesting.
Similarly, an entire block of code could be switched to 'visual view', which displays the block as an image, which could be, for example, the screenshot of the last output it produced.
---
The Core language is interesting - declarative, functional and dynamically typed (right?) query language. Some Prolog scent there.
My only concern is that it might be a bit too 'limited' for larger scale applications ?
But for exploratory data mining, it looks like a great tool.
It seems to be well suited for queries in large scale distributed databases (like a p2p network) - is my intuition correct ?
If true, then I can see interesting ways in which Eve could be integrated with ipfs for example and used as a data mining tool...
I enjoy things that create sparks of ideas in my mind, Eve has done that for me today ;).
Check out Inform 7, too.
I find it a really beautiful system that's super fun to work with. And showing ordinary people the code is great!
These days I'm working on a kind of interactive documentary about the collective house where I live and the environment around it. Mini games for the renovations and firewood gathering and stuff, mazes for the nearby central market and the home improvement department store, and various random stories that happened here. It's really fun!
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.
How do you handle version control, and merge conflicts?
If you don't have that figured out, none of the rest of this matters. Because a programming language designed for one developer isn't designed for building software.
The ergonomic presentation of a three way merges is not a solved problem in text-based programming languages, but you have to have something if you want more than one developer working on a single project.
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.
I think that Eve won't be conducive to creating applications beyond a few hundred lines of code -- after that, the "human-friendly" programming paradigm becomes an obstacle to production. Once people actually understand how the code works, the document style becomes superfluous.
I suspect that Eve will be a great learning tool and pique the interest of those who would otherwise never program, but Eve will be an introductory tool that users will inevitably graduate from to other languages that are perhaps more powerful, concise, and scale better.
I can see this fitting a niche between Excel and "normal" programming. That niche might be a lot bigger than we think.
I think we may be a bit blinded as regular programmers to who is actually a programmer, and where programming happens.
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.
I guess Eve is their prototype of the back end for that?
You can build charts like this in svg or html right now. Basically, in Eve we are just generating the records necessary to render these views. We have a separate process that's tied to the browser that takes these records and turns them into something the browser can understand. So Eve isn't tied to html; if you write your own translation layer (and we will have many more by default in the future) then Eve can generate whatever you want.
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
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].
My feeling is that the language itself is not really any more human-friendly than any other. You say in the "what Eve isn't" section that it's not for non-programmers-- but if the environment and language were both truly human-friendly, one benchmark of that would likely be a lower barrier to entry for non-programmers.
That said, again as a non-expert programmer, I see massive value particularly in the "document" approach-- though I see it less as human-friendly, and more as human(s)-friendly. Most of my programming experience has been as a graduate student, either scientific programming or (small) app and website development, and it is often the case that code is passed down in time from person to person. Each time you get someone else's project you initially have to rely on code organization conventions, file names and comments to figure out how the program really fits together, before you can even start working with it (and the tendency, for small-ish projects, is to want to avoid this work and just rewrite it yourself). The code-as-document approach seems wildly better for these particular use cases. I want to echo king_magic's comment, that if a wiki-like overlay could be used on top of an arbitrary codebase, it would go a long way toward human(s)-friendly programming, and I'd use the heck out of it.
so just a nice rendering of comment? sounds like it might be possible with syntax highlighting and markdown-enabled comments
Our current learning stack for folks with zero coding experience is Scratch (https://scratch.mit.edu) to Processing (https://processing.org) to Java.* I'll be watching the Eve project carefully to see how it might fit into our intro to programming path.
*If these intro students continue to our full program they learn C#, SQL, PHP & JS/HTML too.
A question regarding the centrality of data: when I first read about this, I thought an important part would be a kind of user interface for building relational databases - perhaps something like fieldbook. You mention Eve already includes a relational query engine - is a UI for modelling tables and for data entry also on the roadmap?
The reason that we are releasing an Eve focused on developers is that we want something more immediately useful while we research what the right direction is for the UI.
But before we get there, we could definitely see some tooling for the current version. You could imagine a grid block that is embedded in the document, for instance.
After 15 years I've learned to hate languages like these for building anything slightly complex.
However...
The great thing about all these languages is there's choice for everyone. There are as many pet peeves and ways of thinking as there are developers. There is a language for (almost) every type of case needed.
So use whatever the hell makes you love programming the most (or hate it the least), gets the job done right and makes your business(or employer) money or does something helpful for your users.
I might like like the flavor you like but, you might not like mine either. And guess what, we might both be totally right about the requirements met by the languages we use for our own work.
Maybe I missed something but it doesn't seem like this is really designed for usage outside the browser environment?
As such it seems like this is really just a very high-level layer on top of JS rather than a general-purpose programming language, a lot like Jupyter Notebook and friends.
I guess the biggest challenge Eve faces is the same one faced by all those other 5GL "languages" that are now rotting at the bottom of a dumpster: How do you become relevant beyond a tiny niche problem space?
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/
Here are my reasons:
1. I've actually coded something similar a long time ago (I think Eve is even better than my solution) and it worked. My team and I were able to make entire apps in a heartbeat.
2. The reason it works is because, as pg famously wrote, programmers think in the language they use. Our cognitive load and power are function of the language we think in. The key to Eve on this purpose is that you can program not only your app, but the development organisation that goes with it. Also, it is beginner friendly.
3. With 1. and 2., you get that Eve is related to reflectivity and homoiconicity. Maybe it is what's behind homoiconicity: your code and your organisation share the same language.
I wish the Eve team the best.
Instead of thousands of debugger options, let's have a magic tool where you click on the thing that's going wrong.
Combining the source, tutorial documentation and program output along with the ability to selectively enable blocks of code makes for a unique experience that I haven't seen elsewhere (Jupyter Notebook comes quite close, however). I recommend anyone reading this to give it a shot: http://play.witheve.com/#/examples/quickstart.eve
It's a shame the majority of the posters here seem to be preoccupied with the tagline, rather than the actual project.
[0] http://fourhourworkweek.com/2016/10/27/david-heinemeier-hans...
I wonder how well these ideas work as you ramp up to complex algorithms though. For example 5 nested for loops with 10 000 records of data would likely choke your visualisation to death. Also often the decision of choosing your data structures (list vs hash table vs concurrent queue vs ...) are paramount to the performance of the application. A single DB I can't imagine always being the best approach, but one idea could be to measure the data frequency passing though and optimise for the best structure perhaps? Similar to how SQL operates at the moment.
The idea of splitting functionality up into blocks is interesting, though I think you are focusing too much on the literate side of things. I think I would just keep the English text to a minimum, only explaining the 'why' and let the code explain the 'what/how'. But forgetting that, the block separation idea is nice enough on it's own, especially with the table of contents.
I've not looked very in-depth at the language, but what you did in the video did seem a bit like magic at times, and the simplicity seemed to hint at a lot of code hidden away behind simple looking APIs. Meaning doing anything out of the norm would find yourself having to roll a lot of your own code, but I could be assuming wrongly here so won't dwell on it.
I did notice that there was no autocomplete popups in the video. Does this mean you've forgone a type system of any sort? I would hope not as TypeScript has shown the productivity hike adding a few simple type annotations can give. Fully 'dynamic' code bases tend to be nightmares after a certain LOC threshold.
All in all congrats for giving a new outlook on programming by combining a set of old ideas in a new streamlined way, and giving HN something else to grumble about for a while!
[1] http://www.red-lang.org/2016/07/eve-style-clock-demo-in-red-...
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.
As always the question is whether it will scale - being so distributed code-wise seems to imply it will also be hard to trace errors or perhaps at some point increase confusion. Would this work for giant complicated apps/websites? Would be nice to see examples/attempts at that.
This would help with those scenarios. Its perhaps not the best tool for general programming but it looks promising for creating maintainable data centric utilities. Instead of all those spreadsheets.
- Make it easier for non-programmers to program
- Make it easier for programmers to program
While I can see that the current roadmap advances toward both those goals, I don't see what the Eve team plans to do when those two goals start pulling in opposite directions.
Will Eve be kept simple and a second UI be created for programmers? Or will Eve continue to be the programmers' tool, and a second UI be created for non-programmers in mind?
The alternative of keeping a single tool for both audiences makes me shudder, as it will literally end up being "code in Word". It is precisely because Word tries to be all things to all people writing prose that it is such a bloated mess (granted, it isn't the only reason, but it is a major one).
I'm not even certain whether a UX for non-programmers would just a subset of the one for programmers, or if there are likely to be features specific to non-programmers.
> An IDE like Medium, not Vim
Thing is, vim is not complicated because of some misplaced elitism, vim is complicated because it helps with complicated problems. (I am a zealot for the church of Emacs, when I say something "nice" about vim, it is because honesty or pointy objects force me.)
Unfortunately it goes downhill from there, it is nice that there is a way to visualize memory in five lines of code, but what about the memory of the following three processes (and the one thread in red and the others in some other color?) In my experience, there is a trade off between the power of a language and the impressiveness of the examples. (A better example would probably be the twitter api, does that mean I need to beg the core developers to talk to the next "slack for dogs" api?)
Then there is the "zoom" feature, I have not the slightest idea what that is supposed to mean. (Actually I have, I just don't think that this side of a strong AI coworker it is possible to hide information in any useful way. (Hiding information is just the inverse of zoom.)
And to top it of, there is a link to the demo and the first thing I notice is, scrolling is broken. (Arch, Firefox, NoScript with in this case all JS sources allowed) Well, the first thing a IDE should allow me to do is to display text in the most reliable way possible, even if that means more than one page. (Plus it is in a browser, which may or may not be only for demonstration purposes, but at the very least the browser uses the right mouse button to display browsery options not IDE options.)
After having fired up chromium, there the IDE works and it actually works kind of well. To keep with the overall negative tone of the comment, almost as good as Jupyter. The first thing I notice, is that one can switch code blocks on and off, but the output depends non linearly on the set of switched on code blocks. For this one would likely need some kind of toggles for sets of code blocks if it should be usable at all. (So to switch on extra test cases, or to test only one part of the program, etc.)
In conclusion, it is a nice project and I wish the devs all the best. Hopefully one of these days someone manages to get literate programming to work. But I think that there are quite a few things which make me doupt that this is, what makes literate programming work in the end.
Did you consider any niche market where it could actually become the main tool? Education come in mind first, but I'm not sure it would be a good "introduction to programming", given how different it's from, well, all other languages. Maybe it could be good in art classes, though, helping kids to build digital and interactive creations, and even write a story around need, through the documentation centric approach.
I like the medium-like bar on the left to browse blocks. Checking the boxes next to the blocks you want to show is a neat way to make a view of just the functions you want to look at. Putting it in a browser, like iPython/Jupyter improves accessibility for people whose main job is not developing software (the Eve demo makes a good example of being able to pass an analytics view to a teammate in marketing).
I do find myself wondering how a literate programming system like this would scale for a large project (I expect the Eve team have thought about this more than I can imagine).
Great polish on the demo, too :)
1. Black box
By hiding away the complexities of schema design and information indexing, Eve cannot be accepted as a proper framework for any professional project. As soon as performance starts to be a problem, there is nothing one can do to help. In the same vein, not having local variables means there is a whole lot of small things you can't do. Doing flappy bird is one thing, I doubt you can make a fast Tetris with this. Rotating pieces will be a nightmare. I mean, even in Eve, you HAD to add "functions" like cosine and sine, just for your demos. If you can't define these functions, you kind of proved that Eve was incomplete...
2. For humans?
I personally don't think that eve makes it particularly easier for human to program. I mean, this is a type of programming that is not new. You can do eve-like programs in any language easily. In c#, you can do an Eve engine with 1 big list of dynamically typed records and Linq queries on it. Yet, it's not the way people like to program. The only real world example that I can think of is D3, which in many ways shares the eve search / apply / bind model. And D3 is pretty great, but many people have found it hard to grasp, and it is likely that the limitation of the approach are ok when dealing with graphics, and much less so when deal with general purpose programming language.
You can introduce programming by making an analogy with a cooking recipe, where you have ingredients (input), and a desired output (whatever the recipe is for). The recipe would process the input and through a sequence of defined steps, turn it into the output.
The average human is familiar with the concept of cooking to some extent so we can say that analogy would work "for humans".
This, in contrast, fast-forwards directly into some concepts like functions, how to evaluate functions, etc... and that's where I stopped reading. This is not "for humans". Might be a viable language, sure. But let's be objective, leave superlatives and weird claims aside.
I wrote in this article
https://medium.com/@thallukrish/debug-assistant-2aa37ac13ca5...
I get that this is the early days of the project, but I would love to see some information about how your program is actually stored/compiled, how you can version control and deploy it, and how you can interact with files/databases outside the 'eve' universe.
If not this, then this idea. Or this idea with more time and features. Impressive already.
I still think Python is a programming language well suited to humans: I'm not sure I want to try to understand (and hold in my head while debugging) how seventeen disjoint blocks of code interact in an event driven UI like in the messaging app example, clever highlighting/jumping or no.
This is what I needed to understand what you're up to here, oddly enough.
From http://programming.witheve.com/deepdives/whateveis.html (which might not be up to date?).
Since this is a web based programming language - i really would like to know how to interop with JavaScript.
In my case i need to use the pixi.js renderer
All the rest looks good. Hopefully it will influence other languages to display their inner workings in a more visual way, maybe even the mainstream ones.
>Only place to try it out is on github
Github is the most terrifying place on the internet for 90% of users (non-developers). I cannot stand when a project is trying to market to regular users but hosts any content on github. I get that this is an early alpha, but come on..
How selfish is it that everything has to be "for humans" anyway? Why can't it just be? Let's not further complicate already-complicated abstractions.