Beyond Light Table(chris-granger.com)
chris-granger.com
Beyond Light Table
http://www.chris-granger.com/2014/10/01/beyond-light-table/
251 comments
Seconded. I am slightly disappointed by this announcement. I backed LightTable because I really wanted to see an alternative to Emacs (for Clojure development). But I was hoping that by raising funding the team would be able to actually implement the tool. The hard parts. The parts that many projects never get around to implementing, because there is no funding.
I certainly didn't expect the team would be "revisiting some of the foundational ideas of computing" so soon.
LightTable right now is a proof of concept. A very good one, but still — it has a long way to go until it can become an everyday tool. Let's not leave it hanging there. If you continue on this path, you will leave behind a trail of half-baked tools, each one a great concept, but none of them actually useful.
I certainly didn't expect the team would be "revisiting some of the foundational ideas of computing" so soon.
LightTable right now is a proof of concept. A very good one, but still — it has a long way to go until it can become an everyday tool. Let's not leave it hanging there. If you continue on this path, you will leave behind a trail of half-baked tools, each one a great concept, but none of them actually useful.
> If you continue on this path, you will leave behind a trail of half-baked tools, each one a great concept, but none of them actually useful.
FWIW, I agree with you. This is our path, though, and the funding and the people we've brought on to work with us prove that. We're locked in to Eve and we think it will ultimately have far greater and for more lasting impact than LT ever could.
So the best I can say is that we're all in on Eve (both personally and now as a company) and I think that's very important for this to have a chance to succeed.
FWIW, I agree with you. This is our path, though, and the funding and the people we've brought on to work with us prove that. We're locked in to Eve and we think it will ultimately have far greater and for more lasting impact than LT ever could.
So the best I can say is that we're all in on Eve (both personally and now as a company) and I think that's very important for this to have a chance to succeed.
Given the funding you got for LT, and the fact that you didn't finish it, what most people are going to read is "we're all in on Eve (both personally and now as a company) until we decide something else is more interesting".
This sort of thing (a pivot) happens all of the time with services, so why is it not ok for pure software?
I backed Light Table and enjoy it (though it is nowhere near my daily editor) but I'm excited about the shift in focus. Sometimes great ideas do not pan out to great products for a variety of reasons, and it would be fiscal suicide for them to keep the focus on Light Table if the team truly does not believe they will be able to reach the product/market fit they were hoping for. This is business, not charity after all.
To put it another way, Eve sounds like a really interesting solution to a hard problem and I'm really excited that this team is trying to tackle it. Stoked to see what the future brings.
I backed Light Table and enjoy it (though it is nowhere near my daily editor) but I'm excited about the shift in focus. Sometimes great ideas do not pan out to great products for a variety of reasons, and it would be fiscal suicide for them to keep the focus on Light Table if the team truly does not believe they will be able to reach the product/market fit they were hoping for. This is business, not charity after all.
To put it another way, Eve sounds like a really interesting solution to a hard problem and I'm really excited that this team is trying to tackle it. Stoked to see what the future brings.
Afaik a pivot happens when there's a problem with the current product/strategy. If LT is truly used by "lots of other people" (I believe it is) it shouldn't be difficult to salvage it: just run another kickstarter.
I can understand having ran out of the original kickstarter money, but after enteing Ycombinator I'd expect them to still have resources to avoid being forced to pivot
(trivia/disclaimer: I'm a kickstarter backer and Light Table was my main editor for some months)
I can understand having ran out of the original kickstarter money, but after enteing Ycombinator I'd expect them to still have resources to avoid being forced to pivot
(trivia/disclaimer: I'm a kickstarter backer and Light Table was my main editor for some months)
I backed Light Table too based on the promising demo video and a fair amount of irrational exuberance. Eventually, my expectations did come down.
And, while Light Table is a polished little editor, it's hard to call Light Table an IDE without offering an apology. Light Table certainly is not what was promised.
In fact, Light Table was my first experience really being burned by a Kickstarter project. Nice that Chris Granger wants to reimagine computing, but he should finish what he starts.
Who would gift his crew with $2.3M given their track record? Atom, which did not promise an IDE has done more work on it's editor in a shorter time than Chris and crew. Buyer beware!
And, while Light Table is a polished little editor, it's hard to call Light Table an IDE without offering an apology. Light Table certainly is not what was promised.
In fact, Light Table was my first experience really being burned by a Kickstarter project. Nice that Chris Granger wants to reimagine computing, but he should finish what he starts.
Who would gift his crew with $2.3M given their track record? Atom, which did not promise an IDE has done more work on it's editor in a shorter time than Chris and crew. Buyer beware!
If they don't think that Light Table is going to be profitable for them as a company long term then yes, that's a problem with the current product/strategy. You're making a lot of assumptions about what the company can or can't do when the writing seems to be on the wall - They didn't feel comfortable moving forward with Light Table as a business so they are moving into a space with similar goals but (hopefully) a much larger opportunity.
It's a company full of smart people backed by smart investors, if there was a way to make LT work at scale I'm sure they would still be working on it.
It's a company full of smart people backed by smart investors, if there was a way to make LT work at scale I'm sure they would still be working on it.
They didn't "feel comfortable"? Is that all? Stated so dispassionately, it would be breathlessly easy to say. But I know the expectation and the agita that belie.
I was taught that when someone gives you even one dollar in consideration of something that you've promised, that taking the money is tantamount to an oath.
Light Table essentially proves the lie, since it is pretty far from the video. From where I sit, Chris and his team broke their oath and I won't be burned twice.
If Andreesen Horowitz believe that computing can be revolutionized for $2.3M, it's their cash to burn. Not surprised at all that they didn't turn to Kickstarter for funding.
The word is out.
I was taught that when someone gives you even one dollar in consideration of something that you've promised, that taking the money is tantamount to an oath.
Light Table essentially proves the lie, since it is pretty far from the video. From where I sit, Chris and his team broke their oath and I won't be burned twice.
If Andreesen Horowitz believe that computing can be revolutionized for $2.3M, it's their cash to burn. Not surprised at all that they didn't turn to Kickstarter for funding.
The word is out.
I say this out of concern and not as some kind of quip, but one of the first thoughts that came to my mind after reading this was, "Well, I now know not to give the Light Table guys any money until I see a finished product."
Yes, I agree.
I was very much interested in LightTable. If I had given money to the kickstarter fund I would be very ticked to find out that those funds were being redirected to a different project (and I would not give funds to those individuals again).
I am also trying to be helpful by pointing this out (not just taking a cheap shot).
Also, my gut reaction to this is "LightTable is effectively dead". Again, not trying to be mean -- just basing this on a long history of following the industry.
All that being said, it does seem that the LightTable folks are trying to be transparent about all of this, and that much is refreshing.
If they are successful in producing something very useful, my hat is off to them. But I have to admit that it sounds kind of "pie in the sky" to me in this announcement. Please feel free to prove me wrong :-D
I was very much interested in LightTable. If I had given money to the kickstarter fund I would be very ticked to find out that those funds were being redirected to a different project (and I would not give funds to those individuals again).
I am also trying to be helpful by pointing this out (not just taking a cheap shot).
Also, my gut reaction to this is "LightTable is effectively dead". Again, not trying to be mean -- just basing this on a long history of following the industry.
All that being said, it does seem that the LightTable folks are trying to be transparent about all of this, and that much is refreshing.
If they are successful in producing something very useful, my hat is off to them. But I have to admit that it sounds kind of "pie in the sky" to me in this announcement. Please feel free to prove me wrong :-D
Just to be clear: this is not Kickstarter funds being redirected. We worked on LT for 2.5 years, we were given 280K (after KS's cut), around 20k went to shirts/fullfillment. That's 260k for 3 guys in SF over 2.5 years... that money ran out long ago.
Thanks for clearing this up. It was not at all clear from the announcement. I would suggest that you update the original post so that others don't get the false impression that I did.
It would be a shame for that to be the case. The amount given was indeed much more than reasonably used up if it supported 3 people for 2.5 years (especially in SF).
It would be a shame for that to be the case. The amount given was indeed much more than reasonably used up if it supported 3 people for 2.5 years (especially in SF).
> Just to be clear: this is not Kickstarter funds being redirected.
While that's good to know, I think that the implicit upside gain hoped for from Kickstarter that underlies a lot of decisions to fund through it (especially for software) is that acheiving funding means not just that the thing gets delivered, but that an effort is made to build a sustainable business model is built around it and support the user community. The perception that, having delivered the kickstarted product and spent a couple years on it the team would abandon it and move on to a very different kind of focus (even if in the same broadly drawn domain) understandably reduces the perception that that kind of upside potential is around for a future effort.
Now, one can argue that that kind of upside expectation is somewhat irrational in the first place, of course.
While that's good to know, I think that the implicit upside gain hoped for from Kickstarter that underlies a lot of decisions to fund through it (especially for software) is that acheiving funding means not just that the thing gets delivered, but that an effort is made to build a sustainable business model is built around it and support the user community. The perception that, having delivered the kickstarted product and spent a couple years on it the team would abandon it and move on to a very different kind of focus (even if in the same broadly drawn domain) understandably reduces the perception that that kind of upside potential is around for a future effort.
Now, one can argue that that kind of upside expectation is somewhat irrational in the first place, of course.
This is very good to know, and something that I was not at all aware of -- I started using Clojure and thus Light Table after the Kickstarter had ended. For some reason I just assumed Light Table had raised a huge amount, and for that I apologize.
As far as an alternative to Emacs for Clojure goes, try Cursive if you haven't already. It didn't exist when Lighttable started out, but has grown to be a damn nice IDE.
It's open source under GPL. https://github.com/LightTable/LightTable
If it truly is "a great IDE" and "95% complete in every corner", yet it dies because the users (who all happen to be coders!) don't rally around it and contribute that last 5%, what does that mean?
If it truly is "a great IDE" and "95% complete in every corner", yet it dies because the users (who all happen to be coders!) don't rally around it and contribute that last 5%, what does that mean?
The problem is that the code is largely undocumented and not easy to follow. People have tried contributing and found that the ramp up was quite steep. You can read the experiences from the author of the Gorilla REPL here https://github.com/JonyEpsilon/gorilla-repl/issues/132 and here https://groups.google.com/forum/#!topic/light-table-discussi...
I have personally contributed to LightTable but you vastly overestimate the amount of people who can contribute back. This is not a Python/C++ project, it's in ClojureScript, a much less known language.
And just because all of the users are devs doesn't mean they're devs who have time to dedicate to building an IDE while they could use something else like KDevelop, PyCharm, Sublime, vim, or hell even VS.
And just because all of the users are devs doesn't mean they're devs who have time to dedicate to building an IDE while they could use something else like KDevelop, PyCharm, Sublime, vim, or hell even VS.
As just a plain editor, it's hard to compete with vim/emacs/sublime. The interesting things LT offered were around connecting to running pieces of software and the truth is that we just ran against a wall in what we can do with our current languages. That's why Apple's effort with Swift is so important: they're designing the language to be tooled. We didn't have that benefit and along the way we learned that it actually wouldn't help that much anyways.
Any single tool is going to be an incremental improvement (at best) on programming, because the source of the issues is really the model itself. My suspicion is that programming is going to change substantially over the next decade, because while we've been worried about machine learning, rails, and hadoop, the notion of the machine changed out from under us. We're already starting to hit a wall as a result of that - reasoning about highly concurrent systems with the programming models we have now is nearly impossible. If we continue pushing LT for that way of thinking, it's unlikely to make much of a difference. Instead, there's an opportunity to embrace that change and take the ideas of LT to their logical conclusion: what would a stack built for today's machine that is meant to be used by humans look like? We stumbled on a solution as we did more and more user testing of LT and in the interest of self preservation we ran with it.
More practically, though, incremental improvements are hard to sell - not just to VCistan, but to programmers as well. Hell, even orders of magnitude improvements are hard to sell to programmers. We'd have no way of sustaining ourselves if we couldn't find some avenue to eventually turn this into a business - we looked and couldn't really find a reasonably quick way to do that. Matching the millions of man hours that have been poured into vim/emacs and so on is just not in the cards for a couple of guys with not much funding. Plus it seems programmers are increasingly less interested in paying for anything in general, so that didn't make our prospects all that attractive. With Eve there's a much clearer path towards creating a sustainable business that is able to continue towards the ridiculous goal we set out with from the beginning: to empower the world's creators.
We use LT every day. Lots of other people do too. It fills an important part of the ecosystem and we hope it continues to infect other tools and organizations who have significantly greater resources than a couple of guys in SF. But either way we will do our best to make sure that it continues. Unfortunately, though, it just can't be our primary focus - both because I think that would be focusing on the wrong part of the problem and because at the end of the day we have to pay ourselves and there's just no way for us to do that.
Any single tool is going to be an incremental improvement (at best) on programming, because the source of the issues is really the model itself. My suspicion is that programming is going to change substantially over the next decade, because while we've been worried about machine learning, rails, and hadoop, the notion of the machine changed out from under us. We're already starting to hit a wall as a result of that - reasoning about highly concurrent systems with the programming models we have now is nearly impossible. If we continue pushing LT for that way of thinking, it's unlikely to make much of a difference. Instead, there's an opportunity to embrace that change and take the ideas of LT to their logical conclusion: what would a stack built for today's machine that is meant to be used by humans look like? We stumbled on a solution as we did more and more user testing of LT and in the interest of self preservation we ran with it.
More practically, though, incremental improvements are hard to sell - not just to VCistan, but to programmers as well. Hell, even orders of magnitude improvements are hard to sell to programmers. We'd have no way of sustaining ourselves if we couldn't find some avenue to eventually turn this into a business - we looked and couldn't really find a reasonably quick way to do that. Matching the millions of man hours that have been poured into vim/emacs and so on is just not in the cards for a couple of guys with not much funding. Plus it seems programmers are increasingly less interested in paying for anything in general, so that didn't make our prospects all that attractive. With Eve there's a much clearer path towards creating a sustainable business that is able to continue towards the ridiculous goal we set out with from the beginning: to empower the world's creators.
We use LT every day. Lots of other people do too. It fills an important part of the ecosystem and we hope it continues to infect other tools and organizations who have significantly greater resources than a couple of guys in SF. But either way we will do our best to make sure that it continues. Unfortunately, though, it just can't be our primary focus - both because I think that would be focusing on the wrong part of the problem and because at the end of the day we have to pay ourselves and there's just no way for us to do that.
I really appreciate this reply, I think most people would have ducked the question and moved on.
I still think that LT is going to slowly peter out, as there isn't enough momentum to dethrone existing IDEs / upcoming actively developed contenders.
That said, I think this level of transparency about where your collective heads are at is great. While some people may still be annoyed (particularly those who donated to the kickstarter) I applaud your willingness to change paths and do what you think needs to be done to succeed.
I'm excited to start playing with Eve.
I still think that LT is going to slowly peter out, as there isn't enough momentum to dethrone existing IDEs / upcoming actively developed contenders.
That said, I think this level of transparency about where your collective heads are at is great. While some people may still be annoyed (particularly those who donated to the kickstarter) I applaud your willingness to change paths and do what you think needs to be done to succeed.
I'm excited to start playing with Eve.
The fact that you're moving on from Light Table is perfectly fine. The problem is that you're not bothering to provide any sort of handover strategy.
A lot of people are interested in the project, would like to contribute to it, and would be happy to take over where you left off. However, this is difficult to do due to lack of documentation and any support from yourself.
You can read the experiences of one person trying to contribute here (https://groups.google.com/forum/#!topic/light-table-discussi...) and here (https://github.com/JonyEpsilon/gorilla-repl/issues/132).
Since you're not going to be actively working on the project, why not involve the community find individuals or an organization that would continue developing and maintaining it.
Surely, this is not too much to ask and it would be a responsible way to transition from the project.
A lot of people are interested in the project, would like to contribute to it, and would be happy to take over where you left off. However, this is difficult to do due to lack of documentation and any support from yourself.
You can read the experiences of one person trying to contribute here (https://groups.google.com/forum/#!topic/light-table-discussi...) and here (https://github.com/JonyEpsilon/gorilla-repl/issues/132).
Since you're not going to be actively working on the project, why not involve the community find individuals or an organization that would continue developing and maintaining it.
Surely, this is not too much to ask and it would be a responsible way to transition from the project.
I have stated from the beginning that I'm more than happy to get people more involved. When it has come up before I've said I'd gladly give people commit rights. There are only a couple of people who have contributed with any degree of frequency where that would make sense - Josh Cole and Mike Innes come to mind, for example.
I will certainly not stand in the way of the community and we're more than happy to help maintain.
I will certainly not stand in the way of the community and we're more than happy to help maintain.
My point was that the community needs more support from you in order to be able to contribute meaningfully. This involves actively finding people who would be willing to take over the project and working with them to help them get started.
Simply dropping the code on GitHub and saying that you're glad for people to get involved is not a sufficient level of support at this point. This might've worked when the project was younger and smaller, but it's just too big for people to be able to dive into now. The links I provided are a prime example of the problem.
Since you found the time to make a blog post about Eve, surely you could also make a post stating that you're looking to hand over Light Table and you'd like to help facilitate the transition.
Simply dropping the code on GitHub and saying that you're glad for people to get involved is not a sufficient level of support at this point. This might've worked when the project was younger and smaller, but it's just too big for people to be able to dive into now. The links I provided are a prime example of the problem.
Since you found the time to make a blog post about Eve, surely you could also make a post stating that you're looking to hand over Light Table and you'd like to help facilitate the transition.
That's fair. I'll get on it.
As someone who dug in far enough to write a simple plugin and then backed straight out again with no wish to go back I agree completely. If the plan is that LT should survive then I do not think simply open sourcing it is going to be enough; it needs the core team to do at least a final push on getting the fundamentals right, clarifying the internal api's, and documenting the way forward. Then maybe the community can take over. As it is, I'm not hopeful.
I'm really excited to see what comes out of this, because I have no doubt that it's possible to come up with both better programming models and better environments to support them. That said:
a) More "traditional" languages aren't going anywhere, at least for the next few decades, however successful Eve is.
b) The idea of really connecting to the running program has a huge amount of potential, even in these languages. Less potential than Eve? Perhaps, but I don't believe for a second that we've hit that wall yet (and I wholly intend on proving that with continued work on the Julia plugin).
Leaving Light Table unfinished would be a travesty, even if it is only an incremental improvement – but it sounds like you'll at least treat it as an important side project, which is something. Best of luck with Eve, anyway.
a) More "traditional" languages aren't going anywhere, at least for the next few decades, however successful Eve is.
b) The idea of really connecting to the running program has a huge amount of potential, even in these languages. Less potential than Eve? Perhaps, but I don't believe for a second that we've hit that wall yet (and I wholly intend on proving that with continued work on the Julia plugin).
Leaving Light Table unfinished would be a travesty, even if it is only an incremental improvement – but it sounds like you'll at least treat it as an important side project, which is something. Best of luck with Eve, anyway.
Thanks for coming forward.
I fully support your ideas with Eve.
Every time I dig into how Xerox PARC systems worked, my own experience with Smalltalk and Oberon, and then look for what we have, I always think we could have had so much better developer experiences if those technologies had succeeded in the market.
Good luck with your efforts.
I fully support your ideas with Eve.
Every time I dig into how Xerox PARC systems worked, my own experience with Smalltalk and Oberon, and then look for what we have, I always think we could have had so much better developer experiences if those technologies had succeeded in the market.
Good luck with your efforts.
How much math do you know? Specifically of the type theory/domain theory/category theory variety. How many process calculi are you familiar with? Just curious.
I personally don't have much of a math background, but Jamie does (he went to Cambridge for it). FWIW, Eve is actually very heavily based on mathematics and using first principles there to guide us to a solution that is backed by more than just intuition.
That is good to hear, for both personal validation and my hopes for your project. Thanks.
Do you think you'll have enough time to improve on the documentation and plugin APIs in LT?
Whenever I've used it I've felt like a small amount of effort in those aspects will allow it to continue to progress in the hands of the plugin community.
Whenever I've used it I've felt like a small amount of effort in those aspects will allow it to continue to progress in the hands of the plugin community.
Thank you for making light table. I use it every day, and it was immensely helpful for learning clojure script.
I'm also really disappointed with this announcement. I had been putting off learning Emacs because I told myself "don't bother, give ibdknox and friends some time to put some polish on LightTable, and you'll have a modern Emacs".
Looks like it's time to dive into Emacs...
Looks like it's time to dive into Emacs...
I just got back into using Clojure after a bit of a hiatus (and after having learned vim). I found a very comprehensive book online called "Clojure for the Brave and True," but then saw that chapters 2 and 3 are about using Emacs. I figured, "Don't worry about that, I'll just use Light Table." I installed it and noticed that not much had changed. Still, I maintained hope that LT would keep improving and be the awesome Clojure/Clojurescript editor I thought it would become. Needless to say, I'll be reading those Emacs chapters this weekend. :(
Come on guys, Emacs isn't that hard. You can be productive with it after have gone through the tutorial that comes with it.
Like Unix you can't grok all of it (ever), but you won't ever need all of it. Just learn more of it as you go along. See it as a trip :-)
And if you need your Emacs Clojure development environment right now, have someone make a VM for you.
Like Unix you can't grok all of it (ever), but you won't ever need all of it. Just learn more of it as you go along. See it as a trip :-)
And if you need your Emacs Clojure development environment right now, have someone make a VM for you.
I should have made note that the reason why I picked vim over emacs for general coding is that I found the various modifier key combinations required to seriously aggravate my RSI (I was unable to complete the tutorial); on the other hand, vim's modal editing has been a huge help. I'm aware of evil mode, so perhaps I'll have to go that route...
The ctrl+spacebar and search way that Light Table works, while not the fastest, was still preferable to holding down multiple modifier keys.
All that being said, the source of my hand pain might actually have to do with my neck and back, as working on those areas has substantially relieved my pain. So perhaps that will no longer be a barrier to emacs usage in a few months. :)
The ctrl+spacebar and search way that Light Table works, while not the fastest, was still preferable to holding down multiple modifier keys.
All that being said, the source of my hand pain might actually have to do with my neck and back, as working on those areas has substantially relieved my pain. So perhaps that will no longer be a barrier to emacs usage in a few months. :)
If you don't like to chord, you can always use M-x, the same way as invoking commands in light table and even better. See helm-M-x: http://tuhdo.github.io/helm-intro.html#sec-4
No, you're right. Emacs default keybindings and especially the longer 'chords' for frequently used commands are horrible.
I've never used the defaults[1] for long. First by making my own custom keybindings, then by making keybindings compatible to what most others applications use and a couple of years ago by switching to evil-mode. I already had vi/Vim experience so that was pretty optimal.
[1] Except some really basic ones that I also use in the shell: C-a, C-e, C-r, etc.
I've never used the defaults[1] for long. First by making my own custom keybindings, then by making keybindings compatible to what most others applications use and a couple of years ago by switching to evil-mode. I already had vi/Vim experience so that was pretty optimal.
[1] Except some really basic ones that I also use in the shell: C-a, C-e, C-r, etc.
> Come on guys, Emacs isn't that hard. You can be productive with it after have gone through the tutorial that comes with it.
...and customized it enough to have an environment comparable to what other editors ship out of the box
...and customized it enough to have an environment comparable to what other editors ship out of the box
wc -l ~/.emacs.d/init.el
241 /home/dario/.emacs.d/init.el
ls -l ~/.emacs.d/emacs.org
-rw-r--r-- 1 user user 67417 Oct 1 17:01 ~/.emacs.d/emacs.org
Please see my reply just above yours. You can use vim with clojure too!
Vim async infrastructure is 'less polished' then emacs. That is why even Vim fans (like me) consider learning emacs for Clojure development.
Hold on now, there are a lot of very stable options. Rich reportedly uses CursiveClojure:
https://cursiveclojure.com/
and there's also vim-fireplace:
https://github.com/tpope/vim-fireplace
By all means, if you don't want to use emacs then you don't have to!
https://cursiveclojure.com/
and there's also vim-fireplace:
https://github.com/tpope/vim-fireplace
By all means, if you don't want to use emacs then you don't have to!
I retract the statement that Rich uses Cursive. I misinterpreted a tweet a while ago, and hope that I didn't cause too much harm. Instead, I'd like to say that Cursive is extremely nice and that you shouldn't let Emacs scare you away from Clojure.
Why can't they say that Light Table is a dead end and they discovered something else in the process (Eve)?
Because people gave money via Kickstarter for LightTable. Abandoning it unfinished likely wouldn't go over well.
it's.... it's software. Complex software (like an editor) is never finished. At some point all software is eventually abandoned. Thus all complex software is abandoned in an unfinished state.
This is a simple truth.
For my part I think they've delivered on the spirit of their Kickstarter. They released a very usable editor that does some amazing shit. It doesn't have every feature in the Kickstarter video, but that's because reality kicked in and they had to prioritize, and found that some of the features didn't work out as well when put to other users.
This is a simple truth.
For my part I think they've delivered on the spirit of their Kickstarter. They released a very usable editor that does some amazing shit. It doesn't have every feature in the Kickstarter video, but that's because reality kicked in and they had to prioritize, and found that some of the features didn't work out as well when put to other users.
Not sure about that. They got 2.3M for eve.
While freehunter is right, I think it's more that LightTable is too unfinished to be considered dead.
LT fills multiple spaces in the area of IDEs:
- An extremely-programmable IDE (there's no other one like it)
- A lightweight generic IDE (there's REALLY no other one like it). I almost wouldn't call it an IDE but it's more than a text editor... it's right in the middle of the two and it's great to have something fill that gap, especially for languages that don't always need full-blown IDE support (like python and clojure)
LT fills multiple spaces in the area of IDEs:
- An extremely-programmable IDE (there's no other one like it)
- A lightweight generic IDE (there's REALLY no other one like it). I almost wouldn't call it an IDE but it's more than a text editor... it's right in the middle of the two and it's great to have something fill that gap, especially for languages that don't always need full-blown IDE support (like python and clojure)
I never used LT, but that description sounds like Emacs to me.
Heh okay, emacs is extremely programmable. I don't really consider it an IDE but that's fair.
It'd take a long time to explain the differences but emacs is far from lightweight, it's a beast. LT is very barebones. And LT is written in HTML/CSS/CLJS which makes it stylable and programmable as such, a real advantage over emacs.
It'd take a long time to explain the differences but emacs is far from lightweight, it's a beast. LT is very barebones. And LT is written in HTML/CSS/CLJS which makes it stylable and programmable as such, a real advantage over emacs.
You can customize style as much as you can. Take a look at Emacs theme gallery: http://pawelbx.github.io/emacs-theme-gallery/
Emacs is an IDE, first and foremost, to Emacs Lisp itself. Other Lisps are close. It's an excellent editors for other languages, and a good enough IDE for some languages. See my C/C++ guide in Emacs: http://tuhdo.github.io/c-ide.html.
Fyi, people wrote parsers, chat and email clients in Emacs that LT is still dreaming.
Emacs is an IDE, first and foremost, to Emacs Lisp itself. Other Lisps are close. It's an excellent editors for other languages, and a good enough IDE for some languages. See my C/C++ guide in Emacs: http://tuhdo.github.io/c-ide.html.
Fyi, people wrote parsers, chat and email clients in Emacs that LT is still dreaming.
I don't even use Emacs, and what you just described sounds like Emacs. That said, LightTable is a lot more noob friendly than Emacs.
I use Emacs every day, and I think Emacs makes a terrible IDE or anything resembling an IDE. It's too slow, the GUI is too primitive, there's a whole host of other problems. I'll dump Emacs the instant something that fixes those issues comes around.
Am curious what exactly is too slow about Emacs. What operations, I mean.
A few things are either slow, highly annoying, broken, or all three:
etags -- it's just an nightmare, full stop. It only gets you where you want to go half the time at most. And then because the GUI is so primitive you can't do basic things like click on a symbol and have it jump you to the definition, you're stuck using the keyboard interface designed for work in a terminal.
An etags that actually worked properly is one of the most basic things that could improve my productivity monumentally.
CEDET -- last used about 5 years ago, gave up because on larger files/projects it would just hang my editor for a few seconds as it processed.
Variable/symbol completion -- see etags.
I'm not doing a very good job communicating my dislikes / pain points because I'm not very good at communicating. Please do not respond with a "but these aren't problems because..." because they are problems for me, I just do a poor job of communicating.
etags -- it's just an nightmare, full stop. It only gets you where you want to go half the time at most. And then because the GUI is so primitive you can't do basic things like click on a symbol and have it jump you to the definition, you're stuck using the keyboard interface designed for work in a terminal.
An etags that actually worked properly is one of the most basic things that could improve my productivity monumentally.
CEDET -- last used about 5 years ago, gave up because on larger files/projects it would just hang my editor for a few seconds as it processed.
Variable/symbol completion -- see etags.
I'm not doing a very good job communicating my dislikes / pain points because I'm not very good at communicating. Please do not respond with a "but these aren't problems because..." because they are problems for me, I just do a poor job of communicating.
Which programming languages in particular do you wish etags worked properly with?
I think you communicated your pain points well, because they are my pain points as well.
I gave up on emacs for Java development for the reasons you cited, but I still use it for REPL style development (Jython, Ruby Motion, XQuery, as a few current examples).
I gave up on emacs for Java development for the reasons you cited, but I still use it for REPL style development (Jython, Ruby Motion, XQuery, as a few current examples).
You are pretty out of date then. See my C/C++ guide (with demos): http://tuhdo.github.io/c-ide.html. It works fine on navigation projects like Linux kernel, it should work for you likely. With Projectile, I can jump any file instantly, even in Linux kernel with more than 46k files, and I've never seen this in an IDE.
And use GNU Global instead of etags. Finally, keyboard boost productivity many times over the mouse.
And use GNU Global instead of etags. Finally, keyboard boost productivity many times over the mouse.
Ah yes, the good old "mouse? you're doing it wrong!" bit of elitism. Some people find keyboard navigation through a second buffer that pops up on the bottom to be not-good. I'm one of those people. I hate it when completion buffers, or anything related to a second buffer, pops up in my frame.
Google Chrome, or any modern browser for that matter, has a much better way of doing things. Imagine for a moment that I was browsing and editing code in Google Chrome instead. A symbol would be a link, and when I ctrl+clicked on it, it would open in a new frame. That would be an interface I could get behind.
For completion, it ought to work like the IDE I used back when I was writing Scala. A little tooltip would pop up with completions. You could scroll through them with the mouse or keyboard, and click or ENTER the one you want and it would paste in. Or you could ignore it completely and continue typing. This sort of UI is so much better than popping up a new buffer in the frame. But in Emacs UI, everything is a buffer and there are only three places they can (or usually do) go: in a new frame, in a new window, or in the minibuffer. Only that last one is usable.
GNU global is not a solution. It produces marginally better output than etags, but still requires you to actually run it whenever you make changes to the codebase. Or at least it did back when I tried it as an etags replacement.
Google Chrome, or any modern browser for that matter, has a much better way of doing things. Imagine for a moment that I was browsing and editing code in Google Chrome instead. A symbol would be a link, and when I ctrl+clicked on it, it would open in a new frame. That would be an interface I could get behind.
For completion, it ought to work like the IDE I used back when I was writing Scala. A little tooltip would pop up with completions. You could scroll through them with the mouse or keyboard, and click or ENTER the one you want and it would paste in. Or you could ignore it completely and continue typing. This sort of UI is so much better than popping up a new buffer in the frame. But in Emacs UI, everything is a buffer and there are only three places they can (or usually do) go: in a new frame, in a new window, or in the minibuffer. Only that last one is usable.
GNU global is not a solution. It produces marginally better output than etags, but still requires you to actually run it whenever you make changes to the codebase. Or at least it did back when I tried it as an etags replacement.
Ah yes, the good old "mouse? you're doing it wrong!" bit of elitism. Some people find keyboard navigation through a second buffer that pops up on the bottom to be not-good. I'm one of those people. I hate it when completion buffers, or anything related to a second buffer, pops up in my frame.
There's nothing elite about the keyboard. It's just the keyboard enable higher productivity when it comes to write code.
For completion, it ought to work like the IDE I used back when I was writing Scala. A little tooltip would pop up with completions. You could scroll through them with the mouse or keyboard, and click or ENTER the one you want and it would paste in. Or you could ignore it completely and continue typing. This sort of UI is so much better than popping up a new buffer in the frame. But in Emacs UI, everything is a buffer and there are only three places they can (or usually do) go: in a new frame, in a new window, or in the minibuffer. Only that last one is usable.
In Emacs you have tooltip as well. For example, company-mode shows a completion popup like this: http://tuhdo.github.io/static/c-ide/company-clang-company-gt...
Completion using a window buffer is still vastly superior because it can handle large collections. For example, here is how I filter completion candidates with Helm: http://tuhdo.github.io/static/c-ide/semantic-boost-demo.gif. Helm works even if you have 99999 candidates (not joking) to filter out. Here is how I quickly filter to a file and enter the file in Linux kernel source tree: http://tuhdo.github.io/static/helm_projectile.gif , very quick and simple; in contrast, the file search dialog box in typical IDEs is very complex with many checkboxes and text fields. How do you cope with completion popup with contains thousands of candidates in it?
GNU global is not a solution. It produces marginally better output than etags, but still requires you to actually run it whenever you make changes to the codebase. Or at least it did back when I tried it as an etags replacement.
No, ggtags: https://github.com/leoliu/ggtags or helm-gtags: https://github.com/syohex/emacs-helm-gtags automatically updates your tag database when you save your file. The tags produced by GNU Global is A LOT better than ctags for C/C++.
Maybe you can look at a few demo screenshots in my C/C++ guide: http://tuhdo.github.io/c-ide.html
There's nothing elite about the keyboard. It's just the keyboard enable higher productivity when it comes to write code.
For completion, it ought to work like the IDE I used back when I was writing Scala. A little tooltip would pop up with completions. You could scroll through them with the mouse or keyboard, and click or ENTER the one you want and it would paste in. Or you could ignore it completely and continue typing. This sort of UI is so much better than popping up a new buffer in the frame. But in Emacs UI, everything is a buffer and there are only three places they can (or usually do) go: in a new frame, in a new window, or in the minibuffer. Only that last one is usable.
In Emacs you have tooltip as well. For example, company-mode shows a completion popup like this: http://tuhdo.github.io/static/c-ide/company-clang-company-gt...
Completion using a window buffer is still vastly superior because it can handle large collections. For example, here is how I filter completion candidates with Helm: http://tuhdo.github.io/static/c-ide/semantic-boost-demo.gif. Helm works even if you have 99999 candidates (not joking) to filter out. Here is how I quickly filter to a file and enter the file in Linux kernel source tree: http://tuhdo.github.io/static/helm_projectile.gif , very quick and simple; in contrast, the file search dialog box in typical IDEs is very complex with many checkboxes and text fields. How do you cope with completion popup with contains thousands of candidates in it?
GNU global is not a solution. It produces marginally better output than etags, but still requires you to actually run it whenever you make changes to the codebase. Or at least it did back when I tried it as an etags replacement.
No, ggtags: https://github.com/leoliu/ggtags or helm-gtags: https://github.com/syohex/emacs-helm-gtags automatically updates your tag database when you save your file. The tags produced by GNU Global is A LOT better than ctags for C/C++.
Maybe you can look at a few demo screenshots in my C/C++ guide: http://tuhdo.github.io/c-ide.html
i've not used lighttable, but as far as filling in the space between editor and ide goes, geany does a decent job. it doesn't have a ton of features, and the plugin mechanism is some combination of C and lua (which raises the entry barrier a bit), but it's definitely targeting that exact space.
Xerox PARC OSes?
That is precisely what this comment says:
https://news.ycombinator.com/item?id=8395319
https://news.ycombinator.com/item?id=8395319
It's open source. On GitHub. It's only dead if no one cares enough.
It's a big and complex project. Not that easy to just jump in and finish IDE.
> Imagine a world where everyone has access to computation without having to become a professional programmer - where a scientist doesn’t have to rely on the one person in the lab who knows python, where a child could come up with an idea for a game and build it in a couple of weekends, where your computer can help you organize and plan your wedding/vacation/business.
This seems to misunderstand fundamentally what it means to be a professional programmer. Knowing some programming language isn't it, its a mode of thinking and analysis. I think that with programming things get confused in people's minds because there is less of a clear professional distinction between construction and design than in physical engineering, but learning languages and syntax is the trivial part of programming already. Eliminating the hard part of the requirement to become a professional programmer is an AI complete problem, because it means you are getting the computer to do your thinking for you.
Many people who try to make programming better starts out with tools like IDEs or analysis tools, maybe proceeds to actual new languages, and ends up tilting at the windmill of transforming programming by replacing it with something that eliminates the need for professional programmers entirely -- and while we tend to get useful tools out of the other step, that last one is pretty consistently a place where we get vague hopes and pretty demos and, if anything of lasting use, salvaged pieces that end up as analysis, etc., tools for professional programmers.
I'm not saying this isn't interesting or that I don't want to see where it goes, but the description provided of both the goal and how the people promising they can deliver it have "found the way" by "studying the past and revisiting some of the foundational ideas in computing" is something I've heard from some group or another every few years for the last several decades. What I don't see is why this time is different.
This seems to misunderstand fundamentally what it means to be a professional programmer. Knowing some programming language isn't it, its a mode of thinking and analysis. I think that with programming things get confused in people's minds because there is less of a clear professional distinction between construction and design than in physical engineering, but learning languages and syntax is the trivial part of programming already. Eliminating the hard part of the requirement to become a professional programmer is an AI complete problem, because it means you are getting the computer to do your thinking for you.
Many people who try to make programming better starts out with tools like IDEs or analysis tools, maybe proceeds to actual new languages, and ends up tilting at the windmill of transforming programming by replacing it with something that eliminates the need for professional programmers entirely -- and while we tend to get useful tools out of the other step, that last one is pretty consistently a place where we get vague hopes and pretty demos and, if anything of lasting use, salvaged pieces that end up as analysis, etc., tools for professional programmers.
I'm not saying this isn't interesting or that I don't want to see where it goes, but the description provided of both the goal and how the people promising they can deliver it have "found the way" by "studying the past and revisiting some of the foundational ideas in computing" is something I've heard from some group or another every few years for the last several decades. What I don't see is why this time is different.
And yet, people do get useful work done with spreadsheets. They build computer programs that solve problems for them. There are many programs that aren't feasible to write in a spreadsheet, but there are many useful ones that are.
I think success for this project looks more like a supercharged spreadsheet than a simplified programming language. There will be many programs that won't be feasible to write in it, but I think they could carve out an area wherein there are many useful programs that can be. If that area is large enough, that would be a big deal.
I think success for this project looks more like a supercharged spreadsheet than a simplified programming language. There will be many programs that won't be feasible to write in it, but I think they could carve out an area wherein there are many useful programs that can be. If that area is large enough, that would be a big deal.
Doing powerful things with spreadsheets involves a similar amount of difficulty/learning as hacking some Python.
But doing simple things with spreadsheets is a hell of a lot easier than doing simple things with python. Learning curves are important because most people will never get to the powerful things if they get frustrated and give up on the simple things.
Actually, for me, doing simple things with Python is more intuitive than doing simple things with Excel.
Programming languages tend to be geared toward coercing the user to abstract data into symbols. Spreadsheets are the other way around being more focused on keeping the data in front of your face as a table.
Data can be a complex thing to understand. By forcing data to be explicitly displayed in tables, users no longer need to "read source code" as just a casual glance at a chart or a table leads to significant comprehension about what's going on.
Data can be a complex thing to understand. By forcing data to be explicitly displayed in tables, users no longer need to "read source code" as just a casual glance at a chart or a table leads to significant comprehension about what's going on.
Maybe. But the key difference is that those who "program" spreadsheets can see all of the steps involved. The hardest part about programming is constructing and executing a model of the computation in your head. Spreadsheets help with exactly that, by making a 1-to-1 association between steps of the computation, and things in front of you.
> But the key difference is that those who "program" spreadsheets can see all of the steps involved.
I would say that that's almost precisely backwards: compared to typical plain-text code, spreadsheets make intermediate results more obvious, while obscuring the steps. (Things like, e.g., scala worksheets or ipython notebooks bridge this gap in a way which makes both the steps and the results clear.)
I would say that that's almost precisely backwards: compared to typical plain-text code, spreadsheets make intermediate results more obvious, while obscuring the steps. (Things like, e.g., scala worksheets or ipython notebooks bridge this gap in a way which makes both the steps and the results clear.)
Yes, I'll agree with that. Users have to poke at the data cell to see what the formula is there - and it's easy to not do this, and be confused why the results are coming out wrong.
> There are many programs that aren't feasible to write in a spreadsheet
There are many programs that aren't feasible to write in a spreadsheet, and yet people have written them regardless.
In college, one course I took got groups of students to participate in a networked, multi-user business simulation that was written in Excel.
It was slow as hell, and Excel probably wasn't the best tool for the job, but it was probably just what the domain experts who created it were familiar with. Despite its lack of performance, it did its job admirably.
I think many people would be absolutely shocked at the size and scope of applications written in Excel using VBA. So in that respect, perhaps a supercharged spreadsheet would result in many more feasible applications than most of us, as developers, would first imagine.
There are many programs that aren't feasible to write in a spreadsheet, and yet people have written them regardless.
In college, one course I took got groups of students to participate in a networked, multi-user business simulation that was written in Excel.
It was slow as hell, and Excel probably wasn't the best tool for the job, but it was probably just what the domain experts who created it were familiar with. Despite its lack of performance, it did its job admirably.
I think many people would be absolutely shocked at the size and scope of applications written in Excel using VBA. So in that respect, perhaps a supercharged spreadsheet would result in many more feasible applications than most of us, as developers, would first imagine.
To me it sounds actually they perfectly understand what it means to be professional programmer and, most significantly, not everyone needs to be a professional programmer to provide added value through simple programs. A better Excel sounds just about right for a metric ton of practical applications for automating the work loads of professionals everywhere.
Working on Eve so far has been an incredible challenge that has taken us through everything from language design and query optimisation to high-dimensional geometry and cognitive science...how do you invite a billion people to program without them ever knowing about it? We're not sure yet, but we know finding out will certainly be fun.
I think what worries me about the hyperbole on this linked page is that it implies all problems software solves are fundamentally similar (they're not), or that all software shares certain fundamentals (it does of course, but at such a low level they are hard to abstract). The range of problems it says they want to tackle is huge:
They want to make a better excel
They want to make a powerful, intuitive, database UI
They want to make a tool scientists can use to crunch and visualise data
They want to make a game programming language for kids
They want to make hypercard with modern programming languages backing it
They want to make a tool for professional programmers to focus on the hard problems
Any one of those is an admirable and difficult goal - trying to make all of those things at once is a good recipe for starting something and never finishing it.
That's not a reason not to try to improve programming practice with something radically better, but I think they'd be far better to pull a Buchheit here and focus on one small set of customers and make them very happy, instead of over-promising and under-delivering.
I think what worries me about the hyperbole on this linked page is that it implies all problems software solves are fundamentally similar (they're not), or that all software shares certain fundamentals (it does of course, but at such a low level they are hard to abstract). The range of problems it says they want to tackle is huge:
They want to make a better excel
They want to make a powerful, intuitive, database UI
They want to make a tool scientists can use to crunch and visualise data
They want to make a game programming language for kids
They want to make hypercard with modern programming languages backing it
They want to make a tool for professional programmers to focus on the hard problems
Any one of those is an admirable and difficult goal - trying to make all of those things at once is a good recipe for starting something and never finishing it.
That's not a reason not to try to improve programming practice with something radically better, but I think they'd be far better to pull a Buchheit here and focus on one small set of customers and make them very happy, instead of over-promising and under-delivering.
> They want to make a better excel
> They want to make a powerful, intuitive, database UI
> They want to make a tool scientists can use to crunch and visualise data
These are basically all the same thing. Excel is generally used as a database / data cruncher. A relational DB with a similarly accessible learning curve could prevent many of the errors that riddle most spreadsheets. We add incrementally updated views to handle the data manipulation / crunching side (relatational aggregates are sufficiently expressive to handle most statistics / ML problems - http://db.cs.berkeley.edu/cs286/papers/bismarck-sigmod2012.p...).
> They want to make hypercard with modern programming languages backing it
Papers like https://github.com/papers-we-love/papers-we-love/blob/master... and http://db.cs.berkeley.edu/papers/eurosys10-boom.pdf show how you can handle interactivity in a relational model. We have enough of this working that we bootstrapped the IDE.
> They want to make a tool for professional programmers to focus on the hard problems
Most of what I do as a professional programmer is not building abstractions or designing systems, but wrestling with incidental low-level detail, lack of visibility and tools that don't talk to each other. I've had enough experience with Eve to be convinced that I would be more productive.
> ... over-promising and under-delivering.
Obviously we are suffering from http://lesswrong.com/lw/kg/expecting_short_inferential_dista... since we have been thinking about this and working with it for months and all you have to go on is a few blog posts. I don't expect to convince you that we are right, but hopefully I can convince you that we have at least thought it through. We aren't trying to boil the ocean here - we are building a small set of tools that are applicable to lots of different problems. We've picked one problem to focus on for the first assault
These are basically all the same thing. Excel is generally used as a database / data cruncher. A relational DB with a similarly accessible learning curve could prevent many of the errors that riddle most spreadsheets. We add incrementally updated views to handle the data manipulation / crunching side (relatational aggregates are sufficiently expressive to handle most statistics / ML problems - http://db.cs.berkeley.edu/cs286/papers/bismarck-sigmod2012.p...).
> They want to make hypercard with modern programming languages backing it
Papers like https://github.com/papers-we-love/papers-we-love/blob/master... and http://db.cs.berkeley.edu/papers/eurosys10-boom.pdf show how you can handle interactivity in a relational model. We have enough of this working that we bootstrapped the IDE.
> They want to make a tool for professional programmers to focus on the hard problems
Most of what I do as a professional programmer is not building abstractions or designing systems, but wrestling with incidental low-level detail, lack of visibility and tools that don't talk to each other. I've had enough experience with Eve to be convinced that I would be more productive.
> ... over-promising and under-delivering.
Obviously we are suffering from http://lesswrong.com/lw/kg/expecting_short_inferential_dista... since we have been thinking about this and working with it for months and all you have to go on is a few blog posts. I don't expect to convince you that we are right, but hopefully I can convince you that we have at least thought it through. We aren't trying to boil the ocean here - we are building a small set of tools that are applicable to lots of different problems. We've picked one problem to focus on for the first assault
Concerning the inferential distance... Wouldn't describing Eve as Smalltalk but based on immutable data structures with built in derivation (so that intermediate results don't consume space) get you much closer (for the programming crowd) than building on the spreadsheet analogy?
Eve has changed a great deal since Chris' original demo. It's much closer now to a spreadsheet or a relational database than to Smalltalk. All data lives in tables. Views are built using relational queries and update incrementally when data changes. IO is done by watchers that react to data arriving in certain tables. The only link to Smalltalk is the idea of running the program inside the development environment so the tools can all access live data.
OK. Good to know. But is the database itself still immutable then?
FWIW, I've mentioned in a few comments below that our first in-road here is just building websites. You can think of it as a replacement for VB6: something a normal person could use to draw out your application and then describe what happens when you interact with it.
The rest comes later, though we do believe it all flows out of a common model for programming in the same way that all of those things could come from any general purpose language.
The rest comes later, though we do believe it all flows out of a common model for programming in the same way that all of those things could come from any general purpose language.
So more like a better web-based hypercard then?
Will be great to see what you come up with, but I think the sales pitch here is overstating what you can reasonably achieve. Everyone has had dreams of revolutionising their discipline by inventing new tools, but it's very rare for tools alone to lead to a new paradigm.
Will be great to see what you come up with, but I think the sales pitch here is overstating what you can reasonably achieve. Everyone has had dreams of revolutionising their discipline by inventing new tools, but it's very rare for tools alone to lead to a new paradigm.
Yeah, I think that's a fair way of thinking about it, especially since we drew a lot of inspiration from Hypercard itself.
> but it's very rare for tools alone to lead to a new paradigm
I think the distinction is that a tool helps you do something more efficiently while still generally thinking about the problem in the same way. What we're proposing is a very different way of thinking about the problem, which is what I think starts to define a paradigm. That being said, this is largely semantics and not a very valuable thing to argue about: paradigms come to be by the accident of use, so we'll find out when we launch and build a community around Eve.
> but it's very rare for tools alone to lead to a new paradigm
I think the distinction is that a tool helps you do something more efficiently while still generally thinking about the problem in the same way. What we're proposing is a very different way of thinking about the problem, which is what I think starts to define a paradigm. That being said, this is largely semantics and not a very valuable thing to argue about: paradigms come to be by the accident of use, so we'll find out when we launch and build a community around Eve.
> The range of problems it says they want to tackle is huge:
If they incorporate all that into one program, it will be (an unusable mess OR so damn complex that a small percentage of users will ever tackle it) AND it will quickly fall behind whatever bleeding edge they're wanting to stick to.
For evidence, I give you: Eclipse, the ultimate do-everything IDE. It's awesome until you realize how much unmaintained cruft there is in there. Which doesn't mean you can't get things done with it, but don't expect bleeding edge on a lot of things that started out that way.
If they incorporate all that into one program, it will be (an unusable mess OR so damn complex that a small percentage of users will ever tackle it) AND it will quickly fall behind whatever bleeding edge they're wanting to stick to.
For evidence, I give you: Eclipse, the ultimate do-everything IDE. It's awesome until you realize how much unmaintained cruft there is in there. Which doesn't mean you can't get things done with it, but don't expect bleeding edge on a lot of things that started out that way.
That seems likely to be true if the approach is to build separate features to achieve all of those goals. Looking at the research papers they've cited in this thread, however, I don't think that's where this is heading -- I'd say it looks more like Excel (which is already the current [figuratively, not specifically quantitatively] 80% solution for the first second and third items, and explicitly the thing addressed by the first) built on a better foundation that unites the existing strengths of the dataflow paradigm implicit in spreadsheets with a strong theoretical basis that unites it with relational + temporal data in a way which also greatly reduces the need to escape out to alternative programming models (e.g., in existing Excel, VBA etc.)
Its still a challenge -- getting the UI right especially -- but its not particularly hard to see from the cited research how a tool built on that foundation that could do what they are saying, with the only specialization to the separate goals being UI affordances rather than separate basic functionality.
Its still a challenge -- getting the UI right especially -- but its not particularly hard to see from the cited research how a tool built on that foundation that could do what they are saying, with the only specialization to the separate goals being UI affordances rather than separate basic functionality.
What they're building is much closer to Smalltalk than to Eclipse though....
> This seems to misunderstand fundamentally what it means to be a professional programmer. Knowing some programming language isn't it [...] learning languages and syntax is the trivial part of programming already
In order to get a job as a junior full stack web developer, you're going to need to know the following:
- HTML, CSS, Python/Ruby, Django/Rails, javascript, jQuery, SQL, Git, basic unix/linux
- Possibly Angular, design patterns, testing
Whereas in terms of CS questions you're likely to be asked, you're going to need to know:
- Basic data structures, algorithmic complexity, basic concurrency patterns
- Possibly some knowledge of common algorithms
Whereas all the programming stuff can easily take a year or more to learn, all the CS stuff you need to know to get a job as a professional developer is maybe a couple weekends worth of watching YouTube videos. I realize that CS knowledge sometimes becomes more important at higher levels depending on your career track, but I think you're underestimating the difficulty of learning the APIs versus learning the CS stuff as far as becoming a professional developer goes.
In order to get a job as a junior full stack web developer, you're going to need to know the following:
- HTML, CSS, Python/Ruby, Django/Rails, javascript, jQuery, SQL, Git, basic unix/linux
- Possibly Angular, design patterns, testing
Whereas in terms of CS questions you're likely to be asked, you're going to need to know:
- Basic data structures, algorithmic complexity, basic concurrency patterns
- Possibly some knowledge of common algorithms
Whereas all the programming stuff can easily take a year or more to learn, all the CS stuff you need to know to get a job as a professional developer is maybe a couple weekends worth of watching YouTube videos. I realize that CS knowledge sometimes becomes more important at higher levels depending on your career track, but I think you're underestimating the difficulty of learning the APIs versus learning the CS stuff as far as becoming a professional developer goes.
> its a mode of thinking and analysis
Right now, though, that thinking and analysis mostly comes with very little assistance from the computer. We are pleasantly surprised when a compiler manages to guess what we meant when we made a mistake.
I think there's a lot of room to help with the process of thinking rigorously. New models of programming could conceivably allow someone to start down the path of building, and then have an interaction with the programming environment in which it helps to find ambiguities or special cases.
I'm a terrible artist; I wouldn't try to make mockups if there weren't sites like Balsamiq. Even if I tried, they would be too rough to serve as any kind of spec. The right tools allow more (not all) people to succeed in trying their hand at design. Of course they will never be a "real designer", but hopefully they can accomplish more of their goals without help.
I think better programming tools and paradigms can have the same effect.
Right now, though, that thinking and analysis mostly comes with very little assistance from the computer. We are pleasantly surprised when a compiler manages to guess what we meant when we made a mistake.
I think there's a lot of room to help with the process of thinking rigorously. New models of programming could conceivably allow someone to start down the path of building, and then have an interaction with the programming environment in which it helps to find ambiguities or special cases.
I'm a terrible artist; I wouldn't try to make mockups if there weren't sites like Balsamiq. Even if I tried, they would be too rough to serve as any kind of spec. The right tools allow more (not all) people to succeed in trying their hand at design. Of course they will never be a "real designer", but hopefully they can accomplish more of their goals without help.
I think better programming tools and paradigms can have the same effect.
I'm a terrible artist; I wouldn't try to make mockups if there weren't sites like Balsamiq. Even if I tried, they would be too rough to serve as any kind of spec. The right tools allow more (not all) people to succeed in trying their hand at design. Of course they will never be a "real designer", but hopefully they can accomplish more of their goals without help.
This is a great analogy, but unfortunately I think it undermines your point somewhat.
Almost anyone can become a great artist or designer, but what it takes is practice, years of practice, and learning from others who have gone before and are working now. There are no short cuts and tools are really the least important element in any discipline, be that design or programming.
This is a great analogy, but unfortunately I think it undermines your point somewhat.
Almost anyone can become a great artist or designer, but what it takes is practice, years of practice, and learning from others who have gone before and are working now. There are no short cuts and tools are really the least important element in any discipline, be that design or programming.
> Almost anyone can become a great artist or designer
I challenge this claim. I don't think just anyone can become a great artist or designer and if you think this I think you miss a great deal when it comes to evaluating these skills. Maybe anyone can become great at Photoshop and the other various tools, but if you don't find yourself enjoying designing, and you haven't had an artistic trait that others have recognized in you early on and you're not making much headway now, you probably want to find out what other talents you might have.
I think that if you enjoy designing you should pursue it. I think wanting to be good at something can lead to a high degree of skill because the motivation will drive you there. Not everyone has that motivation and so not everyone can be a great artist or designer. I think the same thing can be said of engineering. People who go into this field to get a 9-5 job and hate the work will struggle competing against people who love what they do and would do it even if they weren't paid for it.
I challenge this claim. I don't think just anyone can become a great artist or designer and if you think this I think you miss a great deal when it comes to evaluating these skills. Maybe anyone can become great at Photoshop and the other various tools, but if you don't find yourself enjoying designing, and you haven't had an artistic trait that others have recognized in you early on and you're not making much headway now, you probably want to find out what other talents you might have.
I think that if you enjoy designing you should pursue it. I think wanting to be good at something can lead to a high degree of skill because the motivation will drive you there. Not everyone has that motivation and so not everyone can be a great artist or designer. I think the same thing can be said of engineering. People who go into this field to get a 9-5 job and hate the work will struggle competing against people who love what they do and would do it even if they weren't paid for it.
I don't think just anyone can become a great artist or designer and if you think this I think you miss a great deal when it comes to evaluating these skills.
I'm a designer, trained as an artist ;) I do agree motivation is key though.
I'm a designer, trained as an artist ;) I do agree motivation is key though.
He is talking about "access to computation". No one is talking about making normal people into professional programmers.
Right, but I think he also has building websites in mind. So, both, I guess.
I'm fairly certainly that he has in mind the vision put forward in Prof. David Harel's late-career manifesto Can Programming be Liberated, Period? (2008)[1]
Five years earlier, Prof. Harel wrote a book, Come, Let's Play[2], in which he explored the role that temporal logic[3] could have in the building of reactive software systems (e.g. desktop GUI applications, among many others). If you visit Harel's full list of publications[4] and do an in-page search for the terms "LSC", "behavioral" and "scenario", you can follow the links to a number of papers published since the early 2000s, related to the application of temporal logic in the process of software design.
It's possible that my connection of Granger's "eve" to Harel's work is completely mistaken; and if so, I apologize for jumping the gun.
[1] http://www.wisdom.weizmann.ac.il/~harel/papers/LiberatingPro...
[2] http://www.wisdom.weizmann.ac.il/~playbook/
[3] http://en.wikipedia.org/wiki/Temporal_logic
[4] http://www.wisdom.weizmann.ac.il/~harel/papers.html
Five years earlier, Prof. Harel wrote a book, Come, Let's Play[2], in which he explored the role that temporal logic[3] could have in the building of reactive software systems (e.g. desktop GUI applications, among many others). If you visit Harel's full list of publications[4] and do an in-page search for the terms "LSC", "behavioral" and "scenario", you can follow the links to a number of papers published since the early 2000s, related to the application of temporal logic in the process of software design.
It's possible that my connection of Granger's "eve" to Harel's work is completely mistaken; and if so, I apologize for jumping the gun.
[1] http://www.wisdom.weizmann.ac.il/~harel/papers/LiberatingPro...
[2] http://www.wisdom.weizmann.ac.il/~playbook/
[3] http://en.wikipedia.org/wiki/Temporal_logic
[4] http://www.wisdom.weizmann.ac.il/~harel/papers.html
Prof. Rodney Brooks has always had a better more pragmatic take on this, coming from the robotics field no less:
http://en.m.wikipedia.org/wiki/Subsumption_architecture
http://en.m.wikipedia.org/wiki/Behavior-based_robotics
Kodu was based on this model, and it worked very well.
http://en.m.wikipedia.org/wiki/Subsumption_architecture
http://en.m.wikipedia.org/wiki/Behavior-based_robotics
Kodu was based on this model, and it worked very well.
We did read the manifesto and I'm fairly convinced that Harel's vision of interactive specification and refinement is the the long-term future of software. I'm not sure how to get there though, short of general AI. Eve aims to reduce the amount of specification required and can make sensible guesses about implementation, but it is not able to 'fill in the blanks' for partial specifications and we won't be focusing on that any time soon.
Thinking of programming as a dialogue with the computer is a really strong metaphor that I gladly recognize as something that inspired you [1][2].
Short: You provide the goals and the constraints, then through a back and forth dialogue with the computer you describe and clarify the problem (and also your understanding). You keep on negotiating and providing more constraints until it simply finds a possible solution (the problem domain is now computable) or the best fitting solution now satisfies your needs (in time).
The hardest parts are probably: 1. Collecting, developing the constraint solvers. Should we imagine that collection more as platform of user contributed (programmed/trained) packages? 2. Developing the dialouge that is not just textual but visual (in both ways) (notepad vs IDE vs Theater(?!) don't forget macros/acting out!)). Showing is always faster then writing and gives one better cues on the closures/framework of the actual discussion.
[1] http://scattered-thoughts.net/blog/2014/07/21/imperative-thi... [2] https://gist.github.com/jamii/8957881c8eaa4035f4ae
Short: You provide the goals and the constraints, then through a back and forth dialogue with the computer you describe and clarify the problem (and also your understanding). You keep on negotiating and providing more constraints until it simply finds a possible solution (the problem domain is now computable) or the best fitting solution now satisfies your needs (in time).
The hardest parts are probably: 1. Collecting, developing the constraint solvers. Should we imagine that collection more as platform of user contributed (programmed/trained) packages? 2. Developing the dialouge that is not just textual but visual (in both ways) (notepad vs IDE vs Theater(?!) don't forget macros/acting out!)). Showing is always faster then writing and gives one better cues on the closures/framework of the actual discussion.
[1] http://scattered-thoughts.net/blog/2014/07/21/imperative-thi... [2] https://gist.github.com/jamii/8957881c8eaa4035f4ae
Seems very closely related to what I've been talking about / working on lately. Cool!
https://speakerdeck.com/mtrimpe/graphel-the-meaning-of-an-im...
https://speakerdeck.com/mtrimpe/graphel-the-meaning-of-an-im...
I'm not sure if it's an inspiration for Chris but it's definitely related since a key focus for Chris seems to be on building it on immutable data structures (and hence essentially temporal.)
> No one is talking about making normal people into professional programmers.
Right, he's talking about replacing the need for professional programmers. And, in doing so, he focuses on not needing the guy that knows a particular language, rather than not needing the guy that can think through a structure a logical approach to solving the problem.
Its all pretty vague, anyway, and the further clarification on the thread sounds like the goal is the yet another app builder (the supposed gap left by VB6 is specifically cited as the motivation) for the web, of which there are many existing now, all with similar pitches about letting "normal people" (or business experts) build line-of-business apps without hiring a professional programmer.
Right, he's talking about replacing the need for professional programmers. And, in doing so, he focuses on not needing the guy that knows a particular language, rather than not needing the guy that can think through a structure a logical approach to solving the problem.
Its all pretty vague, anyway, and the further clarification on the thread sounds like the goal is the yet another app builder (the supposed gap left by VB6 is specifically cited as the motivation) for the web, of which there are many existing now, all with similar pitches about letting "normal people" (or business experts) build line-of-business apps without hiring a professional programmer.
> And, in doing so, he focuses on not needing the guy that knows a particular language
That's a pretty narrow way of reading what I was saying. What I meant is the one guy who knows how to program and I just happened to pick Python because that's the common case in science. Do you really think a mathematician, biologist, or chemist can't think through a logical approach to solving a problem? I certainly believe they can, the problem is then in translating that to the computer. Right now, that would mean knowing (pick your programming language) and translating that logical solution. We want to make that way, way easier, to the point where it's like using the tools you already do to do this stuff (Excel).
> Its all pretty vaguem, anyway, and the further clarification on the thread sounds like the goal is the yet another app builder
We've bootstrapped the editor, parts of the incremental compiler, parts of the platform, the domain editors, etc. If you can do that in an "yet another app builder", I'd definitely love to see it. We're picking one domain to focus on because that's how you grow a product, but at the end of the day, if it doesn't suit my needs as well, I certainly can't call it a "better programming" in general.
That's a pretty narrow way of reading what I was saying. What I meant is the one guy who knows how to program and I just happened to pick Python because that's the common case in science. Do you really think a mathematician, biologist, or chemist can't think through a logical approach to solving a problem? I certainly believe they can, the problem is then in translating that to the computer. Right now, that would mean knowing (pick your programming language) and translating that logical solution. We want to make that way, way easier, to the point where it's like using the tools you already do to do this stuff (Excel).
> Its all pretty vaguem, anyway, and the further clarification on the thread sounds like the goal is the yet another app builder
We've bootstrapped the editor, parts of the incremental compiler, parts of the platform, the domain editors, etc. If you can do that in an "yet another app builder", I'd definitely love to see it. We're picking one domain to focus on because that's how you grow a product, but at the end of the day, if it doesn't suit my needs as well, I certainly can't call it a "better programming" in general.
> Do you really think a mathematician, biologist, or chemist can't think through a logical approach to solving a problem?
No, then again, I think that mathemeticians, biologists, and chemists now, with existing tools, often program computers to solve problems without being "professional programmers". (And not just with Excel and similar tools.)
> We've bootstrapped the editor, parts of the incremental compiler, parts of the platform, the domain editors, etc. If you can do that in an "yet another app builder", I'd definitely love to see it.
I think all of that is significant, and I didn't intend to minimize that.
> We're picking one domain to focus on because that's how you grow a product
Insofar as I have concerns with the way the short-term focus is described, its that:
1) There isn't a clear description of what unique thing Eve intends to the table in that initial focal market, and
2) The initial focal market, as it has been described, seems quite crowded, rather than a gap that needs filled.
No, then again, I think that mathemeticians, biologists, and chemists now, with existing tools, often program computers to solve problems without being "professional programmers". (And not just with Excel and similar tools.)
> We've bootstrapped the editor, parts of the incremental compiler, parts of the platform, the domain editors, etc. If you can do that in an "yet another app builder", I'd definitely love to see it.
I think all of that is significant, and I didn't intend to minimize that.
> We're picking one domain to focus on because that's how you grow a product
Insofar as I have concerns with the way the short-term focus is described, its that:
1) There isn't a clear description of what unique thing Eve intends to the table in that initial focal market, and
2) The initial focal market, as it has been described, seems quite crowded, rather than a gap that needs filled.
Perhaps an even more accurate approximation is "replacing the need for professional programmers for problems that shouldn't require professional programming"
A simple example of this is SQL. You shouldn't need to be a pro engineer to run some simple queries.
Another example is Mathematica. Scientists and engineers want to solve their domain problems, can learn a little bit of stuff, but shouldn't have to learn about build tools or d3 just to plot some data and solve some equations.
Whether Eve gets the balance right and is useful remains to be seen, but there is plenty of room at the bottom for empowering non-engineers.
A simple example of this is SQL. You shouldn't need to be a pro engineer to run some simple queries.
Another example is Mathematica. Scientists and engineers want to solve their domain problems, can learn a little bit of stuff, but shouldn't have to learn about build tools or d3 just to plot some data and solve some equations.
Whether Eve gets the balance right and is useful remains to be seen, but there is plenty of room at the bottom for empowering non-engineers.
>but learning languages and syntax is the trivial part of programming
I beg to differ. Some of the biggest frustrations are languages and syntax for people learning to program. For a professional programmer learning another language is like learning another car for a mechanic. They all look the same after a while. But trying to teach someone how an engine works is not trivial.
I beg to differ. Some of the biggest frustrations are languages and syntax for people learning to program. For a professional programmer learning another language is like learning another car for a mechanic. They all look the same after a while. But trying to teach someone how an engine works is not trivial.
For someone to become a effective creator of programs today, they need to learn
- a style of analytical thinking and formal reasoning
- syntax and semantics of 1 or more programming languages
- interpreting the debug and error reporting capabilities of their environment
- version control
- text editing
- one or more build systems
- a mental model of computing machines and networks
Outside of academic environments you need to learn all of these thing simultaneously. If we can collapse away a few of these things with minimal loss of productivity we make programming much accessible.
- a style of analytical thinking and formal reasoning
- syntax and semantics of 1 or more programming languages
- interpreting the debug and error reporting capabilities of their environment
- version control
- text editing
- one or more build systems
- a mental model of computing machines and networks
Outside of academic environments you need to learn all of these thing simultaneously. If we can collapse away a few of these things with minimal loss of productivity we make programming much accessible.
> Knowing some programming language isn't it, its a mode of thinking and analysis.
You seem to be implying that we currently have tools that provide a suitably natural and frictionless medium for such thinking and analysis. But what if our current languages/tools are more like Roman numerals and there's still the computing version of Arabic numerals out there to be found?
You seem to be implying that we currently have tools that provide a suitably natural and frictionless medium for such thinking and analysis. But what if our current languages/tools are more like Roman numerals and there's still the computing version of Arabic numerals out there to be found?
[deleted]
The vision here is noble, and I applaud what Chris has done with Light Table, but based on the discussion here, I think the Eve team is setting themselves up for disappointment.
1. By bringing investors on board, and promising Hacker News they're going to change the world, they're basically asking to be stressed out all the time. This is not conducive to innovation.
2. There's a fundamental tension between creating something usable by Joe in accounting and something that is cutting-edge from a technical perspective (highly concurrent etc). 90% of line-of-business programs use less than 10% of CPU, and approximately 0% need high concurrency. Joe in accounting is not going to build the next WhatsApp, and every moment you spend figuring out multi-core whatever, you're not thinking about how to help Joe make his Cash Flow Prediction Tool look slick.
3. From a marketing perspective, creating a new category of software is an enormously difficult undertaking. There are two related problems here:
A. You have to find potential customers. Because nothing like Eve exists, the market does not exist. I.e. the world's "creators" don't all go to the same conferences, visit the same websites, and hang out in the same IRC channels. Light Table at least was addressing an existing market, i.e. "programmers who use X/Y/Z", so you could actually find customers, and they could tell their programmer friends about it.
B. After you find potential customers, you have to educate them, i.e. explain the potential benefits and teach them how to use the darn thing. This requires a major investment from both you and from your interested customers. It is much, much easier to sell something that relieves the customer's pain than something that promises him "superpowers". 95% of "creators" have only vague and incorrect notions about programming, so you'll have a hell of a time explaining the product. Let's say you want to target Joe in accounting: What will the advertisement actually say? "Do you miss VB6?"
4. The fact that the LT team is giving up on Light Table when it's still the proverbial "couple of guys" is not a good sign. From a marketing perspective, Light Table had every advantage in the world: tons of publicity / viral videos, a clearly defined market, and an exciting product that got people talking. The fact that they're throwing in the towel tells me, well, they quit too early, and they'll quit on Eve when the going gets tough.
To be more specific, I think Chris's fears about the market for Light Table are totally unfounded. To wit:
* "The competition has millions of man-hours invested". Who cares? On a day-to-day basis I execute maybe 3% of the code paths in my editor. In my view, Light Table is a classic opportunity to offer 10% of the functionality of the bloated competition but really knock that 10% out of the park. Look at e.g. Pixelmator versus Photoshop or [toot toot] Wizard versus SPSS.
* "Programmers don't pay for software". I'm sorry, but this is a poor excuse, and if I were your drill sergeant, and this were an 80s movie, I'd be screaming in your face right now. Programmers are a wealthy and growing segment. They'll pay for stuff if it helps them get their job done (GitHub, TextMate, books, conferences, heck Visual Studio). Not only that, with the product's positioning, you have a great opportunity to sell to people who want to be programmers, the "ski pants" market, if you will. If you read the comments in this thread, you'll notice that your users are complaining about the Light Table's lack of polish and they clearly recognize the need to pay someone to provide that polish.
In sum, I think the LT team should have worked themselves into a crying, bleeding, starving mess to make Light Table a commercial success, and then pursued bigger ideas once they had the business experience under their belt. Even if it took a few years, they'd be in a much better position both financially and psychologically to tackle a Grand New World-Changing Product once they had the routine down from their Small Life-Changing Editor.
As an indie-app-developer-whatever myself, I would kill for the kind of publicity and market opportunity that Light Table had. I wish Chris & Co. all the best with Eve, and I truly hope they succeed. But based on what I'm reading, I don't think they don't deserve to.
1. By bringing investors on board, and promising Hacker News they're going to change the world, they're basically asking to be stressed out all the time. This is not conducive to innovation.
2. There's a fundamental tension between creating something usable by Joe in accounting and something that is cutting-edge from a technical perspective (highly concurrent etc). 90% of line-of-business programs use less than 10% of CPU, and approximately 0% need high concurrency. Joe in accounting is not going to build the next WhatsApp, and every moment you spend figuring out multi-core whatever, you're not thinking about how to help Joe make his Cash Flow Prediction Tool look slick.
3. From a marketing perspective, creating a new category of software is an enormously difficult undertaking. There are two related problems here:
A. You have to find potential customers. Because nothing like Eve exists, the market does not exist. I.e. the world's "creators" don't all go to the same conferences, visit the same websites, and hang out in the same IRC channels. Light Table at least was addressing an existing market, i.e. "programmers who use X/Y/Z", so you could actually find customers, and they could tell their programmer friends about it.
B. After you find potential customers, you have to educate them, i.e. explain the potential benefits and teach them how to use the darn thing. This requires a major investment from both you and from your interested customers. It is much, much easier to sell something that relieves the customer's pain than something that promises him "superpowers". 95% of "creators" have only vague and incorrect notions about programming, so you'll have a hell of a time explaining the product. Let's say you want to target Joe in accounting: What will the advertisement actually say? "Do you miss VB6?"
4. The fact that the LT team is giving up on Light Table when it's still the proverbial "couple of guys" is not a good sign. From a marketing perspective, Light Table had every advantage in the world: tons of publicity / viral videos, a clearly defined market, and an exciting product that got people talking. The fact that they're throwing in the towel tells me, well, they quit too early, and they'll quit on Eve when the going gets tough.
To be more specific, I think Chris's fears about the market for Light Table are totally unfounded. To wit:
* "The competition has millions of man-hours invested". Who cares? On a day-to-day basis I execute maybe 3% of the code paths in my editor. In my view, Light Table is a classic opportunity to offer 10% of the functionality of the bloated competition but really knock that 10% out of the park. Look at e.g. Pixelmator versus Photoshop or [toot toot] Wizard versus SPSS.
* "Programmers don't pay for software". I'm sorry, but this is a poor excuse, and if I were your drill sergeant, and this were an 80s movie, I'd be screaming in your face right now. Programmers are a wealthy and growing segment. They'll pay for stuff if it helps them get their job done (GitHub, TextMate, books, conferences, heck Visual Studio). Not only that, with the product's positioning, you have a great opportunity to sell to people who want to be programmers, the "ski pants" market, if you will. If you read the comments in this thread, you'll notice that your users are complaining about the Light Table's lack of polish and they clearly recognize the need to pay someone to provide that polish.
In sum, I think the LT team should have worked themselves into a crying, bleeding, starving mess to make Light Table a commercial success, and then pursued bigger ideas once they had the business experience under their belt. Even if it took a few years, they'd be in a much better position both financially and psychologically to tackle a Grand New World-Changing Product once they had the routine down from their Small Life-Changing Editor.
As an indie-app-developer-whatever myself, I would kill for the kind of publicity and market opportunity that Light Table had. I wish Chris & Co. all the best with Eve, and I truly hope they succeed. But based on what I'm reading, I don't think they don't deserve to.
Hey Evan, I have immense respect for your work, but this is surprisingly armchair quarterbackish.
> "The competition has millions of man-hours invested". Who cares? On a day-to-day basis I execute maybe 3% of the code paths in my editor
This is the Microsoft Office argument and the problem is that no one uses the same 3%. If they did, sure it'd be "dead simple", by that of course I mean take many, many years of work. Sublime which attempts to do far less than we wanted to took 5 years to get to today and I'm not sure it really is a commercial success capable of supporting 3+ people.
> "Programmers don't pay for software". I'm sorry, but this is a poor excuse
It's far from an excuse, it's the truth. It doesn't matter if developers as a class have a lot of money. They don't actually spend it. I don't know a single person who has ever personally paid for Visual Studio. Github is a service and the vast majority of their money comes from companies not individuals. How many people run stuff only on the heroku free tier?
Or here's a direct example: when we launched the kickstarter people \freaked\ out about us pricing it at $50. We had to drop it all the way to $15 and folks still complained endlessly about it. It is well known that short of a service targeted at companies, it is near impossible to sell developer tools. After all, it's a group of people who look at a piece of software and say "I can build that".
If there's some secret, we're missing it. There's an entire organization [0] that has grown up around trying to help dev focused companies figure this stuff out. It's led by James Lindenbaum (co-founder of Heroku, invested in us), he knows his stuff and he couldn't figure out a way to make this work out either.
[0]: http://heavybit.com/
> "The competition has millions of man-hours invested". Who cares? On a day-to-day basis I execute maybe 3% of the code paths in my editor
This is the Microsoft Office argument and the problem is that no one uses the same 3%. If they did, sure it'd be "dead simple", by that of course I mean take many, many years of work. Sublime which attempts to do far less than we wanted to took 5 years to get to today and I'm not sure it really is a commercial success capable of supporting 3+ people.
> "Programmers don't pay for software". I'm sorry, but this is a poor excuse
It's far from an excuse, it's the truth. It doesn't matter if developers as a class have a lot of money. They don't actually spend it. I don't know a single person who has ever personally paid for Visual Studio. Github is a service and the vast majority of their money comes from companies not individuals. How many people run stuff only on the heroku free tier?
Or here's a direct example: when we launched the kickstarter people \freaked\ out about us pricing it at $50. We had to drop it all the way to $15 and folks still complained endlessly about it. It is well known that short of a service targeted at companies, it is near impossible to sell developer tools. After all, it's a group of people who look at a piece of software and say "I can build that".
If there's some secret, we're missing it. There's an entire organization [0] that has grown up around trying to help dev focused companies figure this stuff out. It's led by James Lindenbaum (co-founder of Heroku, invested in us), he knows his stuff and he couldn't figure out a way to make this work out either.
[0]: http://heavybit.com/
What's also missing in this discussion is that you can get programmers to get their companies to pay tons of cash.
Building a consultancy company around a technology product is probably on of IT's most classic business models.
Building a consultancy company around a technology product is probably on of IT's most classic business models.
That is certainly true, though I haven't seen many IDE-based consultancies. In our particular case, that wouldn't have been the right direction - none of us want to be "programming", much less doing it at other people's whim.
I meant to refer to Eve and not LightTable.
From what I understand something like Eve is begging for a hybrid product/consultancy approach...
Putting personal preferences aside it would by far be the most logical path towards building a big business out of it.
From what I understand something like Eve is begging for a hybrid product/consultancy approach...
Putting personal preferences aside it would by far be the most logical path towards building a big business out of it.
Ah yeah, Eve has a ton of interesting business opportunities around it, everything from on demand computation/hosting (heroku) to collaboration and versioning (github). Consulting or even just building products of our own that are much easier to maintain/faster to build is also an option.
You need to understand that people like to complain about stuff. If they complained about the $50 and then you dropped it to $15. They got exactly what they wanted. Why would they not just keep complaining to get it down another $5?
People pay for stuff that is useful to them, the problem with light table is people don't understand why it is useful to them until they think about it/look at it. You should have completely ignored every complaint related too money.
VS costs hundreds of dollars (going into the thousands for MSDN). And it is used by hundreds of thousands of programmers.
If product A results in a increase in productivity people will pay for it.
People pay for stuff that is useful to them, the problem with light table is people don't understand why it is useful to them until they think about it/look at it. You should have completely ignored every complaint related too money.
VS costs hundreds of dollars (going into the thousands for MSDN). And it is used by hundreds of thousands of programmers.
If product A results in a increase in productivity people will pay for it.
Microsoft is an irrational actor: they will sink billions of dollars into VS without regard for direct return in order to secure Windows as a platform. Using them as an example is useless. Moreover, VS is "purchased" almost exclusively as part of the entire Microsoft stack. When I was there a tiny, tiny fraction of revenue came from anyone actually just buying VS.
I've heard rumors that VS is a $1b/year business, which is definitely nothing to sneeze at.
How does Eve compare to something like Autodesk's design script?
How does Eve compare to something like Autodesk's design script?
Okay then sublime text. Hundreds of thousands of people have paid for that.
Out of curiosity, do you have real numbers there? I'd be quite surprised if it was really hundreds of thousands.
Why? It's probably one of the most popular editors for PHP/HTML/CSS/Javascript/Ruby/Python.
According to https://sublime.wbond.net/stats there are roughly 2.5M sublime text users. If even 10% of them paid for it, that would be 250,000. Assuming 10% is a little high, let's do 1% would would be 25,000.
Even if those numbers are wrong (which they may be I have no idea how he gets those numbers, and if everyone is using Package Control) there can very easily be hundreds of thousands of paid licenses.
According to https://sublime.wbond.net/stats there are roughly 2.5M sublime text users. If even 10% of them paid for it, that would be 250,000. Assuming 10% is a little high, let's do 1% would would be 25,000.
Even if those numbers are wrong (which they may be I have no idea how he gets those numbers, and if everyone is using Package Control) there can very easily be hundreds of thousands of paid licenses.
I know Chris already responded to some of your concerns, but I'd like to weigh in briefly as well.
> By bringing investors on board, and promising Hacker News they're going to change the world
a16z constitutes the majority of our investment, and Chris Dixon at a16z is rather well equipped to help us tackle this problem. It has also given us access to a rather impressive network of very smart people who can help us. Yes, there is a trade-off in that our investors have a say in what we do, but given the small number of investors, and who they are individually, there is a low probability of micromanagement from them. Secondly, we never promised Hacker News that we're going to change the world; we said we have some ambitious ideas, and that we wanted to pursue them. Might they change the world? Sure. Might we also die trying? Absolutely. That's a risk inherent to... well, everything. Certainly a lot of things worth doing.
> The fact that the LT team is giving up on Light Table/I think the LT team should have worked themselves into a crying, bleeding, starving mess
The last time we had office hours with pg about LT, we didn't exactly leave with a warm fuzzy feeling about continuing work on the project. But we did, for another year, spending the remainder of the Kickstarter money and approaching the end of the runway, staying as lean as possible, and continuing to develop a product that pg, James Lindenbaum, et al, all regarded as a nonviable business. We may have to agree to disagree on how plausible it is to make an open source IDE a commercial success, but there was plenty of crying and bleeding before we came to work on Eve.
At that point, it became what Jamie aptly described as a matter of return on effort. There isn't much sensibility in spending countless hours to solve the wrong problem, and running out of money didn't strike us as the optimal way to continue working on a problem we genuinely cared about. Instead, once LT became open source, we forged ahead into an area that Chris Dixon called a "Vietnam" of software, and while Eve may be particularly difficult, it brought us new funds precisely so we don't have to give up.
> I truly hope they succeed
Thank you, so do we :)
> By bringing investors on board, and promising Hacker News they're going to change the world
a16z constitutes the majority of our investment, and Chris Dixon at a16z is rather well equipped to help us tackle this problem. It has also given us access to a rather impressive network of very smart people who can help us. Yes, there is a trade-off in that our investors have a say in what we do, but given the small number of investors, and who they are individually, there is a low probability of micromanagement from them. Secondly, we never promised Hacker News that we're going to change the world; we said we have some ambitious ideas, and that we wanted to pursue them. Might they change the world? Sure. Might we also die trying? Absolutely. That's a risk inherent to... well, everything. Certainly a lot of things worth doing.
> The fact that the LT team is giving up on Light Table/I think the LT team should have worked themselves into a crying, bleeding, starving mess
The last time we had office hours with pg about LT, we didn't exactly leave with a warm fuzzy feeling about continuing work on the project. But we did, for another year, spending the remainder of the Kickstarter money and approaching the end of the runway, staying as lean as possible, and continuing to develop a product that pg, James Lindenbaum, et al, all regarded as a nonviable business. We may have to agree to disagree on how plausible it is to make an open source IDE a commercial success, but there was plenty of crying and bleeding before we came to work on Eve.
At that point, it became what Jamie aptly described as a matter of return on effort. There isn't much sensibility in spending countless hours to solve the wrong problem, and running out of money didn't strike us as the optimal way to continue working on a problem we genuinely cared about. Instead, once LT became open source, we forged ahead into an area that Chris Dixon called a "Vietnam" of software, and while Eve may be particularly difficult, it brought us new funds precisely so we don't have to give up.
> I truly hope they succeed
Thank you, so do we :)
I couldn't agree more with your #4.
I was waiting for LT to become a tool I can recommend to beginners. It's far from being ready, and it now appears they just gave up. If LT was too hard for them, what are they even talking about with this Eve thing?
I was waiting for LT to become a tool I can recommend to beginners. It's far from being ready, and it now appears they just gave up. If LT was too hard for them, what are they even talking about with this Eve thing?
It's not a matter of difficulty, it's a matter of return on effort. We could pour hundreds of man-years into catching up with emacs/vim but we would be solving the wrong problem. The reason that language tooling is so hard is because languages are not built for this kind of tooling.
Why would anyone want to catch up with emacs/vim? The original idea behind LT was visual programming, as it was shown in the Bret Victor's demo. That was the whole point, and I don't feel LB provides that yet. That's why I'm sad they gave up on it, and started a new project, which appears to be even more difficult.
Programs are written in text. If you want to edit programs, you have to be reasonable text editor. You need find-and-replace. You need to handle files being updated underneath you. You need syntax highlighting and incremental parsing. You need to be able to match error messages to locations in files (much harder than it sounds). You need to be able to open large files without dying. You need to scroll smoothly. You need to handle custom key bindings, different keyboard layouts (eg https://github.com/LightTable/LightTable/issues/620) and unicode editing.
You have to do all these things because if you don't the editor is not usable for editing programs. The vast majority of the code in LT is devoted to basic text editing. Just reaching the same level of polish as, say, gedit would take many more man-years of work. All of that work has to be done before we can spend time on actual innovation.
Or we could just make a language with a sane serialisation format. Eve already supports live coding, incremental compilation as you type, globally unique identifiers for every piece of code and time-travel debugging. We also have algorithms sketched out for concurrent editing, commit-as-you-type (ie the version control system stores every keystroke) and causal history for data (why/why-not provenance). We got to do all that in a few months because we didn't have to fuck around building a text editor.
You have to do all these things because if you don't the editor is not usable for editing programs. The vast majority of the code in LT is devoted to basic text editing. Just reaching the same level of polish as, say, gedit would take many more man-years of work. All of that work has to be done before we can spend time on actual innovation.
Or we could just make a language with a sane serialisation format. Eve already supports live coding, incremental compilation as you type, globally unique identifiers for every piece of code and time-travel debugging. We also have algorithms sketched out for concurrent editing, commit-as-you-type (ie the version control system stores every keystroke) and causal history for data (why/why-not provenance). We got to do all that in a few months because we didn't have to fuck around building a text editor.
Wow, what you described is not at all what I was looking for when I supported Light Table. I already have IPython IDE where I have all that text editing, and all other stuff I need to type in and run my code. I was looking for something completely different, not yet another text editor! I was looking for something visual, where I can see what my code is doing without me having to insert a bunch of print statement.
In fact, I found some of that here:
http://pythontutor.com/visualize.html#mode=edit
but I hoped that LT will do it even better.
I think their new project plans to fulfill Bret Victor's vision in a way LT cannot. Bret Victor's demo was meant as a starting point. He was really advocating tools that help us understand the systems we create as programmers. Not live editing. I think Eve is an attempt to give us the tools to build and reason about our systems.
>> "they clearly recognize the need to pay someone to provide that polish"
I don't see anyone offering to pay for polish. Can you point to these instances?
I've been active in the LT community for most of a year and don't recall _one_ offer to pay for any bug fix or feature. If anyone has such a request, please make it in LT's github issues or mailing list and I'll consider looking into it.
I don't see anyone offering to pay for polish. Can you point to these instances?
I've been active in the LT community for most of a year and don't recall _one_ offer to pay for any bug fix or feature. If anyone has such a request, please make it in LT's github issues or mailing list and I'll consider looking into it.
I think the (relative) success of RubyMotion as a paid product puts the myth that programmers won't pay for software to bed. I haven't bought RubyMotion yet because it doesn't meet my present needs, I would buy LightTable (for an RM order of magnitude price) because it does. What LT will probably not do though is sell in a way that pays back VC's looking for a go big or go home hit.
The description of Eve seems pretty vague, which I'm sure is intentional, but it'd be nice to get a bit of clarification.
It sounds like Eve will essentially be a visual programming language, similar to the many others that have come across Hacker News.
Chris - is Eve a visual programming language? If so, what makes it better than all the others that have tried and failed?
It sounds like Eve will essentially be a visual programming language, similar to the many others that have come across Hacker News.
Chris - is Eve a visual programming language? If so, what makes it better than all the others that have tried and failed?
It depends on how you use the term "visual programming language", which unfortunately has a lot of baggage around it. It is not sticking lego blocks together like Scratch or LEGO Mindstorms, nor is it the boxes with arrows pointing at eachother like Max MSP/Lab View/Blueprint/noflo, but it's also not strictly textual. The closest analog really is Excel or Access, but with the ability to describe how you translate one sheet/table to another one. Your main interface is a grid of data and a list of output tables. On top of that sits a set of domain editors though, to make drawing UI, for example, not an exercise in writing a bunch of rows out into a table. Instead you use a photoshop-like tool to just draw your UI. Same with doing math or string operations or flying drones or working with music and so on. We of course can't cover every domain, but what's interesting is that the editor is itself kind of like an editor of editors and it'll make it fairly trivial for you to build your own manipulable representations.
Trying to reduce UI design to something like Photoshop seems quite problematic to me. It encourages the designer to think that what you see is all there is. What about the things that aren't immediately evident in a WYSIWYG environment, like accessibility for users with disabilities (I'm thinking especially of blind users)? And if the WYSIWYG environment uses absolute positioning, as Photoshop does, then how will the UI adjust itself to different screen sizes? An advantage of representing a UI in a human-editable format like HTML, XAML, or Android's XML layout system is that all the properties of the UI elements are equally visible and editable, not just the things that are visible in the on-screen rendering. Also, I think that reading and editing the UI definition in a textual format forces the designer to think of the UI at a more abstract level than just dragging and dropping elements onto the screen and tweaking the things that are visible in that environment. And for the UI definition to actually be human editable, one is forced to leave absolute layout to the computer, making it more flexible.
Photoshop isn't even used much for visual design these days: it's all pretty much Illustrator. Vectors make dealing with resolution much easier, but redlining is still needed when rasterizing to lower resolutions.
Most of the designers (outside of web to be sure, since I don't live in silicon valley) I know don't use textual formats, that is for developers. Much of the content is too dynamic to work with textually without substantial programming.
Most of the designers (outside of web to be sure, since I don't live in silicon valley) I know don't use textual formats, that is for developers. Much of the content is too dynamic to work with textually without substantial programming.
We're doing some clever stuff between constraint layout and relative layout that will make a lot of that concern disappear. We also intend to present this as almost a statemachine, or a storyboard where you see the various states of your UI laid out, which gives us an opportunity to surface a lot of the "unseen" aspects of UI.
It seems much easier to answer these questions once, in the domain-specific editor, than to re-implement them over and over in each project.
The sticking point isn't the "visual" part, it's the "not text" part.
What's the big deal? There is an entire family of conventions and tools that have been built up over the years to support coding in text: editors, version control, diff tools, patches, linters, code generators, naming conventions, meanings of special symbols, etc.
It's definitely technically possible to change the paradigm entirely, but how does one avoid reinventing twelve wheels?
To paraphrase, "I know, you won't write my language in flat text files. And now you have a dozen problems."
What am I missing?
What's the big deal? There is an entire family of conventions and tools that have been built up over the years to support coding in text: editors, version control, diff tools, patches, linters, code generators, naming conventions, meanings of special symbols, etc.
It's definitely technically possible to change the paradigm entirely, but how does one avoid reinventing twelve wheels?
To paraphrase, "I know, you won't write my language in flat text files. And now you have a dozen problems."
What am I missing?
Those tools are hard to build. Sure, parsers are easy. Incremental parsers that can deal with half-edited text are hard (that's basically the entire function of Intellij MPS). Running static analysis on half-edited text is hard. Keeping text in sync with runtime state is hard. Even diffing text is hard.
If we were talking about any other coding problem and I suggested you keep all your data in a complicated text serialisation spread across several hundred text files and resolve conflicts by diffing the files line-by-line, I would be laughed out of the room. The vast majority of work in any IDE, including Light Table, is just working around the fact that plain text is a terrible storage mechanism for complex, concurrently edited data.
That's not to say that you shouldn't use text to write or view the program or that we should all be coding by drawing pretty pictures and connecting lines. Just that we should keep the code in a sensible, networked data-store with support for concurrent editing and ACID transactions and then the way you choose to present and edit it can vary from person to person.
If we were talking about any other coding problem and I suggested you keep all your data in a complicated text serialisation spread across several hundred text files and resolve conflicts by diffing the files line-by-line, I would be laughed out of the room. The vast majority of work in any IDE, including Light Table, is just working around the fact that plain text is a terrible storage mechanism for complex, concurrently edited data.
That's not to say that you shouldn't use text to write or view the program or that we should all be coding by drawing pretty pictures and connecting lines. Just that we should keep the code in a sensible, networked data-store with support for concurrent editing and ACID transactions and then the way you choose to present and edit it can vary from person to person.
1. OK, you have prima facia case that some problems won't be problems anymore. But the problems you mention are mostly nice-to-haves and not must-haves. For example, I can do static analysis manually or when it's safe (pre-commit, during saves).
> If we were talking about any other coding problem and I suggested you keep all your data in a complicated text serialisation spread across several hundred text files...
Except developing code in a team of size greater than one is a distributed computation problem. Distributed persistence mechanisms are basically a bunch of files spread across a system. And they deal with some of the same problems (availability, versioning, reconciliation, replication, etc.). Speaking of which, these are problems are typically solved through tools (git, etc.) that presume textual languages.
3. To be more concrete:
Q: How do I post code samples to sites like StackOverflow?
Q: How do I create patches from and apply patches to my codebase?
Q: Does git (or some other offline editing mode) work?
...some of the answers may include statements like, "Well, wiring and metadata is all XML (or something) under the hood, so use your existing merge tools." In that case, we're dealing with two things: a language and a configuration spec. We're not really talking about a system that's friendly to coders after all.
...again, these are technically solvable problems. I just think people are vastly underestimating the level of effort needed to get to feature parity with the current way of doing things.
The best way to prove me too skeptical is to develop a decent-sized project across a decent-sized team, which is something non-text development tools (including Excel and Photoshop) haven't been particularly good at. My bet is that this won't happen and that at best Eve will be a successful enterprise tool for domain-specific problems that can be tackled by small teams (again, like Excel, Photoshop, LabView, etc.).
Not that there's anything wrong with that. Adobe is a successful company.
> If we were talking about any other coding problem and I suggested you keep all your data in a complicated text serialisation spread across several hundred text files...
Except developing code in a team of size greater than one is a distributed computation problem. Distributed persistence mechanisms are basically a bunch of files spread across a system. And they deal with some of the same problems (availability, versioning, reconciliation, replication, etc.). Speaking of which, these are problems are typically solved through tools (git, etc.) that presume textual languages.
3. To be more concrete:
Q: How do I post code samples to sites like StackOverflow?
Q: How do I create patches from and apply patches to my codebase?
Q: Does git (or some other offline editing mode) work?
...some of the answers may include statements like, "Well, wiring and metadata is all XML (or something) under the hood, so use your existing merge tools." In that case, we're dealing with two things: a language and a configuration spec. We're not really talking about a system that's friendly to coders after all.
...again, these are technically solvable problems. I just think people are vastly underestimating the level of effort needed to get to feature parity with the current way of doing things.
The best way to prove me too skeptical is to develop a decent-sized project across a decent-sized team, which is something non-text development tools (including Excel and Photoshop) haven't been particularly good at. My bet is that this won't happen and that at best Eve will be a successful enterprise tool for domain-specific problems that can be tackled by small teams (again, like Excel, Photoshop, LabView, etc.).
Not that there's anything wrong with that. Adobe is a successful company.
Have you ever looked into how version control for Smalltalk worked?
People who worked with that used to love it and I'm fairly certain that Eve's model would (be able to) work quite similarly.
People who worked with that used to love it and I'm fairly certain that Eve's model would (be able to) work quite similarly.
Incremental parsers are actually quite easy: just go recursive descent and memoize. Keeping text in sync with runtime state is harder, but still not that hard, you just need a nice replay model. Going functional or immutable actually doesn't help very much here: it distracts from the dependency tracing needed to make a live system work.
All the stuff I've done here [1] is plain text. I'm sure you have other good reasons for avoiding text, but these aren't that strong; text is mostly orthogonal to the real problems of building live systems.
[1] http://research.microsoft.com/en-us/people/smcdirm/managedti...
All the stuff I've done here [1] is plain text. I'm sure you have other good reasons for avoiding text, but these aren't that strong; text is mostly orthogonal to the real problems of building live systems.
[1] http://research.microsoft.com/en-us/people/smcdirm/managedti...
Sounds a bit like Kaya (https://vimeo.com/107069470) that I mentioned to you guys. Good luck!
That sounds very similar to LabView (aka. G)... Have you ever tried programming something complicated in LabView? I'd almost rather write assembly.
Professional programming is about managing complexity. It's about putting thousands of man-hours into one single project with a dozen of different people without anyone's head exploding.
Light-table could have potentially been a huge help in the constant battle with managing complexity.. It's an area that has need some serious development (virtually nothing substantial has been added to IDEs in the past decade). But instead you're going to create a beginner friendly monster.
This is the opposite of progress
Professional programming is about managing complexity. It's about putting thousands of man-hours into one single project with a dozen of different people without anyone's head exploding.
Light-table could have potentially been a huge help in the constant battle with managing complexity.. It's an area that has need some serious development (virtually nothing substantial has been added to IDEs in the past decade). But instead you're going to create a beginner friendly monster.
This is the opposite of progress
I was suggesting that it's actually not like labview at all :p
The model we have is significantly better than what we ever showed with Light Table. For example, being able to organize "code" by the actual functionality it's related to instead of files is something that happens by default in our world. You can actually create queries to show any view of the rules that exist in our world that you want (show me everything related to this button, that has been changed in the past month..)
Our model is entirely about preventing people's heads from exploding, taming complexity through a very simple set of primitives that seamlessly work together.
The model we have is significantly better than what we ever showed with Light Table. For example, being able to organize "code" by the actual functionality it's related to instead of files is something that happens by default in our world. You can actually create queries to show any view of the rules that exist in our world that you want (show me everything related to this button, that has been changed in the past month..)
Our model is entirely about preventing people's heads from exploding, taming complexity through a very simple set of primitives that seamlessly work together.
I don't know, I've only used Labview a couple of times, it had really nice interfaces to temperature sensors and some other physical things, you were able to throw together a quick ui monitoring a number of sensors, had a start and stop button and tools for data export. We were able to pick it up in a few hours. Programming the experiment took a couple of hours too, obviously it was rather trivial but I doubt we would have had much luck interfacing with all those different sensors in a C program without major headache.
[deleted]
This is the best comment I've seen on this thread so far. And yet it's already near the bottom.
I didn't want to believe it, but it looks like HN is highly biased toward anything that has some VC behind it, flocking to it like it's suddenly going to change the world.
I didn't want to believe it, but it looks like HN is highly biased toward anything that has some VC behind it, flocking to it like it's suddenly going to change the world.
I've noticed this too lately and it's a bit depressing.
> I didn't want to believe it, but it looks like HN is highly biased toward anything that has some VC behind it, flocking to it like it's suddenly going to change the world.
Considering who sponsors HN, the biases of the community it draws aren't that surprising.
Considering who sponsors HN, the biases of the community it draws aren't that surprising.
There is a podcast from a while back[0] that does a great job of describing their goals and strategy in depth.
[0]: http://podcasts.thoughtbot.com/giantrobots/111
[0]: http://podcasts.thoughtbot.com/giantrobots/111
https://www.youtube.com/watch?v=L6iUm_Cqx2s
Here's a demo they did a while ago. I think it kind of explains what he intends to do with Eve, at least as a concept. On an older blog post he said that it has changed a lot since this demo.
We've been waiting to announce the news for a while now. Can't tell you how happy we are to finally get it out.
We're tremendously excited about the potential we have with Eve and everyone we've talked to about it so far leaves with their head reeling. There's been an undercurrent brewing in the programming community that we're approaching a sort of transformational point in the way software ends up built. We hope to be part of that transformation.
I don't talk about it a ton in the post, but Eve isn't just about giving the Excel generation a seat at the table, but it's also explicitly designed to get us back to what we do best: solving problems. There are some pretty amazing properties that fall out of simplifying things as much as we have: concurrent by default, a real shot at auto-parallelization, a debugger that can tell you when, why, and how a value came to be, diffs not of code but of the output, the chance for true real-time collaboration on software, introspection into every part of the system, and so on. We'll be talking more about how it works over the next couple of months, but I can promise you now: there's some exciting stuff coming for all of us.
As always, in the interest of sharing with the community who helped us get here, I'm happy to answer any questions!
We're tremendously excited about the potential we have with Eve and everyone we've talked to about it so far leaves with their head reeling. There's been an undercurrent brewing in the programming community that we're approaching a sort of transformational point in the way software ends up built. We hope to be part of that transformation.
I don't talk about it a ton in the post, but Eve isn't just about giving the Excel generation a seat at the table, but it's also explicitly designed to get us back to what we do best: solving problems. There are some pretty amazing properties that fall out of simplifying things as much as we have: concurrent by default, a real shot at auto-parallelization, a debugger that can tell you when, why, and how a value came to be, diffs not of code but of the output, the chance for true real-time collaboration on software, introspection into every part of the system, and so on. We'll be talking more about how it works over the next couple of months, but I can promise you now: there's some exciting stuff coming for all of us.
As always, in the interest of sharing with the community who helped us get here, I'm happy to answer any questions!
I've always felt that the tuple oriented view of the world of database was closer to what we should be doing instead of objects (or more lately functions?), although fp definitely gets you closer.
My one comment is to please make eve keyboard oriented from the start. I really don't want to use a mouse. I should be able to navigate every entity logically with a keyboard. For example, I should be able to hit a key to select available link endpoints and another to connect them.
I like visual, but I love keyboard oriented a lot more. Dragging and scrolling are way too overused ui interactions.
My one comment is to please make eve keyboard oriented from the start. I really don't want to use a mouse. I should be able to navigate every entity logically with a keyboard. For example, I should be able to hit a key to select available link endpoints and another to connect them.
I like visual, but I love keyboard oriented a lot more. Dragging and scrolling are way too overused ui interactions.
haha it's funny, this is almost always the first worry programmers have after we talk about Eve.
Don't worry, we'll make sure it works whether you use the mouse, a keyboard, maybe even a touch screen or voice. :)
Don't worry, we'll make sure it works whether you use the mouse, a keyboard, maybe even a touch screen or voice. :)
Suggestion: if you want this to succeed, constrain your scope. Say No to touch-screen & voice! (IMO they are crippled interfaces compared to the keyboard)
Just say 'NO'. & best luck :)
Just say 'NO'. & best luck :)
If they want to reach a billion people then they're going to have to live in a world of touch screen (and maybe voice).
At NDC Oslo this year there was a keynote by Luke Wroblewski on user experience on the web. There's a video on Vimeo: http://vimeo.com/97305189
The key takeaway was that a significant percentage of people are using their smart phones with either only their thumb or their forefinger. Many people don't even have a computing device with a traditional keyboard and full-size screen. That talk got me thinking about this question: what would programming look like if you only use your thumb?
I don't think you can write off these interfaces, rather I think we may need to start to really think about separating creation of core components of software and then orchestrating the interaction of these components as a different aspect to developing software.
At NDC Oslo this year there was a keynote by Luke Wroblewski on user experience on the web. There's a video on Vimeo: http://vimeo.com/97305189
The key takeaway was that a significant percentage of people are using their smart phones with either only their thumb or their forefinger. Many people don't even have a computing device with a traditional keyboard and full-size screen. That talk got me thinking about this question: what would programming look like if you only use your thumb?
I don't think you can write off these interfaces, rather I think we may need to start to really think about separating creation of core components of software and then orchestrating the interaction of these components as a different aspect to developing software.
If they want to reach a billion people then starting off by targeting all 1 billion is probably the wrong way of going about it.
I've often wished I could program even a RAD proof of concept kind of thing on my phone. Many ideas come to me while I'm not at a computer (our desks are not always the most inspiring place we find ourselves) and as a consequence, are gone before I get back to work.
If you're wondering how programming with just your thumbs might work, look at Touch Develop from Microsoft Research.
If you're wondering how programming with just your thumbs might work, look at Touch Develop from Microsoft Research.
Or maybe the people who are primarily using their phone/tablet to access the internet don't actually need to program anything in the first place?
It's worth noting that for programmers with some degree of RSI or a similar injury, a keyboard can potentially be a far less painful interface than a mouse or even touch.
Awesome! Congratulations on the funding, looking forward to see it soon.
Siri, Cortana ... Eve
+100
1. Powerful keyboard-based navigation/manipulation will be extremely helpful.
2. RDBMS-style tuples seem weird to me; why not objects? Quite natural to a layperson, IMO. If a "cell" can hold an object ({name: "Brown shoes", price: { amount: 254, currency: "USD"}} rather than just a scalar value like $2.54) a spreadsheet can be a lot more powerful.
1. Powerful keyboard-based navigation/manipulation will be extremely helpful.
2. RDBMS-style tuples seem weird to me; why not objects? Quite natural to a layperson, IMO. If a "cell" can hold an object ({name: "Brown shoes", price: { amount: 254, currency: "USD"}} rather than just a scalar value like $2.54) a spreadsheet can be a lot more powerful.
Take a look at http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.113.... . Object databases, XML databases and network databases were around long before relational databases. The key problem the relational databases solved is not having to bake the access paths into your data-structure.
With a sufficiently rich type system (with composites and sets as domains), there's not a lot of difference when you are talking about pure data (instead of how the data structure relates to behavior) between tuples and objects.
What domain-specific editors are you planning to include in public release? Something for UI construction on the web?
Is it planned that users of Eve will routinely construct new or modify existing domain-specific editors to the task at hand?
Since first focus of Eve is on web apps (and it's hosted on javascript, correct?), will it cover both client and server applications?
Will there be an FFI?
If I remember correctly, you're planning to use datalog+time+constraints and plan to use materialized views extensively, is it so? Will ability to work with changes as a stream and aggregate over them in more interesting ways than "the last always wins" be builtin in Eve?
Have you tried to show a prototype to children and how do they respond in learning such system if so? What was the reaction of academic friends who were not too familiar with standard forms of programming (like you did with the first prototype of Aurora)?
If I'll ask more questions will it be all right and not too much trouble? :)
Is it planned that users of Eve will routinely construct new or modify existing domain-specific editors to the task at hand?
Since first focus of Eve is on web apps (and it's hosted on javascript, correct?), will it cover both client and server applications?
Will there be an FFI?
If I remember correctly, you're planning to use datalog+time+constraints and plan to use materialized views extensively, is it so? Will ability to work with changes as a stream and aggregate over them in more interesting ways than "the last always wins" be builtin in Eve?
Have you tried to show a prototype to children and how do they respond in learning such system if so? What was the reaction of academic friends who were not too familiar with standard forms of programming (like you did with the first prototype of Aurora)?
If I'll ask more questions will it be all right and not too much trouble? :)
> Is it planned that users of Eve will routinely construct new or modify existing domain-specific editors to the task at hand?
Not sure at this point. For now we are focusing on the core interactions and we'll build out the rest once we've put tools in peoples hands and seen how they work.
> What domain-specific editors are you planning to include in public release? Something for UI construction on the web?
The table, rule and function editors for managing data and logic. A UI editor, hopefully with some constraint-based layout model. Various debugging/tracing/understanding tools.
> Since first focus of Eve is on web apps (and it's hosted on javascript, correct?), will it cover both client and server applications?
It will have to. Not sure yet how that will work. We can do websocket-style stuff at the moment but we will want to provide something simpler on top of that.
> Will there be an FFI?
Yes. You will be able to add new functions / datatypes (like http://www.postgresql.org/docs/9.1/static/xtypes.html), new table/index data-structures (like http://www.postgresql.org/docs/9.1/static/gist-intro.html) and new query-plan/data-flow nodes.
The editor and compiler are mostly written in Eve. The core language is tiny but very extensible - since execution order is not specified explicitly but determined from data-flow you can drop new logic in anywhere to add new compiler optimisations or new editor commands.
The language is also very data-centric - this week I was playing with programs that modify their own code by writing to the ast tables, triggering the incremental compiler to update the dataflow plan.
> If I remember correctly, you're planning to use datalog+time+constraints and plan to use materialized views extensively, is it so? Will ability to work with changes as a stream and aggregate over them in more interesting ways than "the last always wins" be builtin in Eve?
We're still trying out different models of time. The ideal semantic model is append-only, never forget. Implementing that on a real machine needs some restrictions to prevent exploding. Dedalus (http://db.cs.berkeley.edu/papers/datalog2011-dedalus.pdf) attaches epochs to each facts and only allows rules to query the current or last epoch. Edelweiss (http://db.cs.berkeley.edu/papers/vldb14-edelweiss.pdf) allows querying any epoch but uses static analysis to figure out when data can be safely deleted without changing the results.
> Have you tried to show a prototype to children and how do they respond in learning such system if so? What was the reaction of academic friends who were not too familiar with standard forms of programming (like you did with the first prototype of Aurora)?
No children yet. We test things on adult non-programmers regularly. That lead to a couple of surprising changes like getting rid of nesting / scoping (no matter what we did visually, people just couldn't figure it out).
> If I'll ask more questions will it be all right and not too much trouble? :)
Keep 'em coming.
Not sure at this point. For now we are focusing on the core interactions and we'll build out the rest once we've put tools in peoples hands and seen how they work.
> What domain-specific editors are you planning to include in public release? Something for UI construction on the web?
The table, rule and function editors for managing data and logic. A UI editor, hopefully with some constraint-based layout model. Various debugging/tracing/understanding tools.
> Since first focus of Eve is on web apps (and it's hosted on javascript, correct?), will it cover both client and server applications?
It will have to. Not sure yet how that will work. We can do websocket-style stuff at the moment but we will want to provide something simpler on top of that.
> Will there be an FFI?
Yes. You will be able to add new functions / datatypes (like http://www.postgresql.org/docs/9.1/static/xtypes.html), new table/index data-structures (like http://www.postgresql.org/docs/9.1/static/gist-intro.html) and new query-plan/data-flow nodes.
The editor and compiler are mostly written in Eve. The core language is tiny but very extensible - since execution order is not specified explicitly but determined from data-flow you can drop new logic in anywhere to add new compiler optimisations or new editor commands.
The language is also very data-centric - this week I was playing with programs that modify their own code by writing to the ast tables, triggering the incremental compiler to update the dataflow plan.
> If I remember correctly, you're planning to use datalog+time+constraints and plan to use materialized views extensively, is it so? Will ability to work with changes as a stream and aggregate over them in more interesting ways than "the last always wins" be builtin in Eve?
We're still trying out different models of time. The ideal semantic model is append-only, never forget. Implementing that on a real machine needs some restrictions to prevent exploding. Dedalus (http://db.cs.berkeley.edu/papers/datalog2011-dedalus.pdf) attaches epochs to each facts and only allows rules to query the current or last epoch. Edelweiss (http://db.cs.berkeley.edu/papers/vldb14-edelweiss.pdf) allows querying any epoch but uses static analysis to figure out when data can be safely deleted without changing the results.
> Have you tried to show a prototype to children and how do they respond in learning such system if so? What was the reaction of academic friends who were not too familiar with standard forms of programming (like you did with the first prototype of Aurora)?
No children yet. We test things on adult non-programmers regularly. That lead to a couple of surprising changes like getting rid of nesting / scoping (no matter what we did visually, people just couldn't figure it out).
> If I'll ask more questions will it be all right and not too much trouble? :)
Keep 'em coming.
A lot of good news, thank you!
It would be interesting to hear how much of EVE code has it taken to implement compiler or editor. And is there any interesting bottlenecks you would need to optimize out before release?
And how was the experience of writing a lot of EVE code? Do you feel yourself a lot more productive? Have you become accustomed to a new way of writing software very fast and does it feel natural to you now?
Regarding models of time. I'm a bit familiar with Dedalus and I've skimmed over Edelweiss. I'm interested in how would you use Edelweiss in non-distributed settings (I assume Eve is not targeted at that kind of applications right now). Would you try to use it to maintain transactional visibility during re-flows of data across views and afterwards discarding dead data?
I remember you're mentioning datomic in a podcast, so I think you'd want to keep dead data at least for some time, to have an ability to run time-travel queries later. Is this correct?
Would it be possible for developers to control when facts should be garbage collected? For example, CORFU log (which is a good implementation of event log abstraction with flexible views above it) allows clients to control trimming http://muratbuffalo.blogspot.ru/2014/09/paper-summary-tango-... (also I've had a good experience implementing underneath a similar interface for a queue system, it lead to a similar range compression optimization as in Edelweiss).
All the details you've already mentioned make me dream at night wishing a sooner release of Eve to experiment with it. I hope your next answers won't make me kidnap you and beg for an earlier access :)
It would be interesting to hear how much of EVE code has it taken to implement compiler or editor. And is there any interesting bottlenecks you would need to optimize out before release?
And how was the experience of writing a lot of EVE code? Do you feel yourself a lot more productive? Have you become accustomed to a new way of writing software very fast and does it feel natural to you now?
Regarding models of time. I'm a bit familiar with Dedalus and I've skimmed over Edelweiss. I'm interested in how would you use Edelweiss in non-distributed settings (I assume Eve is not targeted at that kind of applications right now). Would you try to use it to maintain transactional visibility during re-flows of data across views and afterwards discarding dead data?
I remember you're mentioning datomic in a podcast, so I think you'd want to keep dead data at least for some time, to have an ability to run time-travel queries later. Is this correct?
Would it be possible for developers to control when facts should be garbage collected? For example, CORFU log (which is a good implementation of event log abstraction with flexible views above it) allows clients to control trimming http://muratbuffalo.blogspot.ru/2014/09/paper-summary-tango-... (also I've had a good experience implementing underneath a similar interface for a queue system, it lead to a similar range compression optimization as in Edelweiss).
All the details you've already mentioned make me dream at night wishing a sooner release of Eve to experiment with it. I hope your next answers won't make me kidnap you and beg for an earlier access :)
> It would be interesting to hear how much of EVE code has it taken to implement compiler or editor.
The current iteration of the editor is 350 lines of our text-based Eve dsl plus 450 lines of helper js which will eventually become our UI and IO libraries.
Stratification is about 30 lines. There used to be more going on in the compiler but now that we use a constraint solver for all the query plans there isn't much left for it to do. http://p2.berkeley.intel-research.net/papers/EvitaRacedVLDB2... has some interesting ideas that we will be exploring later.
> And is there any interesting bottlenecks you would need to optimize out before release?
We've managed to get pretty surprisingly far with really dumb code. We are halfway through a big rewrite so the current build of the editor is using a runtime that is missing half of it's features. Each table is stored in a big array, we do sequential scans for constraint propagation, the incremental evaluation has not been ported yet and we don't have any Edelweiss gc. It can still recalculate and rerender in 20-40ms. That's too slow for fluid animation but plenty fast enough button clicks etc.
The lesson here is that computers are really fast and we squander most of that speed on unnecessary runtime abstraction. I'm pretty excited to see how fast it will get when we have real indexes and incremental evaluation.
> And how was the experience of writing a lot of EVE code? Do you feel yourself a lot more productive? Have you become accustomed to a new way of writing software very fast and does it feel natural to you now?
There are ups and downs.
The main upside I've noticed is how much time I normally have to spend worrying about where to put data, how to access data, how to keep data consistent and what order to do things in. In Eve you just put it in a table and let the runtime worry about the rest. I feel like I now spend a lot more time thinking about the actual problem instead of shepherding data around.
The main problem we're wrestling with at the moment is identity. Since the editor is built in the Edelweiss style as a pure function of the input events, we have to be able to generate stable, unique ids for anything that has a continuous identity. In the Bloom model we could just generate a random UUID and store it. At the moment we build ids by mashing together strings but I feel like the language should be helping us out here.
There are also a whole bunch of problems that come down to immaturity. We don't have a debugger yet so we rely on console dumps a lot. The compiler doesn't have much error checking so bugs in the editor tend to percolate a long way before surfacing symptoms. Implementing integrity constraints is pretty high up on my todo list right now.
> I'm interested in how would you use Edelweiss in non-distributed settings (I assume Eve is not targeted at that kind of applications right now).
There is a section in Out Of The Tarpit where the author argues that the ideal way to specify an application is as a purely functional view over all the inputs it has ever received. He then concedes that in practice you are forced to throw things away to avoid running out of memory. Reading the Edelweiss paper convinced me that we could program as if we were living in Mosely's ideal world and then separately specify a garbage collection strategy. It's just another instance of separating specification from optimisation which I believe is key to managing complexity.
This is probably the most risky part of our plan but we can always fall back to the Bloom model instead. The actual language implementation doesn't really vary between them.
The current iteration of the editor is 350 lines of our text-based Eve dsl plus 450 lines of helper js which will eventually become our UI and IO libraries.
Stratification is about 30 lines. There used to be more going on in the compiler but now that we use a constraint solver for all the query plans there isn't much left for it to do. http://p2.berkeley.intel-research.net/papers/EvitaRacedVLDB2... has some interesting ideas that we will be exploring later.
> And is there any interesting bottlenecks you would need to optimize out before release?
We've managed to get pretty surprisingly far with really dumb code. We are halfway through a big rewrite so the current build of the editor is using a runtime that is missing half of it's features. Each table is stored in a big array, we do sequential scans for constraint propagation, the incremental evaluation has not been ported yet and we don't have any Edelweiss gc. It can still recalculate and rerender in 20-40ms. That's too slow for fluid animation but plenty fast enough button clicks etc.
The lesson here is that computers are really fast and we squander most of that speed on unnecessary runtime abstraction. I'm pretty excited to see how fast it will get when we have real indexes and incremental evaluation.
> And how was the experience of writing a lot of EVE code? Do you feel yourself a lot more productive? Have you become accustomed to a new way of writing software very fast and does it feel natural to you now?
There are ups and downs.
The main upside I've noticed is how much time I normally have to spend worrying about where to put data, how to access data, how to keep data consistent and what order to do things in. In Eve you just put it in a table and let the runtime worry about the rest. I feel like I now spend a lot more time thinking about the actual problem instead of shepherding data around.
The main problem we're wrestling with at the moment is identity. Since the editor is built in the Edelweiss style as a pure function of the input events, we have to be able to generate stable, unique ids for anything that has a continuous identity. In the Bloom model we could just generate a random UUID and store it. At the moment we build ids by mashing together strings but I feel like the language should be helping us out here.
There are also a whole bunch of problems that come down to immaturity. We don't have a debugger yet so we rely on console dumps a lot. The compiler doesn't have much error checking so bugs in the editor tend to percolate a long way before surfacing symptoms. Implementing integrity constraints is pretty high up on my todo list right now.
> I'm interested in how would you use Edelweiss in non-distributed settings (I assume Eve is not targeted at that kind of applications right now).
There is a section in Out Of The Tarpit where the author argues that the ideal way to specify an application is as a purely functional view over all the inputs it has ever received. He then concedes that in practice you are forced to throw things away to avoid running out of memory. Reading the Edelweiss paper convinced me that we could program as if we were living in Mosely's ideal world and then separately specify a garbage collection strategy. It's just another instance of separating specification from optimisation which I believe is key to managing complexity.
This is probably the most risky part of our plan but we can always fall back to the Bloom model instead. The actual language implementation doesn't really vary between them.
I find the details you are giving here interesting, and quite promising.
> That lead to a couple of surprising changes like getting rid of nesting / scoping (no matter what we did visually, people just couldn't figure it out).
I worry about that -- I can see where its probably a huge gain for initial usability but my concern with it is that it shows signs of one of the big problems with spreadsheets in that they make it easy for non-programmers to start with something, and add complexity to it until not only they can't maintain it, but calling in a professional programmer doesn't make it maintainable either, and you essentially need to do a ground-up reanalysis and rewrite to get it into a state where it is maintainable with the complexity it has grown to.
> That lead to a couple of surprising changes like getting rid of nesting / scoping (no matter what we did visually, people just couldn't figure it out).
I worry about that -- I can see where its probably a huge gain for initial usability but my concern with it is that it shows signs of one of the big problems with spreadsheets in that they make it easy for non-programmers to start with something, and add complexity to it until not only they can't maintain it, but calling in a professional programmer doesn't make it maintainable either, and you essentially need to do a ground-up reanalysis and rewrite to get it into a state where it is maintainable with the complexity it has grown to.
Scoping is basically a way of mapping human-readable names to uniquely addressed code objects. When I say "foo" the compiler walks up the lexical scope until it finds a declaration for a variable called "foo" and replaces the human-readable name with the corresponding unique id.
Instead of having a set of rules to map the human-readable names, we generate unique ids for everything at edit time and tag them with the human-readable name. So when you type "foo", you get an intelligently sorted auto-complete box asking you which foo you mean.
This is one of the advantages of not directly editing the program text - we can insert all kinds of useful metadata directly into the AST.
> ...they make it easy for non-programmers to start with something, and add complexity to it until not only they can't maintain it...
Like most things, the problem can't be solved with technology alone. We can improve the tools to make it easier to organise code and to make it easier to understand other peoples code but we will also have to find ways to scale up the teaching aspect. It's the 'pit of success' - we have to design the experience so that people naturally end up doing the right thing. That includes building a community where people learn from each other and are exposed to better ways of structuring their thoughts.
Instead of having a set of rules to map the human-readable names, we generate unique ids for everything at edit time and tag them with the human-readable name. So when you type "foo", you get an intelligently sorted auto-complete box asking you which foo you mean.
This is one of the advantages of not directly editing the program text - we can insert all kinds of useful metadata directly into the AST.
> ...they make it easy for non-programmers to start with something, and add complexity to it until not only they can't maintain it...
Like most things, the problem can't be solved with technology alone. We can improve the tools to make it easier to organise code and to make it easier to understand other peoples code but we will also have to find ways to scale up the teaching aspect. It's the 'pit of success' - we have to design the experience so that people naturally end up doing the right thing. That includes building a community where people learn from each other and are exposed to better ways of structuring their thoughts.
> Instead of having a set of rules to map the human-readable names, we generate unique ids for everything at edit time and tag them with the human-readable name. So when you type "foo", you get an intelligently sorted auto-complete box asking you which foo you mean.
> This is one of the advantages of not directly editing the program text - we can insert all kinds of useful metadata directly into the AST.
I suppose I'll have to see how it works when there is something available to poke on, but that description doesn't allay my concern about it making a programming environment that makes writing easy, but reviewing, understanding, and maintaining previously-written programs hard in much the way that spreadsheets do.
If the information needed to disambiguate references is buried behind the scenes and not readily apparent in the primary interfaced used for editing, that seems problematic.
> This is one of the advantages of not directly editing the program text - we can insert all kinds of useful metadata directly into the AST.
I suppose I'll have to see how it works when there is something available to poke on, but that description doesn't allay my concern about it making a programming environment that makes writing easy, but reviewing, understanding, and maintaining previously-written programs hard in much the way that spreadsheets do.
If the information needed to disambiguate references is buried behind the scenes and not readily apparent in the primary interfaced used for editing, that seems problematic.
There is also much less stuff to disambiguate. The only names you ever refer to at the moment are tables. Most databases get by just fine with no namespacing at all.
As Jonathan Edwards says in his subtext work "names are too valuable to waste on talking to compilers." Making naming more of an interface concern rather than a part of the language is a great IDE and can greatly complement the way we use lots of search to write programs anyhow.
> Most databases get by just fine with no namespacing at all.
True, but most databases are very limited components of the program(s) that use them, which do use namespacing, not the complete platform for the program.
True, but most databases are very limited components of the program(s) that use them, which do use namespacing, not the complete platform for the program.
We also get to have arbitrary names rather than trying to stuff everything into single word. "People who disagree with me on the internet" is a valid name for an Eve table.
It's a valid name, albeit on that requires quoting, in pretty much any SQL based database, too. A lot of organizations have coding standards that prohibit names requiring quotes, and/or long names, but most databases support them just fine.
That said, I'm quite interested in getting a hold of eve.
That said, I'm quite interested in getting a hold of eve.
Liked what I saw with Juno[1] (Julia IDE based on Light Table) and hope sometime after the big Eve reveal next year that Juno can easily migrate. The Juno team clearly felt that Light Table was one of the better and more extensible IDE platforms for Julia to work within.
Best of luck.
[1] http://junolab.org/
Best of luck.
[1] http://junolab.org/
Juno is fantastic and we'll help them do whatever we can with LT.
This is as good a place as any to ask, but why aren't you piggybacking on the work that's being done in the Clojure community on these issues?
I'm working on something similar but much more constrained myself [1], but initiatives like Brandom Bloom's EClj and Reid McKenzy's KISS are already on their way to building the foundation for what you need with Eve but within the Clojure format/community.
Taking that route would also give you a natural path to keep LightTable alive and going and eventually get it bootstrapping/self-hosting.
[1] https://speakerdeck.com/mtrimpe/graphel-the-meaning-of-an-im...
I'm working on something similar but much more constrained myself [1], but initiatives like Brandom Bloom's EClj and Reid McKenzy's KISS are already on their way to building the foundation for what you need with Eve but within the Clojure format/community.
Taking that route would also give you a natural path to keep LightTable alive and going and eventually get it bootstrapping/self-hosting.
[1] https://speakerdeck.com/mtrimpe/graphel-the-meaning-of-an-im...
Programming suffers heavily from path dependencies. There are lots of suboptimal things that we are stuck with because of all the other suboptimal things. We are trying for a clean break.
As a non-programmer, business/marketing guy who fuddles around code when needed - this makes me super excited.
[deleted]
Chris: I've been following your work since I backed LightTable on Kickstarter. I just want to say congratulations and keep on truckin'.
I've been programming professionally for about three years. When I got my first job, I spent days setting up ruby/rails/zsh/vim/git. I was seriously dumbfounded. I could not believe that programmers (in 2011) actually worked this way. And I was even more perplexed that the main tools for reasoning about my code were print statements, browser reloading, and unit tests (so, so many unit tests). This is "the pain we forgot", except it's recent enough that I've never forgotten it.
Thanks for your work. I'm looking forward to a better programming for my kids. And hope to support any way I can.
I've been programming professionally for about three years. When I got my first job, I spent days setting up ruby/rails/zsh/vim/git. I was seriously dumbfounded. I could not believe that programmers (in 2011) actually worked this way. And I was even more perplexed that the main tools for reasoning about my code were print statements, browser reloading, and unit tests (so, so many unit tests). This is "the pain we forgot", except it's recent enough that I've never forgotten it.
Thanks for your work. I'm looking forward to a better programming for my kids. And hope to support any way I can.
I prefer not to think of unit tests as a write to reason about the code you're writing now, but to let the system confirm that your current reasoning doesn't contradict with your previous reasoning (about other parts of the code).
For ruby, there's Pry [0].
[0]: http://pryrepl.org/
[0]: http://pryrepl.org/
I really do hope these guys are able to accomplish their goal, but I remain skeptical. We've seen efforts from folks like Google and MIT down to small companies trying to solve this "problem", when it seems to me that the underlying reality is simply that software is hard. Layer abstractions over it if you must, but at the end of the day those will only get the layperson over the hump of trivial problems, leaving one disillusioned when the tool is unable to realize loftier goals.
I agree, there is a considerable risk they have traded in a less interesting problem they could solve very well (IDE), for more interesting challenge that they will end up not getting to market with (programming tools for "the rest of us"). I think this is the nature of VC investment, though. The money is there to chase risky things.
As a fairly new (4 years) programmer with an avid interest in comparative language features and tooling, this looks like the direction that every cool new thing I've read about or attempted to create myself seems to be going. The LISPers have always been there, preaching freedom from syntax and a focus on semantics, but it has never made it into a readable form for your average new aspiring programmer.
I keep thinking what we need is for the structure of programs to be something saner than the one-dimensional byte stream that we keep pretending programs aren't by splitting them into lines, functions, classes, and files. Tables aren't fundamentally different than those other constructs, in the same sense that programming languages aren't fundamentally different from each other - BF is Turing complete and all that. But usability and learning curve, as someone said on here, really matter, and tables have a far more clean and rigid structure than a mess of braces.
The most difficult problems in programming aren't the low level algorithms, they're the social problems along the lines of how do you involve large numbers of new programmers in a project without ruining it, or how do you empower users to create their own features without starting over and building a custom rules engine?
I keep thinking what we need is for the structure of programs to be something saner than the one-dimensional byte stream that we keep pretending programs aren't by splitting them into lines, functions, classes, and files. Tables aren't fundamentally different than those other constructs, in the same sense that programming languages aren't fundamentally different from each other - BF is Turing complete and all that. But usability and learning curve, as someone said on here, really matter, and tables have a far more clean and rigid structure than a mess of braces.
The most difficult problems in programming aren't the low level algorithms, they're the social problems along the lines of how do you involve large numbers of new programmers in a project without ruining it, or how do you empower users to create their own features without starting over and building a custom rules engine?
I'll be excited when I see it.
Light Table was announced to change the way we're writing code, too. But the execution didn't quite match the vision.
Light Table was announced to change the way we're writing code, too. But the execution didn't quite match the vision.
There is a temptation to think that programming isn't that hard, that somehow we just need lighter shoes and we'll run a four minute mile. I look forward to a better spreadsheet, but I don't think it will revolutionize programming. Just tackling the spreadsheet though is a big enough, worthy enough, and valuable enough goal, I hope they succeed.
In the continuum of programming tasks, tasks best for spreadsheets are pretty far down the scale. But these tasks are very common and an improved tool could have a very big impact.
After grad school I did real time process control programming for semiconductor manufacturing. Complex machines, which couldn't be slowed down, were programmed in assembly language and had many simultaneously moving parts, all under the control of software. Programming, done in assembly language, was a mess. It was hard, very hard, we had to build all of our own tools, including the operating system that ran on the minicomputer running our software. The mechanical engineers were very talented and built amazing machines, but they thought that the understood the "hardware" so they should be the ones to write the software to run it. Of course, this didn't work out at all. It's easy to believe that programming shouldn't be that hard.
Computation can be intrinsically difficult in ways that new tools don't help. Consider a simple problem like suffling a deck of cards. Having a tool that makes a shuffle easy to code doesn't make it a fair or efficient shuffle. On the otherhand, most students of Computer Science would know the pitfalls of shuffling by the time they got through a couple of years of grad school. One can't expect that even intelligent people will understand that the a fair shuffle has to pick one of the exactly N! possible shuffles with uniform probability and that the following loop doesn't do it (for a number of reasons):
In the continuum of programming tasks, tasks best for spreadsheets are pretty far down the scale. But these tasks are very common and an improved tool could have a very big impact.
After grad school I did real time process control programming for semiconductor manufacturing. Complex machines, which couldn't be slowed down, were programmed in assembly language and had many simultaneously moving parts, all under the control of software. Programming, done in assembly language, was a mess. It was hard, very hard, we had to build all of our own tools, including the operating system that ran on the minicomputer running our software. The mechanical engineers were very talented and built amazing machines, but they thought that the understood the "hardware" so they should be the ones to write the software to run it. Of course, this didn't work out at all. It's easy to believe that programming shouldn't be that hard.
Computation can be intrinsically difficult in ways that new tools don't help. Consider a simple problem like suffling a deck of cards. Having a tool that makes a shuffle easy to code doesn't make it a fair or efficient shuffle. On the otherhand, most students of Computer Science would know the pitfalls of shuffling by the time they got through a couple of years of grad school. One can't expect that even intelligent people will understand that the a fair shuffle has to pick one of the exactly N! possible shuffles with uniform probability and that the following loop doesn't do it (for a number of reasons):
(* Randomly rearrange each card *)
for ctr := 1 to 52 do begin
random_number := random(51)+1;
tmp := card[random_number];
card[random_number] := card[ctr];
card[ctr] := tmp;
end;> I look forward to a better spreadsheet, but I don't think it will revolutionize programming.
If you look at the research papers they cite, its not so much that they are aiming at a better spreadsheet which will , as a side effect, revolutionize programming, but a better programming model than those currently deployed which will, as a side effect, revolutionize spreadsheets.
My initial post was highly skeptical, and I still think that there's an uphill battle here. But I think that they have a good foundation to build a tool that both eases and empowers "casual programming" (including the kind of things that would be done in spreadsheets and that people don't and won't think of as programming) and empowers professional programmers to focus on the hard part of professional programming.
That said, its far from the first improvement of this general description that's been tried -- even with a good foundation -- and while I think its by far the best foundation I've seen for it, most of the key application domain areas have "good enough" solutions that its going to be hard to get people out of. (I am increasingly convinced that the initial casual-programmer web app focus makes sense, though, because while there's lots of established incumbents in that space, there's no dominant player to displace, so while it will may take a lot of polish to get decent uptake there, its an easier fight than going straight for Excel out the gate, and better reach than focussing on pro programmers as the initial focal market.)
If you look at the research papers they cite, its not so much that they are aiming at a better spreadsheet which will , as a side effect, revolutionize programming, but a better programming model than those currently deployed which will, as a side effect, revolutionize spreadsheets.
My initial post was highly skeptical, and I still think that there's an uphill battle here. But I think that they have a good foundation to build a tool that both eases and empowers "casual programming" (including the kind of things that would be done in spreadsheets and that people don't and won't think of as programming) and empowers professional programmers to focus on the hard part of professional programming.
That said, its far from the first improvement of this general description that's been tried -- even with a good foundation -- and while I think its by far the best foundation I've seen for it, most of the key application domain areas have "good enough" solutions that its going to be hard to get people out of. (I am increasingly convinced that the initial casual-programmer web app focus makes sense, though, because while there's lots of established incumbents in that space, there's no dominant player to displace, so while it will may take a lot of polish to get decent uptake there, its an easier fight than going straight for Excel out the gate, and better reach than focussing on pro programmers as the initial focal market.)
It seems like the hard part of programming is and always will be the problem solving part, and not the syntax memorization / environment setup. Business leaders, at least where I work, are not programming due to the fact that they just don't think computationally, not that they have to fiddle around with a DB connector.
I'm curious about the target audience and the drive to make programming "easier". Sure--the tools can help, but it doesn't necessarily help a user solve the problem correctly. Is the audience programmers? Is it for replacing programmers with software power users? Or am I totally missing the point, that this is a totally new way of solving problems in a language agnostic way?
I'm curious about the target audience and the drive to make programming "easier". Sure--the tools can help, but it doesn't necessarily help a user solve the problem correctly. Is the audience programmers? Is it for replacing programmers with software power users? Or am I totally missing the point, that this is a totally new way of solving problems in a language agnostic way?
The goal of getting programming into everyone's hands seems totally misguided. Not everyone is cut out for computer programming. Just like not everyone is cut out to be a doctor or a pilot or a farmer.
Sure, not everyone is cut out for programming. But there's still a fair amount of incidential complexity we can eliminate, which will make programming more approachable to more of the people who would be good at it.
Lockharts Lament (https://www.maa.org/external_archive/devlin/LockhartsLament....) applies equally well to programming. People in general are smarter and more adaptable than HN seems to believe. The real obstacles to more widespread programming are a) showing people that it can make their lives easier and b) smoothing the learning curve so that it provides rewards before their patience runs out. We know this because many people do build amazingly complex systems with Excel and Access and VB6. They are clearly capable of computational thinking. They just don't have the time or inclination to invest thousands of hours into learning bash/emacs/python/js/html/css before seeing any results.
I think the main goal of eve is precisely to help people "think computationally". Part of that is finding a better fundamental model than imperative programming. The other part is removing incidental complexity (DB connectors, etc). If you dismiss either part you'll get exactly what we've been getting for the past 40 years: micro-optimizations.
But, I agree with you, the former-- changing the fundamental computation model-- is the more exciting (and harder) of the two.
But, I agree with you, the former-- changing the fundamental computation model-- is the more exciting (and harder) of the two.
One can imagine a tremendous number of useful applications something like EVE would enable. Working in a top notch cancer research lab, I can think of several instances where an exceptionally talented lab biologist needs some computational work done but doesn't have the slightest idea of how to get started. Hopefully, EVE will bring down some of those barriers and change this. This is exciting.
Chris, so you found some of Prof. Harel's work interesting?
https://news.ycombinator.com/item?id=7489865
Or did you arrive at a use case for temporal logic from another avenue?
Congratulations, by the way, eve sounds exciting!
https://news.ycombinator.com/item?id=7489865
Or did you arrive at a use case for temporal logic from another avenue?
Congratulations, by the way, eve sounds exciting!
At some point, somebody will succeed in some real fashion with a tool that allows non-programmers to make software (for real, not baby software). And after that I'll just go live in the woods, I guess. The cost of my labor will go from a lot to basically zero.
Still, even though their goal (and the goal of similar projects) is my obsolescence, I wish them luck. It will probably be a massive overall good. But it's also a reason why I think all the current frenetic activity about teaching more people to program will end up being the wrong thing.
Still, even though their goal (and the goal of similar projects) is my obsolescence, I wish them luck. It will probably be a massive overall good. But it's also a reason why I think all the current frenetic activity about teaching more people to program will end up being the wrong thing.
> somebody will succeed in some real fashion with a tool that allows non-programmers to make software (for real, not baby software)
I'll bet this won't happen. If you can get non-programmers to produce what we think of as real software now, I am sure whatever insight you made will make programmers create much better, more complicated software.
See also, http://en.wikipedia.org/wiki/Jevons_paradox
I'll bet this won't happen. If you can get non-programmers to produce what we think of as real software now, I am sure whatever insight you made will make programmers create much better, more complicated software.
See also, http://en.wikipedia.org/wiki/Jevons_paradox
I am not totally sure it can or will really happen. I'm just a garden-variety pessimist.
Everyone can write but there are still professional writers. There is a difference between being good enough to get at work and good enough that thousands of people read and enjoy your work.
Similarly, basic computational literacy should include being able to knock together a simple CRUD app or running a simulation. That doesn't mean that Joe Plumber is going to be building complex distributed systems any time soon. It will certainly ease the interface between professional programmers and users though. Rather than having to provide complete appliances where every possible user action is accounted and coded for ahead of time, you can just supply tools that the user applies however they like.
The Unity marketplace looks a bit like this. It turns out there are lots of people who have the desire to make a game and enough skills to handle basic scripting but not enough to build their own physics engine. In the marketplace you can buy level editors, animation engines, pathfinding algorithms etc and glue them together.
Similarly, basic computational literacy should include being able to knock together a simple CRUD app or running a simulation. That doesn't mean that Joe Plumber is going to be building complex distributed systems any time soon. It will certainly ease the interface between professional programmers and users though. Rather than having to provide complete appliances where every possible user action is accounted and coded for ahead of time, you can just supply tools that the user applies however they like.
The Unity marketplace looks a bit like this. It turns out there are lots of people who have the desire to make a game and enough skills to handle basic scripting but not enough to build their own physics engine. In the marketplace you can buy level editors, animation engines, pathfinding algorithms etc and glue them together.
Don't give up just yet. They might take away some of the work in the solution but the world will still need people who can think about the problem. Most people can't do that.
I am sure they will do much better than MS Access. But still, years ago I had to work on a couple of projects where the spec was some system in Access that the domain experts had coded up. What a mess! - Really, you have no idea. They eventually could not fix the bugs themselves which was why the new system was being written. So there will always be room for people who can organise and abstract things.
I am sure they will do much better than MS Access. But still, years ago I had to work on a couple of projects where the spec was some system in Access that the domain experts had coded up. What a mess! - Really, you have no idea. They eventually could not fix the bugs themselves which was why the new system was being written. So there will always be room for people who can organise and abstract things.
True, people can "do stuff" but one must really understand what's going on to analyze and fix problems. Maybe we'll all have jobs un-screwing the terrible messes people make with their visual tools :)
Interesting move. I've just read Peter Thiel's startup notes, and one point he's adamant about is to build your product as a monopoly for a small market (this is in no way new advice, but since I just finished his book his formulation is the most recent one in my head). E.g. Facebook and Harvard students, AirBnB and housing for conferences, etc. If you can't get to mass adoption in a small niche, how are you going to scale it up? Additionally, your product has to be at least an order of magnitude better than what the niche already uses (e.g. Facebook was an order of magnitude better than Harvard's static face book).
I have a hard time seeing what small niche Eve will dominate, and how it's at least 10x better than any existing solution. Looking at the examples they give:
> a scientist doesn’t have to rely on the one person in the lab who knows python
Scientist these days pretty much have to pick up a programming language (Python, R, Matlab, etc.) throughout their undergrad/early grad studies. If you're going to target that niche, not only are you fighting against the huge investment professors and labs have made in existing tools (along with the small libraries/frameworks they built themselves), but you also have to provide an equivalent quality ecosystem for the weird data formats some very specific niches use, for the lab equipment, and so on. If you wanted to deliver a 10x improvement on the existing state of computation in research labs, you'd have to spend a lot of time focusing on exclusively that.
> a child could come up with an idea for a game and build it in a couple of weekends
They already can, using Scratch or the myriad similar tools available which will probably remain better because they were designed with game design in mind.
> your computer can help you organize and plan your wedding/vacation/business.
People already use MS Office, Google Docs, etc. for these tasks. Unless Eve brings a 10x improvement to those tools, how can they ever hope to displace them? My dad has been using the same version of Excel for the past 10 years, I have a hard time imagining people like him switching over.
In his lectures, Peter Thiel spends some time talking about all the solar startups that emerged more or less at the same time in the late 2000s, only to fail miserably. While the buzz and excitement for solar power companies was there, in reality they could not deliver on what startups need to deliver to thrive: a product solving a real problem for a niche market that's at least 10x better than the existing solution in place. I feel like we're in a similar space with all those "learn to code" and "new programming tools" companies that have been steadily emerging.
No doubt, the CS academic and HCI researcher that I am is excited by Eve- I'm sure they've done their research and that it would be a really neat product. The entrepreneur in me is however extremely doubtful.
I have a hard time seeing what small niche Eve will dominate, and how it's at least 10x better than any existing solution. Looking at the examples they give:
> a scientist doesn’t have to rely on the one person in the lab who knows python
Scientist these days pretty much have to pick up a programming language (Python, R, Matlab, etc.) throughout their undergrad/early grad studies. If you're going to target that niche, not only are you fighting against the huge investment professors and labs have made in existing tools (along with the small libraries/frameworks they built themselves), but you also have to provide an equivalent quality ecosystem for the weird data formats some very specific niches use, for the lab equipment, and so on. If you wanted to deliver a 10x improvement on the existing state of computation in research labs, you'd have to spend a lot of time focusing on exclusively that.
> a child could come up with an idea for a game and build it in a couple of weekends
They already can, using Scratch or the myriad similar tools available which will probably remain better because they were designed with game design in mind.
> your computer can help you organize and plan your wedding/vacation/business.
People already use MS Office, Google Docs, etc. for these tasks. Unless Eve brings a 10x improvement to those tools, how can they ever hope to displace them? My dad has been using the same version of Excel for the past 10 years, I have a hard time imagining people like him switching over.
In his lectures, Peter Thiel spends some time talking about all the solar startups that emerged more or less at the same time in the late 2000s, only to fail miserably. While the buzz and excitement for solar power companies was there, in reality they could not deliver on what startups need to deliver to thrive: a product solving a real problem for a niche market that's at least 10x better than the existing solution in place. I feel like we're in a similar space with all those "learn to code" and "new programming tools" companies that have been steadily emerging.
No doubt, the CS academic and HCI researcher that I am is excited by Eve- I'm sure they've done their research and that it would be a really neat product. The entrepreneur in me is however extremely doubtful.
Our first bastion is websites, you can think of it as filling in the gap that Microsoft left when they killed VB6. 15 or so years ago, someone could open up VB6 draw out a couple of forms and put together a simple "Line of Business" app themselves without having spent 10 years of their life becoming a professional programmer. The modern VB6 would do the same for websites. :)
> Unless Eve brings a 10x improvement to those tools
We know the bar is pretty universally an order of magnitude and so we've planned accordingly. Our primary target here is selling a super power: you couldn't do this at all before, and now you can. Joe in accounting doesn't have the opportunity to build things to support himself (short of studying programming), but with Eve he could do everything from automate several of his workflows, to building a dashboard, to building dynamic reports for his bosses, to creating internal tools to track and measure things.
There is a fairly clear gap in our ecosystem around these kinds of programs and they represent what I would argue is the vast majority of programs that should be written, but aren't because of the cost.
There's also the opportunity to just make websites an order of magnitude easier to build for programmers and we're getting there. I was able to write an entire editor for this thing in itself in a week for one of our prototypes - there's some real potential there.
> Unless Eve brings a 10x improvement to those tools
We know the bar is pretty universally an order of magnitude and so we've planned accordingly. Our primary target here is selling a super power: you couldn't do this at all before, and now you can. Joe in accounting doesn't have the opportunity to build things to support himself (short of studying programming), but with Eve he could do everything from automate several of his workflows, to building a dashboard, to building dynamic reports for his bosses, to creating internal tools to track and measure things.
There is a fairly clear gap in our ecosystem around these kinds of programs and they represent what I would argue is the vast majority of programs that should be written, but aren't because of the cost.
There's also the opportunity to just make websites an order of magnitude easier to build for programmers and we're getting there. I was able to write an entire editor for this thing in itself in a week for one of our prototypes - there's some real potential there.
> 15 or so years ago, someone could open up VB6 draw out a couple of forms and put together a simple "Line of Business" app themselves without having spent 10 years of their life becoming a professional programmer.
There's plenty of people throwing together simple LOB apps (including, particularly web apps) now -- with a wide variety of different tools -- without spending a decade becoming a professional programmer. And using similar workflows as they did when VB6 was around. Visual designers with minimal code didn't go away when VB6 did, and the place where there are the most competing ways of doing this is on the web.
> Joe in accounting doesn't have the opportunity to build things to support himself (short of studying programming), but with Eve he could do everything from automate several of his workflows, to building a dashboard, to building dynamic reports for his bosses, to creating internal tools to track and measure things.
That's exactly the pitch for lots of things that are on the market now (to pick one among many, without any particular intention to claim its the best in the field, Zoho Creator).
There's plenty of people throwing together simple LOB apps (including, particularly web apps) now -- with a wide variety of different tools -- without spending a decade becoming a professional programmer. And using similar workflows as they did when VB6 was around. Visual designers with minimal code didn't go away when VB6 did, and the place where there are the most competing ways of doing this is on the web.
> Joe in accounting doesn't have the opportunity to build things to support himself (short of studying programming), but with Eve he could do everything from automate several of his workflows, to building a dashboard, to building dynamic reports for his bosses, to creating internal tools to track and measure things.
That's exactly the pitch for lots of things that are on the market now (to pick one among many, without any particular intention to claim its the best in the field, Zoho Creator).
> Our first bastion is websites, you can think of it as filling in the gap that Microsoft left when they killed VB6.
They've created LightSwitch. LightSwitch is also a great example for the usual outcome of using RAD tools: You often come pretty soon to the point where the provided abstractions are lacking some functionality or performance. The customer / user doesn't care how the software is built, it's compared to the greatest there is.
They've created LightSwitch. LightSwitch is also a great example for the usual outcome of using RAD tools: You often come pretty soon to the point where the provided abstractions are lacking some functionality or performance. The customer / user doesn't care how the software is built, it's compared to the greatest there is.
I think a tool for the web that is as productive as VB and Powebuilder was back in the day, would be a big hit.
ASP.NET Web Forms?
What was the small niche that VisiCalc dominated?
Bricklin was joined by Bob Frankston, and the pair worked on VisiCalc for two months during the winter of 1978–79, forming Software Arts. Bricklin wrote, "[W]ith the years of experience we had at the time we created VisiCalc, we were familiar with many row/column financial programs. In fact, Bob had worked since the 1960s at Interactive Data Corporation, a major timesharing utility that was used for some of them and I was exposed to some at Harvard Business School in one of the classes." Bricklin is referring to the variety of report generators that were in use at that time, including Business Planning Language (BPL) from International Timesharing Corporation (ITS) and Foresight, from Foresight Systems. However, these earlier timesharing programs were not completely interactive, nor did they run on personal computers.
http://en.wikipedia.org/wiki/VisiCalc
http://en.wikipedia.org/wiki/VisiCalc
Microcomputer users.
I have high hopes for this area. There are a huge amount of ad-hoc problems that are today solved most easily by throwing together an Excel file, even for a very competent programmer. There is currently no faster way to manipulate and do small scale programming on data. For decision analysis and modeling, you go straight from excel to a full-blown program, without any other compelling options.
A product with some interesting ideas in this area is Calca: http://calca.io/
A product with some interesting ideas in this area is Calca: http://calca.io/
I am a bit disappointed about Light Table, though it was obviously coming.
Good luck with Eve. I am sure you have read it already, but the paper "Out Of The Tar Pit" by Ben Moseley and Peter Marks might be of interest.
http://shaffner.us/cs/papers/tarpit.pdf
The first half is pretty dry. Around Section 7 they get into describing a non-standard way to look at application design. Their language design ideas might fit well with the goals of Eve.
Good luck with Eve. I am sure you have read it already, but the paper "Out Of The Tar Pit" by Ben Moseley and Peter Marks might be of interest.
http://shaffner.us/cs/papers/tarpit.pdf
The first half is pretty dry. Around Section 7 they get into describing a non-standard way to look at application design. Their language design ideas might fit well with the goals of Eve.
A lot of our overarching design is based on things they laid out in Out of the Tar Pit :)
hehe, cool. I thought the separation of concerns sounded familiar.
I expect Eve will have an open architecture? So that those of us that like to plumb the depths can play too.
Most of these "programming for the masses" projects inadvertently throw up road blocks to experienced programmers. GUI's where you have to use the mouse and click 10 times to create a function, complicated formats that don't lend well to source control, etc.
With what we saw with Light Table, I am hopeful you will easily sidestep these sorts of issues.
I expect Eve will have an open architecture? So that those of us that like to plumb the depths can play too.
Most of these "programming for the masses" projects inadvertently throw up road blocks to experienced programmers. GUI's where you have to use the mouse and click 10 times to create a function, complicated formats that don't lend well to source control, etc.
With what we saw with Light Table, I am hopeful you will easily sidestep these sorts of issues.
> I expect Eve will have an open architecture? So that those of us that like to plumb the depths can play too.
See https://news.ycombinator.com/item?id=8397747 :)
See https://news.ycombinator.com/item?id=8397747 :)
Anything to do with Aurora ?
https://www.youtube.com/watch?v=L6iUm_Cqx2s
We renamed Aurora to Eve, though it's changed significantly since that video. We found lots of issues with that way of thinking about the world and so worked to find a better model. The name Aurora didn't seem to test very well, but we've found Eve to work rather nicely.
How does Eve compare and relate to similar, older attempts to use spreadsheets as a visual programming metaphor, like Forms/3? ftp://ftp.cs.orst.edu/pub/burnett/ForJFP/JFP.fordistrib.pdf
It seems like the interaction between spreadsheets and programming is an oft-explored area - it will be interesting to see what this evolution brings.
It seems like the interaction between spreadsheets and programming is an oft-explored area - it will be interesting to see what this evolution brings.
* Collection-oriented rather than cell-oriented. Eve is loosely based on datalog which is closer to SQL or prolog than to a spreadsheet. The relational query model is much more powerful than vlookup. I believe we can make it as approachable.
* Networked / multiuser. Excel deals poorly with concurrent access to data and reacting to events. Most of the users we talk to have problems with sharing spreadsheets and moving data through pipelines. We aim to provide a shared database so that one users computations can easily depend on another users data and can respond to changes or new data.
* Web-native. The web is unfortunately the only distribution platform with any reach. That's one of the things that killed VB6.
* Not ugly. It may be shallow, but people don't like to use ugly software and will perceive it as being harder to use (eg http://www.ergonomicsclass.com/wp-content/uploads/2011/11/Tr...)
That said, the forms/3 HCI research is excellent and their recent work on preventing errors (http://eusesconsortium.org/wysiwyt.php) has been especially educational.
* Networked / multiuser. Excel deals poorly with concurrent access to data and reacting to events. Most of the users we talk to have problems with sharing spreadsheets and moving data through pipelines. We aim to provide a shared database so that one users computations can easily depend on another users data and can respond to changes or new data.
* Web-native. The web is unfortunately the only distribution platform with any reach. That's one of the things that killed VB6.
* Not ugly. It may be shallow, but people don't like to use ugly software and will perceive it as being harder to use (eg http://www.ergonomicsclass.com/wp-content/uploads/2011/11/Tr...)
That said, the forms/3 HCI research is excellent and their recent work on preventing errors (http://eusesconsortium.org/wysiwyt.php) has been especially educational.
Thanks for the response. All of these pain points are definitely true, in my experience.
I'm working on a database-backed spreadsheet product too, and it sounds like we have very similar ideas about the weaknesses of the current spreadsheet model.
Our output product is still 'rich' spreadsheets rather than apps, though, and while we have a programmable VM and data processing language our language looks much more Excel than prolog or SQL. We also were really interested in the forms/3 research during our early development which is what prompted me to post.
I'm working on a database-backed spreadsheet product too, and it sounds like we have very similar ideas about the weaknesses of the current spreadsheet model.
Our output product is still 'rich' spreadsheets rather than apps, though, and while we have a programmable VM and data processing language our language looks much more Excel than prolog or SQL. We also were really interested in the forms/3 research during our early development which is what prompted me to post.
I can't help reading 'Eve Online' everytime I read 'Eve'. I guess it's a time-space deformation.
Eve's goal is to completely simplify and reshape computer programming at large? Oh. Well, best of luck to you.
Imagine a world where everyone has access to computation
without having to become a [..] programmer
"...doesn’t have to rely on the one person in the lab who knows python"
I'm a long term Java programmer who recently learned Python. Python is sensational. We should encourage everyone to know a language like Python, not pass it off as the domain of "professional programmers".
I'm a long term Java programmer who recently learned Python. Python is sensational. We should encourage everyone to know a language like Python, not pass it off as the domain of "professional programmers".
I'm a PhD student, and a big Julia fan (and contributor), and I STILL think everyone should know Python (or similar). It truly can be the language for everyone, and I've found it amazingly easy to teach it to people.
Admirably. As there is a lot of money in the table I would like to be paid for dreaming. Nothing is impossible, but at this level pay me beforehand.
A story about the initial introduction of computers to the lab my dad worked at, with no particular concrete conclusion:
My father is a microbiologist. When he started his postdoc at OHSU, they actually had a information artist guy in the department (apologies, I have no idea what the profession's name actually is). When you were writing a paper, you'd go to the graphics office/dept/whatever and give him your data, which he'd then lay out in some huge post board or something, then take a picture of it and shrink it down. Clearly much more time consuming than what Excel can accomplish for you now. I think around that same time they were just starting to get computers installed everywhere. By the time my dad left OHSU a few years later, this person was working in the mail room, his profession no longer existed (or at least wasn't particularly employable anymore). Everyone was now making their own charts, graphs, visualizations or what-have-you using their computers.
I, being a programmer, always thought about this as a success story. Interestingly enough, my dad has a different take on it. His perspective is that he used to be a scientist, now he's a scientist and a shitty artist. The way he sees it, its now his responsibility to learn this myriad of tools (photoshop, illustrator, Canvas hehe), whereas before his sole focus was more so on "the science". I certainly see it on my end, he's much better at Photoshop than I am, and at the same time knows a bit of HTML to get by, etc etc. However the reality isn't that the time to make these graphics has magically dropped to zero, its just that is become simple enough to not justify having an entire art department handling it, but hard enough to be annoying to him. He certainly spends a lot of time being angry at Photoshop now, which seems to be perfectly acceptable for a professional designer, but a strange consequence of being a scientist. Another result is that you now have someone not trained in data visualization trying to express his findings (vs possibly having someone who has a degree in that making suggestions about how to best present it).
Its interesting to try to reconcile these results. Its quite possible that there is no lesson here and its simply a spectrum of trade offs, no perfect scenario. Certainly everyone agrees Microsoft Word is a clear net positive, maybe visualization is just less of a win. Or maybe this is just because we are in an intermediate step, at some point things will be so easy that you 1) don't need a separate department, 2) it takes almost no time and 3) it inspires you to create really good visualizations without having much background in that. Who knows.
On the other hand some people would argue that this is actually displaying a deeper educational problem, where if there was more interdisciplinary teaching, then every scientist would have some grasp of data visualization and then its just a matter of having a better Photoshop. As time goes on I become more and more skeptical of this approach however. It seems strange to "empower" people when you are actually burdening them with additional responsibility. Since you can do everything yourself, it now becomes "your fault" for not being good at everything.
My father is a microbiologist. When he started his postdoc at OHSU, they actually had a information artist guy in the department (apologies, I have no idea what the profession's name actually is). When you were writing a paper, you'd go to the graphics office/dept/whatever and give him your data, which he'd then lay out in some huge post board or something, then take a picture of it and shrink it down. Clearly much more time consuming than what Excel can accomplish for you now. I think around that same time they were just starting to get computers installed everywhere. By the time my dad left OHSU a few years later, this person was working in the mail room, his profession no longer existed (or at least wasn't particularly employable anymore). Everyone was now making their own charts, graphs, visualizations or what-have-you using their computers.
I, being a programmer, always thought about this as a success story. Interestingly enough, my dad has a different take on it. His perspective is that he used to be a scientist, now he's a scientist and a shitty artist. The way he sees it, its now his responsibility to learn this myriad of tools (photoshop, illustrator, Canvas hehe), whereas before his sole focus was more so on "the science". I certainly see it on my end, he's much better at Photoshop than I am, and at the same time knows a bit of HTML to get by, etc etc. However the reality isn't that the time to make these graphics has magically dropped to zero, its just that is become simple enough to not justify having an entire art department handling it, but hard enough to be annoying to him. He certainly spends a lot of time being angry at Photoshop now, which seems to be perfectly acceptable for a professional designer, but a strange consequence of being a scientist. Another result is that you now have someone not trained in data visualization trying to express his findings (vs possibly having someone who has a degree in that making suggestions about how to best present it).
Its interesting to try to reconcile these results. Its quite possible that there is no lesson here and its simply a spectrum of trade offs, no perfect scenario. Certainly everyone agrees Microsoft Word is a clear net positive, maybe visualization is just less of a win. Or maybe this is just because we are in an intermediate step, at some point things will be so easy that you 1) don't need a separate department, 2) it takes almost no time and 3) it inspires you to create really good visualizations without having much background in that. Who knows.
On the other hand some people would argue that this is actually displaying a deeper educational problem, where if there was more interdisciplinary teaching, then every scientist would have some grasp of data visualization and then its just a matter of having a better Photoshop. As time goes on I become more and more skeptical of this approach however. It seems strange to "empower" people when you are actually burdening them with additional responsibility. Since you can do everything yourself, it now becomes "your fault" for not being good at everything.
Well, there is a net benefit of everybody being able to do more things instead of delegating: responsibility.
If I have to do my stuff, I can stop blaming others. This is good for me and for the others. Even if the information artist guy made better visualizations, the people at the lab could blame him for not doing them as they envisioned, and the guy himself could not put the best of his effort on doing things, because they weren't made directly for him, so the blame could would be probably justified.
But, well, it is better to step away from this world of giving responsibility to others and then blaming them, into a world in which everyone do their best and don't blame anyone. Even if the final work is a little worse, it would be acknowledged that it was done by no specialist.
Ok, I don't know exactly what is my argument here, so I'll just stop.
If I have to do my stuff, I can stop blaming others. This is good for me and for the others. Even if the information artist guy made better visualizations, the people at the lab could blame him for not doing them as they envisioned, and the guy himself could not put the best of his effort on doing things, because they weren't made directly for him, so the blame could would be probably justified.
But, well, it is better to step away from this world of giving responsibility to others and then blaming them, into a world in which everyone do their best and don't blame anyone. Even if the final work is a little worse, it would be acknowledged that it was done by no specialist.
Ok, I don't know exactly what is my argument here, so I'll just stop.
Maybe it is more decent for a man to just know how to do everything, and everything that forces him in that direction is a win.
"A human being should be able to change a diaper, plan
an invasion, butcher a hog, conn a ship, design a
building, write a sonnet, balance accounts, build a
wall, set a bone, comfort the dying, take orders, give
orders, cooperate, act alone, solve equations, analyze
a new problem, pitch manure, program a computer, cook
a tasty meal, fight efficiently, die gallantly.
Specialization is for insects."Sometimes, the computer serves merely to ensure a yak in every yard that needs shaving.
Light Table failed because it was overly ambitious. So the response is to start a new, vastly more ambitious project?
"Light Table will continue to go on strong."
Sure.
Sure.
Would you guys be hiring remote workers?
I'm afraid not. I worked remotely for a few months before getting my visa and it was tremendously unproductive. We're dealing with a lot of new and unfamiliar ideas and it's hard enough communicating about them in person in front of a whiteboard, let alone over slack.
Everyone is having all the fun in the other side of the country, and I'm stuck in Disney World missing out. Sad stuff.
I hope Light Table doesn't get essentially abandoned, despite throwing in a final pity paragraph about it not being so. There haven't been any new Light Table updates recently and that's disappointing. It's not unusable as is, but it's lacking that last 20% of refinement and polish and perfect documentation and other things that makes good software into great software.
Looking at Github activity I don't think that this will be the case. You can clearly see that guys are busy with Eve now.
I mean Light Table is a great IDE but it just needs so much done. It feels like 95% complete in every corner. The vim keybindings are buggy, Python plugin lacks proper virtualenv/custom python support, performance is not quite there either... I forget all the issues I encountered back when I used it but there has been very few releases since and it's super concerning to just see what was once an extremely active project slowly go in maintenance mode.
Please, quell my fears. You guys put together an amazing Kickstarter and used to put out so much in terms of updates and feature updates; I don't see that anymore.
With all that said, best of luck with Eve, sounds awesome.
... Edit: I think these graphs are pretty telling. https://github.com/LightTable/LightTable/graphs/code-frequen...