ibdknox

I don't suggest playing with that version much as it's being completely replaced by experimental/cardwiki in the next month.

I sincerely wish there had been a class like this when I was in school. The reading list here has some really fascinating stuff in it, several of which I'd never seen before, many of which are things that have inspired Eve. It's really exciting to see more people starting to dig into alternative ways of thinking about computation. More generally, it'd be nice to see more classes that encourage thinking about all the coloring we could do outside of the lines.

> The capability of these generalized parallel ad hoc join algorithms where demonstrated on a supercomputer circa 2009.

Is this external work? If so, do you have any pointers to it?

Looks like one of the x-stream guys replied: https://github.com/ar104/sortingVsScanning/blob/master/Sorti...

Related discussion on twitter: https://twitter.com/roy_amitabha/status/634078514698952704

> Also I wonder if it goes too far from abstraction, the ability to name and manipulate something before specifying what it is, exactly, and how to define something iteratively as you become more familiar with what it has to be.

We have some really interesting ideas here around query-first schema generation. E.g. using things before they even necessarily exist as anything formally in the system. Powerful IDEs like Visual Studio enable this workflow, by giving you a quickfix that will create a method/function if it doesn't exist. Coupled with heavy normalization (i.e. 6th normal form) and a nice way of dealing with modeling in that world [1], we should be able to provide a really nice iterative experience. Our explicit goal is for working with Eve to feel almost conversational and exploratory. We found one of the biggest problems with tools like Access was that they forced you to plan everything up front, to define schemas and relationships before you can even do something of value. That's a trap we want to make sure we avoid.

> I also dislike drawing diagrams on screen when they're much quicker to sketch out on paper, but that's probably more of a personal preference (and I've not spent enough time with the editor yet).

The current editor evolved out of the question of if we could write programs on paper efficiently. I agree with you and one of the things I really want to explore a bit further down the road is a sketching-like interface that enables you to draw things directly (it wouldn't be too hard to even capture images from a whiteboard or sheet of paper).

[1]: https://en.wikipedia.org/wiki/Anchor_Modeling

Out of curiosity, what makes you "not as enthused" about our work? The focus on Bloom? Going more visual?

I'm really excited to see what Jonathan is doing now that he's shifted his focus to end-user and building a releasable system at CDG. If you're interested in this stuff, all three of us are going to be at the Future of Programming workshop at strangeloop this year :)

We do! One neat thing about our architecture is that literally everything is just data and side-effects happen outside of the system itself. This means if you disconnect the "watchers" that do things like send email based on the presence of rows in the email table, you can safely do anything you want. This resolves a bunch of issues around testing for us.

The overall plan is to provide a bunch of really interesting generative testing facilities. For example, we can generate data based on your integrity constraints that tries to sneak values into the system that would break them. Being a live language also helps a lot here - you're inherently testing as you build things. We want to make it easy to just capture that while you're doing it.

Check out my note on visual programming. [1]

The short answer is we have lots of tools in mind that will help with this, but programming this way just creates a very different kind of system. We've built some complex things and they've remained fairly flat and we made sure that it is both readily apparent what is contributing to your current query and easy to navigate into it if you want to see more. For the most part these problems boil down to navigation and debugging issues, both of which we have really powerful ideas for. For example, we want our debugging story to be what's called a "why? debugger" where you can click on any value in the system and Eve will show all the data that went into calculating it and every query it went through to get to here.

There's assuredly going to be lots more experimentation needed here, but we have every intention of making this handle more complex things. We're bootstrapping the compiler and eventually the editor, we've built clones of websites, and we'll continue to push the edges of what we can do with it :)

[1]: https://github.com/witheve/Eve/blob/master/design/visualProg...

The shift is primarily due to the fact that relatively few people seemed to want to build large applications, including ourselves.

There are definitely some differences between building large apps and these more communication/analysis tasks, but we think the foundation itself applies to both. The language is an adaptation of the Dedalus[1] semantics, which the BOOM lab did some amazing things in distributed systems with [2]. If it can build a clone of hadoop, chances are it can build most things. We've built a number of our compilers in Eve, several of our editors were bootstrapped, we've built numerous examples, most recently a complete clone of Foursquare. Before we'd want others to try and do that though, we need our tooling to get a bit better. We expect that the Eve editor will get there eventually kind of out of necessity - we're going to bootstrap a lot of it this time too, starting with the compiler.

[1]: http://db.cs.berkeley.edu/papers/datalog2011-dedalus.pdf

[2]: http://db.cs.berkeley.edu/papers/eurosys10-boom.pdf

> But neither of them really found a satisfying answer, a way to say "hey, for making your web app or whatever, if you throw away your existing stuff and use this tool/process, now it's super-easy."

Actually, we think we did. We're just not choosing that as the primary focus of the workflow in Eve. Now with a better version of the editor and with a bit more work on the UI builder, I suspect we could rebuild the entire foursquare clone in under a week. If we had VCS so that multiple people could work together on it, it might only be a couple of days. This foundation for programming has lots of implications for building "real software" - it's actually based on research for making distributed systems much easier to build. [1]

We'll see more of that as we go since we're bootstrapping bits and pieces. One of the first things that will transition over is the compiler, if that gives you any indication of the level of sophistication you can achieve with this programming model.

[1]: http://db.cs.berkeley.edu/papers/eurosys10-boom.pdf

They don't appear to be related. The previous discussion was about replicating an Escher style drawing in Julia. This is about a web framework for Julia that just happens to be named Escher :)

This is very cool work. :) Great job Will!

When Atom was first launched I mentioned that it might make sense to port the interesting parts of LT over to it since the core editor isn't what's important (and it's also a ton of work to get right). LT has found its way into lots of projects, from the Chrome Dev Tools to XCode and IntelliJ, which is a tremendous honor for us - it's great to see it coming to Atom as well.

Some really interesting work was presented last year: http://www.future-programming.org/2014/program.html

I sincerely encourage anyone fiddling with new ideas in programming to submit a proposal. :)

From what I know of his project, the best description is probably a vertically integrated haskell-like language, fully structured editor (think paredit without parens), and distributed framework.

So yeah, Urbit is a better analogue than LT :)

> If there's a better way to teach the same concepts without actually programming, that would be really useful. In a pragmatic sense, it's not helpful to the cause.

These seem contradictory. We can either teach a narrow swatch of people to "code" or we can search for other ways to impart the important bit: modeling. The entire argument of the essay is that we should be looking for those "really useful" ways.

> If a time-strapped journalist comes across a highly-upvoted blog post on a tech site

I'm not sure focusing on getting a message out to someone who won't read the entire post is a worthwhile pursuit.

The simplest possible distinction: coding is writing code in a programming language[1][2][3], modeling is breaking down systems without regard for computer or programming language and is not specific to any domain.

When we say "coding" the accepted definition has to do with giving instructions in a programming language to a computer. I'm saying that the fundamental skill for people has nothing to do with Python or computers at all.

[1]: https://www.google.com/webhp?sourceid=chrome-instant&ion=1&e... - "write code for (a computer program)."

[2]: http://en.wikipedia.org/wiki/Computer_programming - "commonly referred to as coding"

[3]: https://www.google.com/webhp?sourceid=chrome-instant&ion=1&e... - everything on the first page is talking about writing code as instructions to a computer.

> I'm a little disappointed to see him attack this initiative to get more people into coding.

That's because I'd rather people have the freedom to be mathematicians, nurses, lawyers, physicists, writers, and accountants while still being able to leverage computers. Instead of forcing people to become professional programmers to get the computer to model things for you, we should focus on teaching people how to model in general and build more tools like Excel that let people do that.

Hell, I'd stand behind a movement to just teach people Excel. With Excel, we don't have to spend the next several years worrying about what flavor of MVC we have to use. Instead, we can focus on doing actually important things like curing cancer.

> Besides programmers and mathematicians, the only people I've met with the faculties to properly break things down are lawyers.

My point is we should fix that, instead of focusing on teaching people Python.

> So, teach kids geography.

Haha exactly! That's a really interesting example I hadn't heard before. There are lots of other fun ones: number permanence, volume conservation, etc.

I actually mention the magic of LISP and Smalltalk environments - they do greatly add in the exploratory creation process. But my "coding as literacy" strawman is born out by the industry: http://code.org/ and http://www.codecademy.com/ are great examples. By saying you can learn to code by following through some online lessons that teach you how to write some Javascript, we're doing people a great disservice.

Moreover, my real argument is that I don't think coding should be literacy. From the fundamental disconnect section:

> We don't want a generation of people forced to care about Unicode and UI toolkits. We want a generation of writers, biologists, and accountants that can leverage computers.

I don't think people should have to worry about exactly what the computer is doing if their problem isn't related to it. Specifically teaching general purpose programming as we think of it now is largely teaching people to build apps or command line tools. Instead of a generation that thinks of that as computing, we need a generation of people curing cancer with it.

> The real lesson of programming is to be able to to create models that stand up agains the cold asphalt of reality.

I would argue that's just a matter of modeling enough to be good at it. I indirectly talk about this in a few places, while discussing how we iteratively craft models and in the section about kids (where I bring up debugging specifically). It's very important to work out assumptions and to be able to explore your models to find out where you've gone wrong. Programming is one way of doing that in terms of the computer, my hope is we'll find better ways of doing it in the future.

We're already doing that one :)

This is really interesting and very cool to see. The approach we're taking with Eve (gory details at [1]) is that you can treat everything as relational and doing so provides lots of benefits. One thing that wasn't clear though, was how you extend that notion down into the OS-level for both performance and semantic reasons. It's encouraging to see someone with requirements as deep as facebook's find that this strategy works in that context.

The next step would be manipulating the OS as relations. E.g. an insert into the process table allows you to actually spawn a process. It would start to get really interesting from there...

[1]: http://incidentalcomplexity.com/2014/10/16/retrospective/

What an aggressive response. :/

Thanks for the indirect pointer on how to correct the issue though. If you hard refresh you can zoom now.

The cursors were long before we were thinking explicitly of spreadsheets. Our model now has no encapsulating scope, which is just like access to some global object like you're suggesting here.

Huh. I just opened a brand new download of eclipse and it's at 440mb with no files open. LT is 115 + 50 having been open all week.

Did you have some weird plugins installed? Did you create a bunch of Clojure processes and count those?

EDIT: Ah, there was a memory leak for a while. I bet that's what the problem was. It's definitely fixed in master.

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.

That's fair. I'll get on it.

Out of curiosity, do you have real numbers there? I'd be quite surprised if it was really hundreds of thousands.

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.

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.