I thought this was a great article when he posted it and it's always really exciting to see people engage with us about the research we've done. He links to it at the bottom, but here's a link to my followup [1].
We've learned a ton over the past couple of years and we've finally settled on a path forward. That means we're starting to move out of research mode and starting to execute on all of this knowledge gathering. To that end, we're going to be doing a public alpha release in the next few weeks for people to play with. :) It ought to be interesting to the folks here to see how crazily different our work could be - the latest version of Eve is better likened to Medium's content editor or Dropbox's paper than it is to Visual Studio. It's been a long road (with around 30 versions of Eve at this point), but there are some really exciting times ahead.
Happy to answer any questions! Though I imagine there'll be plenty of discussion when we do the release :)
Here's a question for you, then. Has any thought been given to the accessibility story for Eve and tools like it?
As a blind developer, I always get a bit nervous when the future of programming is discussed in terms I've read used to describe Eve. It seems like a very useful way of developing apps, but one that can easily exclude a subset of the population if a11y issues aren't thought through in advance.
Also, part of me is tempted to dismiss Eve because I suspect we'll always have the current way of developing software to fall back on. But when I consider it more, I don't find that line of thinking productive for me. For instance, lots of folks might be tempted to dismiss GUIs for blind users because graphics, but there are actually huge advantages to representing UIs as trees of objects that can be introspected and interacted with. I can write code that scans the accessibility hierarchy for a specific element and reads it, for instance. In a command line interface, that code would need to either scan for a non-specific set of characters that a curses app might use to draw a thing that looks like a button and make a guess at its contents, and even then that logic would be very brittle. So even if Eve and whatever comes after derives lots of its power from rendering concepts visually, the underlying primitives needed to do so might have beneficial a11y implications and shouldn't be discounted because the end goal happens to look nicer than a wall of text.
Anyway, would be nice to see that on the roadmap if it isn't already. Even if only 20% of programming is like this in 10 years, that's still a substantial subset that might exclude me by virtue of the accessibility story not being thought out first.
I haven't kept up on Eve development as closely as I would have liked, but I do try to read each blog post which are usually very interesting. After tinkering with something like unreal's blue print visual graph programming, I am inclined to build something similar for Rust lang and game development. Have you considered this approach, I know visual programming hasn't been very successful on a general level but I think it excels at domain specific tasks. Last I checked Eve didn't implement graph nodes and connection widgets, did it ever? Have you considered it? Watching unreal editor run the blue print live and seeing nodes fire off really made me rethink debugging, like the next proper way instead of basic print statements. It also is impressive to see quick results to complex behaviors through wiring up nodes.
hey! you're the guy in the presentation video, correct? can I maybe give you an unsolicited but constructively-intended suggestion? (initially decided it was a bit too OT, but I happened onto this thread 6 days later and figure there's not much to derail now--if you'll even read this reply).
anyway, suggestion is to try and keep your voice at a more constant volume? :) you tend to trail off into a lower level (though not as bad to become inaudible) and then "yeelp" all the way back up at the start of the next sentence, which was occasionally a bit startling :) I was listening to it late at night on medium-large speakers so finding the right level was a bit of a gamble to not wake anyone :-P
either way just a suggestion, maybe there was a reason for that particular presentation. do with it what you will ;-)
and thanks for the interesting ideas on a very interesting topic! :)
The presentation was very enlightening. If this was the future of business application programming I could see that or maybe even the future of programming websites. But as a game programmer I'm having trouble connecting it to my world. But it's titled as the future of programming, so I figure that would include me as well.
What's interesting is the problems you want to address I deal with every day programming games. When you're making games you have to simulate physics in your head and the setup to just get a project ready is a gigantic pain. How could a game programmer use this type of system to make a game? It seems like the complexity would just get out of hand.
> Also, if programming in Excel is so awesome, why am I not developing banking software using it?
Well, if you took away Excel, the banking system would collapse. It might be old and clunky, but it can do anything you need it to. It might not be "real programming", but near enough anyone is able to get a spreadsheet up and running much faster than a POC app that's been built in a proper programming language.
Oh it's real programming, as far as I'm concerned. My problem with Excel is that it has the worst tooling out of any application platform I've ever encountered, and it's subject to the hideous whims of Microsoft on the quality front.
When one imports a CSV into Excel, Excel has a nasty tendency to actually change the data based on formatting rules. When you open up a CSV file in Excel, it silently corrupts the information. You need to back up your file before doing any work on it.
Excel refuses to do proper Unicode, or at least I haven't found the right way to reliably get a Unicode CSV out of it that won't break in third-party tools.
Excel does not do versioning natively, and you have to rely on a buggy mishmash of Microsoft-based solutions to do file-based version management. Excel files tend to get emailed around everywhere, and so there's never a single source of data. It has the worst properties of a decentralized architecture without any of the benefits.
Data belongs in a relational database. You can use a spreadsheet to manipulate it, but the manipulated data needs to go back into the database. The spreadsheets that do this are programs and they need to be managed as code, going into version control systems.
> Well, if you took away Excel, the banking system would collapse.
Lovely comment, and so true. And you're right: for a POC it's unstoppable. I was trying to get to the nub of "why is it perfect for a POC, but not for running an enterprise application"? That's kind of my point, though I admit it was a bit clunkily-put.
At my firm, we are continuously in the process of formalizing excel sheets into auditable applications that don't give enough degrees of freedom to allow our investors to shoot themselves in the foot.
Yep, Excel is the best way for a business person to build an MVP for their needs. Then "real developers" can take that MVP and build a full-blown application if that's what the business needs - often though, Excel is enough - even if it drives the IT people crazy.
Yes - lots of banking software is developed in Excel. I'm referring to the software developed by non developers - by end users. Excel is their IDE of choice. They develop in Excel because vendors and in house IT teams don't meet their needs.
I admire what you're doing, but I can't help but see gaping holes in your card wiki idea.
1. Your examples all seem to suffer from the same problem all of Bret Victors ideas do too; they don't scale. Sure I would like interactivity, no I don't want to re-eval my entire codebase on every keystroke, and no I don't want to recreate my vertex data every frame in the Draw method just so I can scrub a tree's bendiness.
2. The card wiki is too reliant on perfect structure. What if I need to change the structure at some point (refactor), then all my queries break. They'll break even worse too if my queries just says 'get the salaries per department', but then I modify the structure to have two sets of employees per dept (perhaps current and ex-employees), which changes the meaning of the query, yet the computer would plod along and now wrongly sum both groups I presume, if working in this automated way.
3. Performance. Sure it's easy to re-calculate an equation based on dependencies. Want to do 'a = b + c'? Then obviously re-calc 'b' and 'c' dependencies before performing the equation. But the hard part is when to do the re-calculation? Perhaps store an 'isDirty' bool? Or cache the value? Or just re-calc everytime it's needed? Human programmers make this decision based on how the result is used, how many times it is used, framerate, memory consumption and performance heuristics. There isn't a one size fits all, it's highly contextual.
4. You say 'we know Wikipedia works'. But have you tried scraping data from Wikipedia? Computers get stuck on all sorts of dumb stuff. Wikipedia is obviously meant for human consumption, where visual data and the English language rule, and the only structure we need is a 'top to bottom' layout. Programming is way more specific that this, so I can't see how combining the two ideas is any good.
5. Organisation. Perhaps you're still working on this, but you switched back and forth between a single card at a time, but given 20+ cards I'm not going to remember where stuff is. Code editors throw a bunch of stuff into one document, have tabs, and an explorer, and intellisense and search etc - and I still lose stuff all the time!
Hopefully when you do this release you'll include some complex samples, like you said you could build a compiler with these cards? So perhaps I'll be proved wrong.
Yes, reminds me of CASE (Computer aided software engineering) systems from the 90's. In 10 years there'll be no programmers, then the web happened, and it all started again.
In your #2 example, you'd have to pass the semantic meaning to it somehow. It doesn't look like a simple document database. There is logic and semantics. There is a total cost fact, which you'd update by saying total cost excludes employees that are "is:Quit" "is:Fired" etc. All the facts and queries on top of it would then work.
I like the part where he's talking about the programming study he got to do at Microsoft with a one way mirror, where he observes that programmers who say they never use the mouse, use the mouse 50% of the time they are programming.
Use your awareness and ask yourself: Is this person primarily optimizing programming, or is she/he primarily optimizing their social status as a programmer? (Maybe doing the latter is more rational? Doing the latter likely results in higher pay and a more secure job.)
> The lesson from this was apparently, that just fixing the IDE wasn’t enough. Programming itself suffers from the problem that it is indirect and invisible, beleaguered with accidental complexity and unobservable.
These are the two deepest sentences about programming I've read in a while.
Here's the video in a nutshell:
1 - Chris Granger asks a deep question
2 - He observes people
3 - He tries some lateral paradigm
4 - It's interesting
5 - It's bootstrap implemented in only a few lines of code
6 - It's not the right answer, repeat from step 1
I don't know if the statements about the keyboard can be attributed to dishonesty. But when you ask a programmer what they /do/ most of the time, the first thing they think of is programming, and that usually uses the keyboard. But programming is a tiny fraction of what a programmer actually does. Reading, searching, browsing, experimenting, navigating file systems and build systems, running things -- the actual coding is a tiny part at the end, in reality, but it completely dominates the entire activity in our mental model of what it is.
I use the mouse a lot because the VS IDE forces the use of the mouse for all sorts of things. If only there were a simple way of connecting Emacs to the compiler I would probably drop VS for coding and use VS only for code review and other interactions with TFS.
This article was great, as well as the video and Chris's response. It reminded me of 2 problems I've encountered time and time again that I'd love (for someone) to solve.
1. Often presentations, reports, etc. rely on calculated data from e.g. an Excel spreadsheet. Whenever data gets updated it's really tricky to make sure everything that uses that data reflects the latest state. Too often have I heard the phrase in meetings "Oh that graph? Yeah, that's still based on last month's data."
2. I've had very smart colleagues who couldn't program, but could bend Excel to their will. Eventually they'd hit the limits of what's possible in Excel though. It always struck me that a) Excel is basically an FRP system and that therefore b) these people already have most of the skills to program if they had slightly different tools.
I always had an inkling that these two problems were somehow related, but I couldn't put my finger exactly on how they are related or what the solution would be. I'm really excited to see that EVE seems to go a long way to solving these things. I can't wait to see where they take it next. At the same time I also take some solace from the fact that, based on the number of iterations, people who are clearly much smarter than me also struggle with defining and solving this problem.
For 1) hopefully Eve, or a tool like it, can let you do things like:
- Show me all the graphs which don't include this months data, and why / what they are using instead
- Show me the graphs that will change (and/or the ones that won't) when I add this months data
Basically searching forwards and backwards to find where issues are, with enough info/context to resolve mistakes 'bugs'.
And then ideally it would be possible to state an invariant 'this graph must include this months data' and have the system automatically verify it for you.
My first thought on watching the demo was: This seems a lot like Lotus Notes.
The author claims this is a compliment, but generally Notes has a terrible reputation as one of the most over-architected and misused software solutions of the '90s.
You can check it out (in excruciating detail) at this Interface Hall of Shame article from 1999:
I would like to counterpoint. I knew quite a few people I trusted who sang the praises of Lotus Notes.
It was the IBM buyout that started the big downfall.
> all the insane GUIs built using the tools?
Remember VB6 and all the shitty applications written in that? Uh, yeah. And don't get me started on the disasters that people perpetrated on us from the web. And how about the pile of dogshit that was Gtk v1? <shudder>
In addition, this was also still the time of "look and feel" lawsuits.
Everybody had insane GUI's in the 1990's, so singling out Lotus Notes is far from fair.
IBM (Lotus) Notes / Domino does have a fairly elegant core in the form of a high-performance "NoSQL" document database with fast and reliable multi-master replication. The problem was that the development tools they build on top of that database were bizarre and terrible, and then they used those tools to build an e-mail client with poor usability.
The page deals with Lotus Notes as an email system, which is the only thing many places used it for. The email client was awful, but it was one part of a larger application platform that offered a client-server replicated database, a user interface toolkit, and document browsing. If you think of it as attempting to scratch some of the same itches that the Web and wikis do, you'll understand it more.
I actually find it funny when Eve is discussed on Hacker News as most people on Hacker News are programmers, so they look down at Eve in the same way that C++ programmers used to look down at Basic Programmers in the 1990s (you had to be a programmer in the 1990s to know what I mean).
Yet a simpler model did prevail, and now we use so called toy languages like Javascript all the time. Eve's time will come, and in 10 years most of us who frequent hacker news today will be like the C++ developers of the 1990s in that we will be the minority. And languages like Eve and other similar projects will be considered normal programming languages. Java, Python and other languages will just be considered special purpose languages, much as C++ is considered "special purpose" today for high performance computing and operating systems
I think Chris and his team's goals now are more to build a programming tool primarily for the non-programmer rather than try to be all things to all people, and also cater for professionals. So I doubt it's going to have a huge impact on how professional developers work for the issues mentioned, but I do have high hopes this can create something that is more approachable for everyone else, and also a more gentle introduction to programming than I had with learning Pascal. Anything that brings new ideas to the table, such as Eve, Bret Victor's original talk that inspired Light Table, and Light Table as a whole are good for the industry. Apple already used a lot of those ideas when building Swift, which likely wouldn't have happened otherwise.
My first impressions from the talk is that it looks a lot like Wolfram's programming lab [0]. Which is great because while I really like the idea of WPL the cost is rather prohibitive. More competition in this arena is definitely necessary.
What will programming look like in 10 years? My guess is that it will look much the same as it does now. We'll have better languages for expressing temporal logic and consistency but it might not be radically far off from where we are now.
Text is still useful and certainly notations could improve but that's about it.
The idea of programming from tables using declarative or logic programming is certainly not new but very powerful. k comes to mind... which is probably at the extreme opposite end of usability. Never the less even COBOL had a sense of this.
Looking forward to where Eve goes next. My ideal environment is one where I can freely mix hand-drawn "symbols" to data and express relations using familiar mathematical notations in a single free-form canvas. I sort of do this on paper presently but I have to translate this artifact into a programming language to insert values and explore the various dimensions. It'd be nice to have a system that could recognize my notations and let me hook them up to data.
Well... not quite like Wolfram Language; but the connection to knowledge, queries, and building new knowledge from queries. The interface is quite flexible too.
So, I'd like to know others' opinions. Is computer programming today primarily: A form of communication? Arts n' crafts? A virtualized form of assembly/construction? None of the above?
I'm in the arts n' crafts camp. Craftily building up abstractions and playing them off each other -over time- seems to be what we're doing here.
I think any program representation should fit your use case. If Excel or SQL fits for data simulations, use that to program, if C++ and Assembler fits for your systems coding, use that, etc...
I'm not a fan of CASE tools, BPEL, instarepl, naked objects, or any other visual or visual/textual modes of coding for general programming work. I agree with the scalability and productivity issues others have mentioned with visual programming systems. Visual probably has a relevant place somewhere in effective software development, but they're just not general purpose enough because the visual bits and bobs tend to muddle the abstractions and are generally too fiddly.
I intuitively agree/sympathize with the myth that less lines of code == less bugs. I think we should seek for languages and libraries that require less lines of code to get stuff done.
Before we can bravely board our starships and chat with our sentient computers in order to program them, we'll need people to write less buggy code with existing systems. For me, that requires:
* TDD which allows everyone to verify their work
* Employing Agile teams to encourage robust communication and to reduce YAGNI, and
* Establishing software architectures where tools and libraries are chosen -primarily- for their ability to promote developer productivity
Eve == ACPU platform. Same things. http://acpul.org/
PS: I'm looking for help with my project, peoples who like same things. I made that project at 2012, too much things collected for this day. I made LiveComment for save this collection, because this is future of programming.
As a side note, it is fascinating to see many parallels in the referenced Chris Granger talk and the one that Alan Kay gave on the history of the Dyna book in 1986 [1].
Huh, thanks for the link, I hadn't seen this talk of his. We take a ton of inspiration from the work done the 70's and 80's before we decided exactly what "computation" meant. There were so many great ideas that elevated what we could do with computers, it's sad that 40 years later we're sitting here trying to rediscover them.
Perhaps in 10 years we'll have a wider variety of ways to tackle problems by computing, some more suitable to certain problems than others, and we'll acknowledge all such as programming.
I'm a huge fan of datalog, reactive programming, interactive working with a knowledge base and ontologies, and the current iteration of eve has all of these.
However, since these systems have been shown to be somewhat limited by the boundaries of efficient computation or even computability in general I'm hard to convince on this.
I think the only way they can truly convince people that this is feasible is by implementing the system in itself.
Not only will it look the same, but we'll be working with a lot of the same code :) Android didn't exist 10 years ago, but it's based Linux, C++, Java, strung together with Makefiles, shell scripts, etc. All this stuff was well over 10 years old when Android was created.
Likewise, iOS is one biggest changes in the last 10 years, but based on old technology.
I DO think "programming" in 10 years will look quite a bit different than today.
For that to come, a paradigm shift would need to happen. Now what could cause that shift? In my opinion its blockchain technology.
I think one of the platforms which allow to run Code on blockchain will reach critical mass, here is a nice intro talk to one of them:
https://www.youtube.com/watch?v=U_LK0t_qaPo
You may ask but what about my beloved javascript, c++, python or java? Well there is plenty of that used in the implementation of ethereum. And they even try to make their language look like javascript a lot ( look for solidity) to attract developers. But those are just aesthetics which come due to bootstrapping.
And bootstrapping is THE key issue here which eve doesn't even begin to deal with, which would deal with interesting questions like:
How many programs/functions/snippets would a blockchain need to become "liveable" by itself? 10000? 100000? more?
People today think but I do this great "app" and people cando such cool things with it. But the point is, very much as Alan Kay also says, apps are just the wrong thought. Appstores are a JOKE for the end user, you can buy what you want , genius, but can you combine two programms to make it do soemthing interesting? No you can't, you would need files and formats , but ahh.. that war has been lost way long ago.
We need maximal flexible programs, code, snippets. Write something on your own, include something here, send a message there and so on. Something like a giant gloabal object or actor space.
Digital Identity, no user EVER wants to log in, remember? So just get that working, it can be solved with the crypto infrastructure in place.
Scaling to millions of users? Scaling to billion of users?
Most of the solutions, which try something today, including eve, try to do something which is based on a webbrowser. But the point of these "future" things should be how to bootstrap OFF the current browser (technical AND content wise) mess we have today.
So no I'dont see eve giving anything of interest, I don't see it capable to grow into a network. If eve tries to "solve" programming I can't see it, I made some notes about other interesting approaches here:
https://gist.github.com/AndreasS2501/30ffda6d10b1c7ac53b1
[+] [-] ibdknox|10 years ago|reply
We've learned a ton over the past couple of years and we've finally settled on a path forward. That means we're starting to move out of research mode and starting to execute on all of this knowledge gathering. To that end, we're going to be doing a public alpha release in the next few weeks for people to play with. :) It ought to be interesting to the folks here to see how crazily different our work could be - the latest version of Eve is better likened to Medium's content editor or Dropbox's paper than it is to Visual Studio. It's been a long road (with around 30 versions of Eve at this point), but there are some really exciting times ahead.
Happy to answer any questions! Though I imagine there'll be plenty of discussion when we do the release :)
[1]: https://gist.github.com/ibdknox/2b185fcb8e5d1de68796
[+] [-] ndarilek|10 years ago|reply
As a blind developer, I always get a bit nervous when the future of programming is discussed in terms I've read used to describe Eve. It seems like a very useful way of developing apps, but one that can easily exclude a subset of the population if a11y issues aren't thought through in advance.
Also, part of me is tempted to dismiss Eve because I suspect we'll always have the current way of developing software to fall back on. But when I consider it more, I don't find that line of thinking productive for me. For instance, lots of folks might be tempted to dismiss GUIs for blind users because graphics, but there are actually huge advantages to representing UIs as trees of objects that can be introspected and interacted with. I can write code that scans the accessibility hierarchy for a specific element and reads it, for instance. In a command line interface, that code would need to either scan for a non-specific set of characters that a curses app might use to draw a thing that looks like a button and make a guess at its contents, and even then that logic would be very brittle. So even if Eve and whatever comes after derives lots of its power from rendering concepts visually, the underlying primitives needed to do so might have beneficial a11y implications and shouldn't be discounted because the end goal happens to look nicer than a wall of text.
Anyway, would be nice to see that on the roadmap if it isn't already. Even if only 20% of programming is like this in 10 years, that's still a substantial subset that might exclude me by virtue of the accessibility story not being thought out first.
[+] [-] viperscape|10 years ago|reply
[+] [-] tripzilch|10 years ago|reply
anyway, suggestion is to try and keep your voice at a more constant volume? :) you tend to trail off into a lower level (though not as bad to become inaudible) and then "yeelp" all the way back up at the start of the next sentence, which was occasionally a bit startling :) I was listening to it late at night on medium-large speakers so finding the right level was a bit of a gamble to not wake anyone :-P
either way just a suggestion, maybe there was a reason for that particular presentation. do with it what you will ;-)
and thanks for the interesting ideas on a very interesting topic! :)
[+] [-] isaiahg|10 years ago|reply
What's interesting is the problems you want to address I deal with every day programming games. When you're making games you have to simulate physics in your head and the setup to just get a project ready is a gigantic pain. How could a game programmer use this type of system to make a game? It seems like the complexity would just get out of hand.
[+] [-] david927|10 years ago|reply
[+] [-] taco_emoji|10 years ago|reply
[+] [-] elthran|10 years ago|reply
Well, if you took away Excel, the banking system would collapse. It might be old and clunky, but it can do anything you need it to. It might not be "real programming", but near enough anyone is able to get a spreadsheet up and running much faster than a POC app that's been built in a proper programming language.
[+] [-] vinceguidry|10 years ago|reply
When one imports a CSV into Excel, Excel has a nasty tendency to actually change the data based on formatting rules. When you open up a CSV file in Excel, it silently corrupts the information. You need to back up your file before doing any work on it.
Excel refuses to do proper Unicode, or at least I haven't found the right way to reliably get a Unicode CSV out of it that won't break in third-party tools.
Excel does not do versioning natively, and you have to rely on a buggy mishmash of Microsoft-based solutions to do file-based version management. Excel files tend to get emailed around everywhere, and so there's never a single source of data. It has the worst properties of a decentralized architecture without any of the benefits.
Data belongs in a relational database. You can use a spreadsheet to manipulate it, but the manipulated data needs to go back into the database. The spreadsheets that do this are programs and they need to be managed as code, going into version control systems.
[+] [-] dexwiz|10 years ago|reply
[+] [-] bobm_kite9|10 years ago|reply
Lovely comment, and so true. And you're right: for a POC it's unstoppable. I was trying to get to the nub of "why is it perfect for a POC, but not for running an enterprise application"? That's kind of my point, though I admit it was a bit clunkily-put.
[+] [-] bwanab|10 years ago|reply
At my firm, we are continuously in the process of formalizing excel sheets into auditable applications that don't give enough degrees of freedom to allow our investors to shoot themselves in the foot.
[+] [-] bdavisx|10 years ago|reply
[+] [-] osullivj|10 years ago|reply
[+] [-] hacker_9|10 years ago|reply
1. Your examples all seem to suffer from the same problem all of Bret Victors ideas do too; they don't scale. Sure I would like interactivity, no I don't want to re-eval my entire codebase on every keystroke, and no I don't want to recreate my vertex data every frame in the Draw method just so I can scrub a tree's bendiness.
2. The card wiki is too reliant on perfect structure. What if I need to change the structure at some point (refactor), then all my queries break. They'll break even worse too if my queries just says 'get the salaries per department', but then I modify the structure to have two sets of employees per dept (perhaps current and ex-employees), which changes the meaning of the query, yet the computer would plod along and now wrongly sum both groups I presume, if working in this automated way.
3. Performance. Sure it's easy to re-calculate an equation based on dependencies. Want to do 'a = b + c'? Then obviously re-calc 'b' and 'c' dependencies before performing the equation. But the hard part is when to do the re-calculation? Perhaps store an 'isDirty' bool? Or cache the value? Or just re-calc everytime it's needed? Human programmers make this decision based on how the result is used, how many times it is used, framerate, memory consumption and performance heuristics. There isn't a one size fits all, it's highly contextual.
4. You say 'we know Wikipedia works'. But have you tried scraping data from Wikipedia? Computers get stuck on all sorts of dumb stuff. Wikipedia is obviously meant for human consumption, where visual data and the English language rule, and the only structure we need is a 'top to bottom' layout. Programming is way more specific that this, so I can't see how combining the two ideas is any good.
5. Organisation. Perhaps you're still working on this, but you switched back and forth between a single card at a time, but given 20+ cards I'm not going to remember where stuff is. Code editors throw a bunch of stuff into one document, have tabs, and an explorer, and intellisense and search etc - and I still lose stuff all the time!
Hopefully when you do this release you'll include some complex samples, like you said you could build a compiler with these cards? So perhaps I'll be proved wrong.
[+] [-] chadcmulligan|10 years ago|reply
[+] [-] Detrus|10 years ago|reply
This is a similar idea and there is a long elaboration https://www.youtube.com/watch?v=voG5-15aDu4
[+] [-] stcredzero|10 years ago|reply
Use your awareness and ask yourself: Is this person primarily optimizing programming, or is she/he primarily optimizing their social status as a programmer? (Maybe doing the latter is more rational? Doing the latter likely results in higher pay and a more secure job.)
> The lesson from this was apparently, that just fixing the IDE wasn’t enough. Programming itself suffers from the problem that it is indirect and invisible, beleaguered with accidental complexity and unobservable.
These are the two deepest sentences about programming I've read in a while.
Here's the video in a nutshell:
Iterate that about a half dozen times.[+] [-] wfo|10 years ago|reply
[+] [-] ibdknox|10 years ago|reply
Btw, if you found those two lines interesting, I did an essay/talk about coming to that conclusion: http://www.chris-granger.com/2014/03/27/toward-a-better-prog...
[+] [-] kwhitefoot|10 years ago|reply
[+] [-] hencq|10 years ago|reply
1. Often presentations, reports, etc. rely on calculated data from e.g. an Excel spreadsheet. Whenever data gets updated it's really tricky to make sure everything that uses that data reflects the latest state. Too often have I heard the phrase in meetings "Oh that graph? Yeah, that's still based on last month's data."
2. I've had very smart colleagues who couldn't program, but could bend Excel to their will. Eventually they'd hit the limits of what's possible in Excel though. It always struck me that a) Excel is basically an FRP system and that therefore b) these people already have most of the skills to program if they had slightly different tools.
I always had an inkling that these two problems were somehow related, but I couldn't put my finger exactly on how they are related or what the solution would be. I'm really excited to see that EVE seems to go a long way to solving these things. I can't wait to see where they take it next. At the same time I also take some solace from the fact that, based on the number of iterations, people who are clearly much smarter than me also struggle with defining and solving this problem.
[+] [-] jononor|10 years ago|reply
And then ideally it would be possible to state an invariant 'this graph must include this months data' and have the system automatically verify it for you.
[+] [-] pavlov|10 years ago|reply
The author claims this is a compliment, but generally Notes has a terrible reputation as one of the most over-architected and misused software solutions of the '90s.
You can check it out (in excruciating detail) at this Interface Hall of Shame article from 1999:
http://hallofshame.gp.co.at/index.php?file=lotus.htm&mode=or...
It starts off with: "We wish we found IBM's Lotus Notes a long time ago. This single application could have formed the basis for the entire site."
Maybe there was an elegant core to Notes that was hidden under all the insane GUIs built using the tools? Would be interesting to hear more.
[+] [-] bsder|10 years ago|reply
It was the IBM buyout that started the big downfall.
> all the insane GUIs built using the tools?
Remember VB6 and all the shitty applications written in that? Uh, yeah. And don't get me started on the disasters that people perpetrated on us from the web. And how about the pile of dogshit that was Gtk v1? <shudder>
In addition, this was also still the time of "look and feel" lawsuits.
Everybody had insane GUI's in the 1990's, so singling out Lotus Notes is far from fair.
[+] [-] nradov|10 years ago|reply
The best ideas from that document database live on in Apache CouchDB. http://couchdb.apache.org/
[+] [-] daxelrod|10 years ago|reply
[+] [-] zubairq|10 years ago|reply
Yet a simpler model did prevail, and now we use so called toy languages like Javascript all the time. Eve's time will come, and in 10 years most of us who frequent hacker news today will be like the C++ developers of the 1990s in that we will be the minority. And languages like Eve and other similar projects will be considered normal programming languages. Java, Python and other languages will just be considered special purpose languages, much as C++ is considered "special purpose" today for high performance computing and operating systems
[+] [-] simonhughes22|10 years ago|reply
[+] [-] agentultra|10 years ago|reply
What will programming look like in 10 years? My guess is that it will look much the same as it does now. We'll have better languages for expressing temporal logic and consistency but it might not be radically far off from where we are now.
Text is still useful and certainly notations could improve but that's about it.
The idea of programming from tables using declarative or logic programming is certainly not new but very powerful. k comes to mind... which is probably at the extreme opposite end of usability. Never the less even COBOL had a sense of this.
Looking forward to where Eve goes next. My ideal environment is one where I can freely mix hand-drawn "symbols" to data and express relations using familiar mathematical notations in a single free-form canvas. I sort of do this on paper presently but I have to translate this artifact into a programming language to insert values and explore the various dimensions. It'd be nice to have a system that could recognize my notations and let me hook them up to data.
[0] https://www.wolfram.com/programming-lab/
update
Well... not quite like Wolfram Language; but the connection to knowledge, queries, and building new knowledge from queries. The interface is quite flexible too.
[+] [-] owyn|10 years ago|reply
https://github.com/witheve/Eve
And there's a blog post describing the features of version 0.
http://www.chris-granger.com/2015/08/17/version-0/
[+] [-] ibdknox|10 years ago|reply
[+] [-] frik|10 years ago|reply
TypeScript 69.2%, Rust 9.9%, C# 8.9%, CSS 5.9%, HTML 3.8%, JavaScript 1.4%, Shell 0.9%
[+] [-] EdSharkey|10 years ago|reply
I'm in the arts n' crafts camp. Craftily building up abstractions and playing them off each other -over time- seems to be what we're doing here.
I think any program representation should fit your use case. If Excel or SQL fits for data simulations, use that to program, if C++ and Assembler fits for your systems coding, use that, etc...
I'm not a fan of CASE tools, BPEL, instarepl, naked objects, or any other visual or visual/textual modes of coding for general programming work. I agree with the scalability and productivity issues others have mentioned with visual programming systems. Visual probably has a relevant place somewhere in effective software development, but they're just not general purpose enough because the visual bits and bobs tend to muddle the abstractions and are generally too fiddly.
I intuitively agree/sympathize with the myth that less lines of code == less bugs. I think we should seek for languages and libraries that require less lines of code to get stuff done.
Before we can bravely board our starships and chat with our sentient computers in order to program them, we'll need people to write less buggy code with existing systems. For me, that requires:
* TDD which allows everyone to verify their work
* Employing Agile teams to encourage robust communication and to reduce YAGNI, and
* Establishing software architectures where tools and libraries are chosen -primarily- for their ability to promote developer productivity
[+] [-] d08ble|10 years ago|reply
[+] [-] ChuckMcM|10 years ago|reply
[1] https://www.youtube.com/watch?v=GMDphyKrAE8
[+] [-] ibdknox|10 years ago|reply
[+] [-] po84|10 years ago|reply
[+] [-] j-pb|10 years ago|reply
However, since these systems have been shown to be somewhat limited by the boundaries of efficient computation or even computability in general I'm hard to convince on this.
I think the only way they can truly convince people that this is feasible is by implementing the system in itself.
[+] [-] WhatIsDukkha|10 years ago|reply
[+] [-] outworlder|10 years ago|reply
I don't think I have to summon Lisp to illustrate my point in a Hacker News Thread...
[+] [-] chubot|10 years ago|reply
Likewise, iOS is one biggest changes in the last 10 years, but based on old technology.
[+] [-] NotUsingLinux|10 years ago|reply
For that to come, a paradigm shift would need to happen. Now what could cause that shift? In my opinion its blockchain technology.
I think one of the platforms which allow to run Code on blockchain will reach critical mass, here is a nice intro talk to one of them: https://www.youtube.com/watch?v=U_LK0t_qaPo
You may ask but what about my beloved javascript, c++, python or java? Well there is plenty of that used in the implementation of ethereum. And they even try to make their language look like javascript a lot ( look for solidity) to attract developers. But those are just aesthetics which come due to bootstrapping.
And bootstrapping is THE key issue here which eve doesn't even begin to deal with, which would deal with interesting questions like:
How many programs/functions/snippets would a blockchain need to become "liveable" by itself? 10000? 100000? more?
People today think but I do this great "app" and people cando such cool things with it. But the point is, very much as Alan Kay also says, apps are just the wrong thought. Appstores are a JOKE for the end user, you can buy what you want , genius, but can you combine two programms to make it do soemthing interesting? No you can't, you would need files and formats , but ahh.. that war has been lost way long ago. We need maximal flexible programs, code, snippets. Write something on your own, include something here, send a message there and so on. Something like a giant gloabal object or actor space.
Digital Identity, no user EVER wants to log in, remember? So just get that working, it can be solved with the crypto infrastructure in place. Scaling to millions of users? Scaling to billion of users?
Most of the solutions, which try something today, including eve, try to do something which is based on a webbrowser. But the point of these "future" things should be how to bootstrap OFF the current browser (technical AND content wise) mess we have today.
So no I'dont see eve giving anything of interest, I don't see it capable to grow into a network. If eve tries to "solve" programming I can't see it, I made some notes about other interesting approaches here: https://gist.github.com/AndreasS2501/30ffda6d10b1c7ac53b1
[+] [-] dkroy|10 years ago|reply
[+] [-] unknown|10 years ago|reply
[deleted]