Or as the physicist and Bayesian pioneer E. T. Janes, wrote:
In any field, the Establishment is seldom in pursuit of the truth, because it is composed of those who sincerely believe that they are already in possession of it.
From Probability Theory: The Logic of Science, E.T. Jaynes, 2003.
It's a fun talk by Bret and I think he echoes a lot of the murmurings that have been going around the community lately. It's funny that he latched onto some of the same core tenants we've been kicking around, but from a very different angle. I started with gathering data on what makes programming hard, he looked at history to see what made programming different. It's a neat approach and this talk laid a good conceptual foundation for the next step: coming up with a solution.
In my case, my work on Light Table has certainly proven at least one thing: what we have now is very far from where we could be. Programming is broken and I've finally come to an understanding of how we can categorize and systematically address that brokeness. If these ideas interest you, I highly encourage you to come to my StrangeLoop talk. I'll be presenting that next step forward: what a system like this would look like and what it can really do for us.
These are exciting times and I've never been as stoked as I am for what's coming, probably much sooner than people think.
Haha it sucks actually - I love talking about this stuff, but I know I really need to save it for my talk so I'm tearing myself to pieces trying to keep quiet.
I guess one thing I will say is that our definition of programming is all over the place right now and that in order for us to get anywhere we need to scale it back to something that simplifies what it means to program. We're bogged down in so much incidental complexity that the definitions I hear from people are convoluted messes that have literally nothing to do with solving problems. That's a bad sign.
My thesis is that given the right definition all of the sudden things magically "just work" and you can use it to start cleaning up the mess. Without giving too much away I'll say that it has to do with focusing on data. :)
It seems like one large breakthrough in programming could simply be using the features of a language in a manner that best suits the problem. That's what I get from your blog post: design for what makes sense - not for what looks normal during a review. One thing I envy from LISP is that there seem to be few 'best practices' that ultimately make our applications harder to modify.
I'm working on a system based on Bret Victor's "Programming in Principle" talk. I believe to achieve such a system, you need to find a way to add semantics to code, as well as the utilization of proofs in order to have enough constraints that your environment is seamlessly self-aware while at the same time extensible.
I'm curious what you mean by data though. Is it data in the "big data" sense? What I mean is, are we talking about gathering a lot of data on coding? My approach is based on that, anyway: lots of data on code with a number of different analyzers (static and dynamic) that allows for extraction of common idioms and constraints, while allowing for the system to more easily help the user.
Of course, there's no magic and a lot of times I reach dead-ends, and while I'm eager to have enough to show the world, progress has been kinda slow lately.
Looking forward for your talk, be sure to link here on HN.
I feel the same way. As a programmer, I feel like there are tons of irrelevant details I have to deal with every day that really have nothing to do with the exercise of giving instructions to a computer.
That's what inspired me to work on my [nameless graph language](http://nickretallack.com/visual_language/#/ace0c51e4ee3f9d74...). I thought it would be simpler to express a program by connecting information sinks to information sources, instead of ordering things procedurally. By using a graph, I could create richer expressions than I could in text, which allowed me to remove temporary variables entirely. By making names irrelevant, using UUIDs instead, I no longer had to think about shadowing or namespacing.
Also, by avoiding text and names, I avoid many arguments about "coding style", which I find extremely stupid.
I find that people often argue about programming methodologies that are largely equivalent and interchangeable. For example, for every Object Oriented program, there is an equivalent non-object-oriented program that uses conditional logic in place of inheritance. For every curried program, there is an equivalent un-curried program that explicitly names its function arguments. In fact, it wouldn't even be that hard to write a program to convert from one to the other.
I'm pretty excited about the array of parallel processors in the presentation though. If we had that, with package-on-package memory for each one, message passing would be the obvious way to do everything. Not sure how to apply this to my own language yet, but I'll think of something.
I'd like to try labview, but doesn't it cost lots of money? I guess I'll sign up for an evaluation copy.
The closest things to my language that I have seen are Kismet and UScript. Mine is different though because it is lazily evaluated and uses recursion as the only method of looping.
Some other things that look superficially similar such as Quartz Composer, ThreeNode, PureData, etc. are actually totally different animals. They are more like circuit boards, and my language is a lot more like JavaScript.
>By making names irrelevant, using UUIDs instead, I no longer had to think about shadowing or namespacing.
I've been trying to do something similar with a pet language :) Human names should never touch the compiler, they are annotations on a different layer.
But writing an editor for such a programming environment with better UX and scalability than a modern text-based editor is... an engineering challenge.
It's not perfect, and making lambdas is still a little awkward because I haven't made them resizable. Also, eventually I'd like the computer to automatically arrange and scale the nodes for you, for maximum readability. But I think it's pretty fun to use. It'd probably be even more fun on an iPad.
I'd love to make my IDE as fun to use as DragonBox
I think it's really nice! Usually these flow-chart languages have difficult UI, but this one is pretty easy to mess around in.
It would be good if, while clicking and dragging a new connection line that will replace an old one, the latter's line is dimmed to indicate that it will disappear. Also, those blue nodes need a distinguishing selection color.
It sounds like you're aiming more toward a fun tablet-usable interface, but:
Have you thought about what it would take to write large programs in such an editor? For small fun programs a graph visualization is cool, but larger programs will tend toward a nested indented structure (like existing text) for the sake of visual bandwidth, readability of mathematical expressions, control flow, etc.
Use the arrow keys to move the box around. I suppose that's still a bit primitive, but I'll make some more involved programs once I fix up the scoping model a bit.
When I first started on this project, I thought at some point I would need to make a "zoom out" feature, because you might end up making a lot of nodes in one function. However, I have never needed this. As soon as you have too much stuff going on, you can just box-select some things and hit the "Join" button to get a new function. The restricted workspace actually forces you to abstract things more, and the lack of syntax allows you to reduce repetition more than would be practical in a textual language.
For example, in textual languages, reducing repetition often requires you to introduce intermediate variables, which could actually make the program's text longer, so people will avoid doing it. However, in my language you get intermediate variables by connecting two sinks to the same source. The addition in program length hardly noticeable.
Nice but still classical programming. I personally think if statements are the problem. The easiest languages are trivial ones with no branching. Not Turing complete, but they rock when applicable e.g. html, gcode
That's true. I intended it to be feature-comparable with JavaScript, since I think JavaScript is a pretty cool language, and that is what it is interpreted in.
I don't think it is possible to make a program without conditional branches.
Somebody posted a link below about "Data Driven" design in C++. In it was an example of a pattern where each object has a "dirty" flag, which determines whether it needs processing, but they found that failing branch prediction here took more cycles than simply removing the branch.
My thought was, instead, what if you created two versions of that method -- one to represent when the dirty flag is true, and another to represent when the dirty flag is false -- and then instead of toggling the dirty flag, you could change the jump address for that method to point to the version it should use. If this toggle happens long enough before the the processor calls that method, you would remove any possibility of branch prediction failure =].
I have no idea if this is practical or not, but it is amusing to consider programs that modify jump targets instead of using traditional conditional branches.
In actual compiled code, conditional branches (without branch prediction) are translated to jumps to different targets, which are specified inline with the instructions. Specifying a modifiable target would mean fetching it from a register (or worse, memory) and delaying execution until the fetch is complete (several cycles minimum on a pipelined machine). With branch prediction, instructions are predicated on a condition inline and we avoid the costly jump instructions.
I think we more commonly use the latter, which tries to guess which way the code will branch and load the appropriate jump target. It's actually typically very successful in modern processors.
I think we need to shift to a different model ... like liquid flow. Liquid dynamics are non-linear (ie. computable), yet a river has no hard IF/ELSE boundaries, it has regions of high pressure etc. which alter its overall behaviour. You can still compute using (e.g. graph) flows, but you don't get the hard edges which are a cause of bugs. Of course it won't be good at building CRUD applications, but it would be natural for a different class of computational tasks (e.g. material stress, neural networks)
(PS angular-js has done all that dirty flag checking if you like that approach)
> I'm pretty excited about the array of parallel processors in the presentation though. If we had that, with package-on-package memory for each one, message passing would be the obvious way to do everything.
Chuck Moore, the inventor of Forth, is working on these processors.
I have. I should play with them more, since I don't quite get DataFlow yet.
I'm used to JavaScript, so that's what I based my language on. It's really a traditional programming language in disguise, kinda like JavaScript with some Haskell influence. It's nothing like a dataflow language. On that front, perhaps those languages are a lot more avante-guarde than mine.
I don't get it, why are you afraid of scooping yourself?
In the same way that HN frowns upon stealth startups, shouldn't we frown upon 'stealth theories'? If your thoughts are novel and deep enough, revealing something about them will only increase interest in your future talks, since you are definitionally the foremost thinker in your unique worldview. If the idea fails scrutiny in some way, you should want to hear about it now so you can strengthen your position.
What's the downside, outside of using mystery to create artificial hype?
can't speak for the thread starter, but one downside to prematurely talking about something is confusion. Half formed thoughts, rambling imprecise language, etc can create confusion for his audience. The process of editing and preparing for a talk makes it more clear and concise. Maybe he is not ready yet to clearly communicate his concepts yet.
For example, people do seem to assume that programming must involve, in some way, coding. Do we really need to code in some programming-language to be programming?
Changing security settings, for example, in a browser lead to quite different behaviors of the program. Isn't the user of the browser programming because they change the behavior of the program?
And this leads to....
> with focusing on data
If we focus on data, and hopefully better abstractions on how to manipulate that data, then wouldn't any user able to alter a program because they can adjust "settings" at almost any point within the program: in real time.
Wouldn't this then enable a lot more people to become programmers?
The difference between setting parameters and programming is obviously that programming allows the creation of new functions.
"Coding" is literally the act of translating a more-or-less formally specified program (that is, a set of planned actions) into a particular computer language.
However, if being a programmer was only like being a translator, programming wouldn't be too hard for mere mortals. That's on the other part - the one that involves methods, logic, knowledge like the CAP theorem - they have problems with. The fact is, not every one can re-discover the bubble sort algorithm like we all here did when we were 8 or so. That's why we are programmers, and that's why they are not (and don't even want to be -- but they are nonetheless nice people and have other qualities, like having money). And these problems don't vanish if you switch from control-flow to data-flow or some bastardized-flow; they just change shape.
As some people have mentioned in this HN post, it is hard to define what programming means.
A program is the result of the automation of some process (system) that people have thought up (even things that couldn't exist before computers). Programming is the act of taking that process (system) and describing it in a computing device of some kind.
Programming currently requires some kind of mapping from the "real world" to the "computer world". The current mapping is done primarily with source code. So, it currently seems that people who are good at programming are good at mapping from the "real world" into the "computer world" via coding.
You seem to be making the point that some people are just good at programming because they can do things like "re-discover the bubble sort algorithm" or understand CAP theorem. These are very domain specific problems.
For people who are able to "re-discover inventory control management" they would do a great job of automating it (programming) if they had an easier way to map that process (system) to a computing device.
The ultimate goal (other than maybe AI) is a 1-to-1 mapping between a "real world" process (system) and a computing device that automates it.
I've been thinking a lot about such issues too; particularly the pain points I have when ramping up against new systems. What information is missing that leaves me with questions? Can code deliver something thorough enough to be maintainable as a single source of truth?
I think, the differences between reading and writing code are as big as sending and receiving packets. It's difficult to write code that extrapolates the base information in your head driving the decisions. Not only that, but you also have to juggle logic puzzles as you're doing it. And on the other side, you have to learn new domain languages (or type hierarchies), as well as what the program is supposed to do in the first place.
I think the idea of interacting with code as you build it is great, but how can we do that AND fix the information gap at the same time?
Can you attend Splash in October? I know academic conferences are probably not your pace, but there will be some good talks and it might be worth your time for networking with some of the academic PL types.
This made me feel like you were going to write the content and then randomly post it in the comments section of someone's blog on clocks as garden decorations or something like that.
APL. Start there. Evolve a true language from that reference plane. By this I mean with a true domain-specific (meaning: programming) alphabet (symbols) that encapsulate much of what we've learned in the last 60 years. A language allows you to speak (or type), think and describe concepts efficiently.
Programming in APL, for me at least, was like entering into a secondary zone after you were in the zone. The first step is to be in the "I am now focused on programming" zone. Then there's the "I am now in my problem space" zone. This is exactly how it works with APL.
I used the language extensively for probably a decade and nothing has ever approached it in this regard. Instead we are mired in the innards of the machine, micromanaging absolutely everything with incredible verbosity and granularity.
I really feel that for programming/computing to really evolve to another level we need to start loosing some of the links to the ancient world of programming. There's little difference between what you had to do with a Fortran program and what you do with some of the modern languages in common use. That's not he kind of progress that is going to make a dent.
Well in the end it doesn't matter if your language is looking for popularity or not. What matters is what you can do with it. You think a language with weird symbols all around can't win? Just look at Pearl.
On a related note, if one plans to sell the Language of The Future Of Programming, I swear this thing will know the same fate as Planner, NLS, Sketchpad, Prolog, Smalltalk and whatnot if it cannot help me with the problems I have to solve just tomorrow.
It's very hard to find good tutorials on APL because it's not very popular and most of its implementations are closed-source and not compatible with each other's language extensions, but it's most recognizable for its extreme use of non-standard codepoints. Every function in APL is defined by a single character, but those characters range from . to most of the Greek alphabet (taking similar meanings as in abstract math) to things like ⍋ (sort ascending). Wikipedia has a few fun examples if you just want a very brief taste; you can also read a tutorial from MicroAPL at http://www.microapl.com/apl/tutorial_contents.html
It's mostly good for being able to express mathematical formulas with very little translation from the math world - "executable proofs," I think the quote is - and having matrices of arbitrary dimension as first-class values is unusual if not unique. But for any practical purpose it's to Haskell what Haskell is to Java.
> But for any practical purpose it's to Haskell what Haskell is to Java.
Can you elaborate on this? As I understand, the core strengths of APL are succinct notation, built-in verbs which operate on vectors/matrices, and a requirement to program in a point-free style. All of this can be done in Haskell.
>A Haskell programmer unfamiliar with APL looks at an APL program and...
And says "what's the big deal?". That's exactly the question, what is the big deal. APL isn't scary, I'm not shouting "I can't make sense of this", I am asking "how is this better than haskell in the same way haskell is better than java?".
I'm not imagined, I am real. I know you were restating the analogy, the problem is that the analogy is wrong. I can't find anything about APL that a haskell developer would find new or interesting or frightening or anything like that.
More esoteric organization/concepts for anyone coming from the C family (which is basically everyone), more out-there notation, more deserving of the title "write-only," and less ability to do anything you might want to do with a real computer beyond using it as a calculator. I wouldn't want to do much work with Haskell's GTK bindings, but at least they exist.
That tutorial is deeply unimpressive. It seems very excited about APL having functions, and not directly mapping to machine-level constructs. In 1962 I can imagine that being impressive (if you weren't familiar with Lisp or ALGOL); today, not so much. The one thing that does seem somewhat interesting is the emphasis it puts on "operators" (i.e., second-order functions). This is obviously not new to anyone familiar with functional programming, but I do like the way that tutorial jumps in quite quickly to the practical utility of a few simple second-order functions (reduce, product, map).
Like I said, it's hard to find good ones; I didn't say I had succeeded. I learned a bit of it for a programming language design course, but I never got beyond the basic concepts.
All the decent tutorials that I know of were in book form. Unless someone's scanned them they're gone. I know mine got destroyed in a flooded basement.
If my memory hasn't been completely corrupted by background radiation, I've seen papers as early as the mid 1950s about this notation.
APL started out as a notation for expressing computation (this is not precise but good enough). As far as I'm concerned it's sitting at a level of abstraction higher than Haskell (arguably like a library overtop Haskell).
Now, in the theme of this thread, APL was able to achieve all of this given the constraints at the time.
The MCM/70 was a microprocessor based laptop computer that shipped in 1974 (demonstrated in 1972, some prototypes delivered to customers in 1973) and ran APL using an 80 kHz (that kilo) 8008 (with a whole 8 bytes of stack) with 2 kBytes (that's kilo) RAM or maxed out at 8 kB (again, that's kilo) of RAM. This is a small slow machine that still ran APL (and nothing else). IEEE Annals of Computer History has this computer as the earliest commercial, non-kit personal computer (IEEE Annals of the History of Computing, 2003: pg. 62-75). And, I say again, it ran APL exclusively.
Control Data dominated the super computer market in the 70s. The CDC 7600 (designed by Cray himself, 36.4 MHz with 65 kWord (a word was some multiple of 12 bits, probably 60 bits but I'm fuzzy on that) and about 36 MFLOPS according to wikipedia) was normally programmed in FORTRAN. In fact, this would be a classic machine to run FORTRAN. However, the APL implementation available was often able to outperform it, almost always when coded by an engineer (and I mean like civil, mechanical, industrial, etc engineer, not a software engineer) rather than someone specialising in writing fast software.
I wish everyone would think about what these people accomplished given those constraints. And think about this world and think again about Bret Victor's talk.
The ones I remember were all books. At the time, I thought this was one of the best books available: http://www.amazon.com/APL-Interactive-Approach-Leonard-Gilma... -- but I don't know if I'd pay $522 for it... actually I do know, and I wouldn't. The paper covered versions are just fine, and a much better price :-)
EDIT: I just opened the drop down on the paper covered versions. Prices between $34.13 and $1806.23!!! Is that real?!? Wow, I had five or six copies of something that seems to be incredibly valuable. Too late for an insurance claim on that basement flood.
> Instead we are mired in the innards of the machine micromanaging absolutely everything with incredible verbosity.
This is one area where Haskell really shines. If you want the machine to be able to do what you want without micromanaging how, than you need a way to formally specify what you mean in an unambiguous and verifiable way. Yet it also needs to be flexible enough to cross domain boundaries (pure code, IO, DSLs, etc).
Category theory has been doing exactly that in the math world for decades, and taking advantage of that in the programming world seems like a clear way forward.
The current state of the industry seems like team of medieval masons (programmers) struggling to build a cathedral with no knowledge of physics beyond anecdotes that have been passed down the generations (design patterns), while a crowd of peasants watch from all angles to see if the whole thing will fall down (unit tests).
Sure, you might be able to build something that way, but it's not exactly science, is it?
This is the kind of talk from Haskell folks that I find incredibly annoying. Where's Haskell's Squeak? Where's Haskell's Lisp Machine? It doesn't take much poking around to find out that non-trivial interactive programming like sophisticated games and user interfaces is still cutting very edge stuff.
I'm sorry, but you're upset because folks are passionate about a language that brings new perspective, and maybe is not exactly as useful in some areas as existing solutions? This is exactly the kind of attachment Bret warns about.
I don't think I expressed attachment to any particular solution or approach - I simply pointed out an extremely large aspect of modern software engineering where Haskell's supposed benefits aren't all that clear. So who's attached?
Are you trying to compare interactive software, one of the dominant forms of programs and widely used by billions of people every day, to formula 1 cars, an engineering niche created solely for a set of artificial racing criteria?
A better analogy would be being mad that the Tesla can't drive on the interstate.
"sophisticated games" pretty specifically implies contemporary 3d gaming, which is not a useful criteria for exploring a fundamental paradigm shift in programming.
The fact that you think a lisp machine is an "extremely large aspect of modern software engineering" certainly makes me feel that you are expressing an attachment to a particular approach.
We have many beautiful cathedrals don't we? So it is a bonafide fact that you can build something with the current state of industry. As far as the analogy goes I would alter it in that the peasants aren't simply watching, but poking the masonry with cudgels. Lastly, scientific methods of building aren't necessarily better, while they follow an order that is rooted in a doctrine, I can quickly think of all those scientifically built rockets that exploded on launch. To play devil's advocate, I'm not convinced that a scientific method is a better one than the current haphazard one we have in place for development.
I'm still not sure how you'll make LightTable work (well scale), hopefully it involves a new programming model to make the problem more well defined?
We had some great discussions at LIXD a couple of weeks ago, wish you could have been there. Everyone seems to be reinventing programming these days. We are definitely in competition to some extent. The race is on.
Great. I'll send you something about my new programming model when it is written up decently, but it has to do with being able to modularly re-execute effectful parts of the program after their code or data dependencies have changed.
@ibdknox. I've started programming Clojure in LightTable the other day. How does programming differ from editing text? Can we use gestures to navigate and produce code? I'm working on visual languages which work well in certain domains, but fail when one needs precise inputs. To me the language constructs we use are inherently tied with the production of code (Emacs + LISP). There is a very good reason the guy who built Linux come up with a great versioning system. It is fair to say that Bret does not quite now yet what he is talking about, as he says himself. As if something big is going to happen and it is hard to say what exactly it is. I hope LightTable or something like it replaces Emacs&Vim in a couple of years. I think that being able to code in the browser will turn out to be unbelievably important (although it looks not that useful today).
A whole bunch of interesting stuff in there. Undoubtedly I shall spend most of my forthcoming holiday reading up on papers and other works as old as I am and realising - yet again - everything old is new again (except for the bits that have been willfully ignored in favour of being reinvented, badly ;) )
I don't know that it was a bad thing though. As soon as I saw that I started to think about how that might be possible, or even if it could be possible. Fundamentally there has to be some kind of common discovery protocol underlying it; it just doesn't appear to be possible (yet) to have two unknown systems talk to each other with an unknown protocol. That'd be like two monoglots, a German and Russian speaker figuring out how to talk fluently with each other. I suppose it would be possible using gestures and props, but these non-verbal clues could themselves be thought of as a kind of discovery protocol for figuring out the more efficient protocol that enables verbal communication.
You should look into Hypermedia API's. The entire point is to have a discoverable API where the developer doesn't need to know low level details. Theoretically, you could write a library to parse, adapt, and act on another API.
This is awesome. It makes me realize how much of the time I am just applying the same formula over and over again and not really being creative. The flip side, I would argue is that reinventing the wheel all the time is expensive. There's a reason why standards have formed.
If you try to reinvent the wheel, you will get another wheel. I think what Bret is talking about there is wondering about if we could create airplanes and spaceships perhaps!
"'The most dangerous thought you can have a creative person is to think you know what you're doing.'
It's possible to misinterpret what I'm saying here. When I talk about not knowing what you're doing, I'm arguing against "expertise", a feeling of mastery that traps you in a particular way of thinking.
But I want to be clear -- I am not advocating ignorance. Instead, I'm suggesting a kind of informed skepticism, a kind of humility.
Ignorance is remaining willfully unaware of the existing base of knowledge in a field, proudly jumping in and stumbling around. This approach is fashionable in certain hacker/maker circles today, and it's poison."
> Ignorance is remaining willfully unaware of the existing base of knowledge in a field, proudly jumping in and stumbling around. This approach is fashionable in certain hacker/maker circles today, and it's poison.
> Learn tools, and use tools, but don't accept tools. Always distrust them; always be alert for alternative ways of thinking. This is what I mean by avoiding the conviction that you "know what you're doing".
These two statements have done a better job explaining my feelings on expertise than almost any of my attempts. Thank you, Bret.
> Ignorance is remaining willfully unaware of the existing base of knowledge in a field, proudly jumping in and stumbling around. This approach is fashionable in certain hacker/maker circles today, and it's poison.
Any more abstraction on this statement?
I'm interpreting it as "don't try new things because you don't know what you're doing", which just so happens to feel like the exact opposite of what Bret is trying to convey.
As I'm interpreting it, it's a cautionary statement against worshipping ignorance. It's brave and difficult to do something that's dissimilar to the ways you've learned and become powerful through performing. It's foolish to dive in without learning all that you can about what those who have been here before discovered.
I don't think it's cautioning against diving in prematurely. It's cautioning against thinking you'll do better than those who have come before by pure virtue of not knowing what yhey've done.
Enough already ! Could anyone with 100 millions $ give this guy a team of 100 Phds to create the new software revolution ?
This guy is not a good or great or fabulous computer scientist, this guy is something else entirely. He's a true creative Thinker. He doesn't have a vision, he's got tons of them. Every subject he starts thinking about he comes with new ideas.
He shouldn't be doing presentations, he should run a company.
Based on his personal writings, it seems like he prefers to be left alone to work on his ideas. It does not seem like he wants to run a company, or really even work with others.
A company? Then we would have just one solution to the problems he sees. I think that just throwing a bunch of ideas at all of us is more effective. We can all think independently and come up with more novel ways to solve those problems.
In 2040 someone will discover Haskell, shed tears on why C#++.cloud is so widespread instead in the industry, and use it to conclude the sorry state of the world. Seriously, don't compare what was published in papers 50 years ago with what business uses today, compare it with what is in papers now, and there are lots of interesting things going on all the time, when was the last time you even checked? Probabilistic programming? Applications of category theory to functional programming? Type theory? Software transactional memory?
Woody Allen did this great movie some time ago, "Midnight in Paris", where the main character, living in present times, dreams of moving back in time to the 1920s as the best time for literature ever. When the occasion to really go back appears though, he discovers the writers of the 1920s thought the best literature was done in 1890s, and so he has to go back again, then again, ... This talk is like this, sentiment blinding a sober assessment.
Well, there must be a reason why research keeps discovering new ways of computing and programming while the industry is stucked with the outdated methods.
I loved that movie, but I don't think it is too relevant here. I mean, you can rediscover and read any literature written in the 20s or the 1890s, which is exactly what our field is not doing.
It's simple: industry and academia are too far apart today.
Look at the languages that come out of academia, then look at the languages that have been invented over the last few decades which have gained traction. The latter list includes a lot of crazy items, things like Perl, PHP, Javascript, Ruby, and Python.
Some of them with their merits but for the most part hugely flawed, in some cases bordering on fundamentally broken. But what do they have in common? They were all invented by people needing to solve immediate problems and they are all designed to solve practical problems. Interestingly, Python was invented while its author was working for a research institute but it was a side project.
The point being: languages invented by research organizations tend to be too distanced from real-world needs of everyday programmers to be even remotely practical. Which is why almost all of the new languages invented over the past 3 decades that have become popular have either been created by a single person or been created by industry.
LLVM and Scala come to mind as PL projects born in academia and enjoying wider adoption. Not all researchers are interested in solving the "real problems out there", but some do, and are successful at it.
I feel like you missed the fact that he is obviously aware of the market/hardware reasons that caused programming to evolve in this manner, but it doesn't change the fact that this current model of programming may be a false evolutionary pathway.
He is pointing out experts tend to deny a perfectly valid way of exploring technology, because it doesn't follow the defined community-accepted standards built on assumptions of hardware and efficiency.
He's not not knocking the current model, he's not even saying these other models shouldn't have died, he's saying they shouldn't be forgotten and should often be reexamined in light of new technology which might make a better home for it.
Yes, he is actually, repeatedly. For instance, at 9:30 in the video: "There won't be any, like, markup languages, or stylesheet languages, right? That would make no sense".
Industry is screwy. My perspective is always from heavy industry, where we consider upgrading to PLCs that run on Pentium 90 architecture _amazing_. There's good reason for that reactionism; never fix what ain't broke.
But the same philosophy is used in the softer analytics, where using state of the art really is better. Sure giant clunky Excel sheets _work_, but we can build far better charting tools. We can run statistics easier than MiniTab. Data can be interactive, searchable, and computable instead of rituals and incantations to lousy proprietary one-off enterprise buzz-word-a-tron programs.
We _could_ be using analytical tools that shape themselves to the data. Instead, we have to convince management that it's _possible_ to analyze and map data easily in these new ways. But once they see how much more powerful these ideas are - how much faster and cheaper they work - lower mgt. is thrilled. And if upper management is profit oriented, they'll like it too.
But by this argument, no one is ever allowed to criticize the current state of the world compared with the past, lest he be accused of nostalgia-clouded vision.
I don't follow. The notion put forward was "hey people who like haskell, stop improving haskell and start adding visual studio support or else $BIGCORP won't use haskell". Nobody cares if $BIGCORP uses haskell, they are free to cripple themselves if they want. If $BIGCORP actually seriously wanted to use haskell, they could afford to pay someone to add visual studio support for haskell.
I just watched most of this talk while a large C++ codebase was compiling, in the midst of trying to find one of many bugs caused by multiple interacting stateful systems, on a product with so much legacy code that it'll be lucky if it's sustainable for another ten years.
Like Bret's other talk, "Inventing on Principle", this talk has affected me deeply. I don't want this anymore. I want to invent the future.
This seems to be a callout to a point Alan Kay has been making for a while. RDF might be a good way to dip your toes in the water, but Alan Kay has gone further and called out languages such as "Linda" and related "tuple-space" research as directions in automatically figuring this stuff out.
For my own part I would also look into metaphor based research. By this I mean that looking to Biology for metaphors worked really well for OO programming so do the same thing here. Humans have been dealing with the mapping of their native language to that of another language for centuries now. I am sure that amongst anthropologists and linguists there is a pretty good body of research on how "first-contact" communication has been accomplished in the past and probably people have attempted to figure out principles to apply as well. There is probably a lot of fertile field here to till from a computer science perspective. NASA might have even sponsored some interesting research in this field, how did we design the voyager plaque, for instance.
APIs are currently the core fabric by which communication occurs within a computing system. As long as we use them, we end up with specialization of communication between computing systems.
This specialization, in my opinion, is the root cause problem in programming computing systems.
Bret Victor had this to say "The only way it (communication between systems) can scale, they (computers) have to figure out (dynamically), a common language".
Here I feel he is missing a key point. It is not a common language we are looking for, but a common architecture by which information is communicated between systems. Or, in this case, a non-architecture or anti-API by which communication takes place between systems.
Very good summary of the state of the art in the early 70s.
His analysis of the "API" problem reminds me of some of the ideas Jaron Lanier was floating around about ten years ago. I can't recall the name of it, but it was some sort of biologically inspired handshake mechanism between software 'agents'.
What I think such things require is an understanding of what is lacking in order to search for it; as near as I can tell, that requires some fashion of self-awareness. This, as far as I can conceive, recurses into someone writing code, whether it be Planner or XML. But my vision is cloudy on such matters.
I should note that I think Brett is one of the leading thinkers of his (my) generation, and have a lot of respect for his ideas.
I very much enjoyed Bret's talk, but the visual programming part of his talk was rather half-baked. I say this as someone who has done visual coding professionally in the past. People have been trying to crack the "drawing programs" nut for decades. It's not a forgotten idea. It's so not forgotten that there is a wikipedia page listing dozens of attempts over the years: http://en.wikipedia.org/wiki/Visual_programming_language.
The reason we still code in text is because visual programming is not a hard problem -- it's a dozen hard problems. Think about all of the tools we use to consume, analyze, or produce textual source code. There are code navigators, searchers, transformers, formatters, highlighters, versioners, change managers, debuggers, compilers, analyzers, generators, and review tools. All of those use cases would need to be fulfilled. Unlike diagrams, text is a convenient serialization and storage format, you can leverage the Unix philosophy to use the best of breed of the tools you need. We don't have a lingua franca for diagrams like we do for text files.
It's not due to dogma or laziness that we use text to write code. It's because the above list of things are not trivial to get right and making them work on pictures is orders of magnitude harder than making them work with text.
What I think, is that you are saying something that people (and not just "people," but some of the most brilliant people in the history of computing) have been saying for 20 to 40 years.
I've always liked Connections: https://en.wikipedia.org/wiki/Connections_(TV_series). What is so great about this show is that James Burke is able to point out how new and amazing ideas come about by connecting a few, seemingly unrelated, concepts to make a new idea.
In my opinion, the ability for someone to take a few observations about the world around them and turn it into something new and amazing is what makes them brilliant.
We are now at a point in history where a lot of people are able to take in a lot of different ideas leading to a lot of new discoveries (one of the reasons why I think new technology is now being created at an almost exponential rate).
You seem to be implying that a particular problem can't be solved because brilliant people in the past have not solved it yet. In my opinion, problems aren't solved yet because someone has not "connected the dots" yet.
And visual programming solves this how? People will have to learn how to connect arcane bricks instead of writing arcane text. Programming isn't going to be democratised until we approach natural language interpreters.
Every step in the development process moves those people with the domain-expertise/vision/creative process/etc. further from the solution. Removing steps, like coding, brings the solution closer to the domain experts/visions/create process/etc.
Visual programming makes it a lot easier for people to work collaboratively. For example, those with the domain-expertise can work closer with those that have programming experience in a visual language.
Just a few ways that visual languages could democratize programming.
Visual programming is not going to solve this unless the visualisation matches their domain-specific notation instead of a visual graph that has separate edges for "then" and "else". At that point, why bother with the visual notation instead of just putting it in text they understand equally well?
Ease of Use - It is not possible to have syntax errors. (Logical errors/misunderstandings of the problem being solved are still possible).
I'm not quite sure what "text they understand" means. Are you talking about natural language interpreters (as you mention above)? That would/will be some cool technology and my feeling is that it is a "next step" in software evolution. Maybe, more likely, the next step is a planned or constructed language interpreter (http://en.wikipedia.org/wiki/Constructed_language). Natural language is so tricky (but maybe not for very domain specific problems).
I mean text that approaches natural language if not natural language. I think something like Inform 7 is far more likely to be adopted by that audience than a visual graph that is just an abstraction of loops and functions. I think the benefits of a textual language matching a domain are much greater than a general-purpose visual programming language.
If it targets, say, a visual learner, I think a graph language won't help unless they are already visualising the program as a graph.
Languages aren't, per se, elite, coding techniques are. Lots of ordinary non-programmers can successfully code to some degree in C, C++, Python, etc. But there are many advanced techniques that only experienced developers will be able to grapple with. Anyone can buy and use a hammer, but that doesn't mean that using a hammer makes anyone a carpenter.
Do I think that in 40 years or 100 years we will still be coding in a way that is compatible with using vim? Probably. And I don't see how that makes programming less "democratic".
> But there are many advanced techniques that only experienced developers will be able to grapple with.
At one time iterators were considered a technique and a design pattern. Now, they are a part of most languages. They are transparent. They are taken for granted.
Currently, programming takes place within the domain of software development. It is not surprising then that we value advanced techniques within the industry. Just like there are advanced techniques that are used within the domains of electrical engineering, mechanical engineering and biology (just to name a few).
As we get better at our job as programmers, we further make our "advanced techniques" transparent to those that use our systems. Sure, currently, these systems are usually very domain specific. However, there is nothing to say that we can not build better software development environments which are both non-domain specific and, at the same time, hide the underlying complexities that require experienced developers.
In my opinion, these development environments would use a type of visual language enabling a lot more people to program. I am biased because this is a problem I've been working on for quite a few years now.
Most people can't describe what they want to a human let alone a computer. This is the skill of the programmer. Coding comes second.
If we can teach kids to analyse process, teaching them a programming language, whatever the paradigm, is trivial.
I have no idea what coding will look like in 40 years (although a very solid percentage of it will be no different to now) but it will be driven as much by fashion as by any perceived need to democratise it.
Of course, the alternative view is that programming is already democratised - I have seen the future and it is VB in Excel spreadsheets. /slits wrists
Programming is expressing what you want. It's much easier to express yourself using language than by drawing. Democratizing programming by removing coding is just like democratizing literature by replacing all the words with pictures.
>It's much easier to express yourself using language than by drawing.
I've done a lot of programming at the white board and it involved a lot of drawing. And I suck at drawing. But I was able to get my ideas across to others.
We don't have a lingua franca for diagrams like we do for text files.*
What is UML, then? If you feel stuck with this then maybe you need to look outside the text = code bubble and get some input on tool design from other sources. I agree that text is a convenient serialization and storage format, but it's a terrible design and analysis medium.
I mean, consider CSound, which is a tool for writing music with computers that has a venerable heritage going back to the 1970s. You have one set of code for defining the charactersistics of the sound, and another for defining the characteristic of the ntoes you play with those sounds: http://www.csounds.com/man/qr/score.htm and http://www.csounds.com/manual/html/index.html
CSound is a moderately good teaching tool, and given its heritage it's an impressive piece of technology. But nobody writes music in Csound except a few computer music professors and the students in their departments that have to do as part of their assignments, and 99% of music composed in CSound is a) dreadful and b) could have been done much faster on either a modular synthesizer or with Max/MSP. Electronic musicians feel the same way about CSound that you as a programmer would feel about an elderly relative that keeps talking about when everything was done with vacuum tubes and toggle switches...you respect it but it seems laughably primitive and has nothing to do with solving actual problems. The very few people that need low-level control on specific hardware platforms work in C or assembler.
I think this is pretty relevant here because one of Bret Victor's more impressive achievements is having written some very impressive operating software for a series of synthesizers from Alesis. I'd be pretty astonished if he even considered CSound for the task.
Far from being stuck in a bubble, I actually spent a couple years developing code in a UML-driven development environment (as in, I spent my days drawing UML diagrams that automatically turned into executable code). First of all, you cannot write any nontrivial program in UML alone. It is not nearly specific enough. UML is to a working program as a table of contents is to a technical manual. And in case you think I'm extrapolating from one bad experience, I've also used LabView have seen the parallel difficulties in that language.
Now, I agree that higher levels of abstraction will be needed in the future, but I disagree that visual programming is an obviously superior abstraction. In fact, I believe that people have been earnestly barking up that tree for decades with little success for reasons unrelated to old-fashioned attitudes. There are practical and technical reasons why developing visual programming tools and ecosystems will always be more difficult than developing text-based ones.
Take merging for example. Merging two versions of a source file is many times over a solved problem (not that there aren't new developments to be made). In contrast, merging two versions of a UML diagram is very much a manual process (to the extent that it's possible at all). Now consider creating a change management tool allows you to branch and merge UML diagrams. This is orders of magnitude harder yet. These are essential and straightforward use cases that are much more complex in a visual medium. Without these basic features, visual programming will not scale well to even medium-size teams.
I can go into more detail about issues with visual programming if I still haven't made my case. And I would love to hear from people with visual programming experience that have contradicting opinions. It's always possible that I missed something.
I appreciate the additional context and totally get where you're coming from. The only nitpick I'd make is this:
Merging two versions of a source file is many times over a solved problem
Granted - but isn't this also a limiting factor? It's not that I don't think anything should ever be reducible to code form, but why is that visual mapping of a complete program isn't a standard everyday tool? I mean, it's all very well that we have syntax highlighters showing keywords, variables and so on, but why is it that when I open a program there isn't a tool to automatically show me loops, arrays and so on?
Loops are one of the simplest programming structures; 90% of loops look like:
LOOP foo FROM bar to baz:
something
something
something
profit
foo = foo + 1
END LOOP
I mean, software engineering shouldn't be about syntax, it should be about structure, and yet there don't seem to be many tools around that open up a source file and build branching diagrams and loop modules automatically. Why is that? Why don't we even have structural highlighting rather than syntax highlighting?
Can you elaborate. I see the structure, in the indenting. My IDE (Visual Studio) has little lines and + boxes that allow me to collapse and expand code like this. It's useless, because the most part I kind of care what "something" is, and the collapse is not replaced with a nice pseudocode "frange the kibbleflits" statement. I have tools that can generate diagrams showing me class hierarchies, call stacks, and so on. I rarely (almost never) find the useful. Maybe you have something different in mind?
Modern IDEs are not text editors. They are heavily augmented with syntax highlighting, completion, code-folding, refactoring, squiggly red lines. This requires an IDE understanding your language and is effectively parsing the tokens as you type. I would suggest that a lot of the features we talk about have arrived already, it is just not explicit, and is tremendously complex to implement, simply because programmers are old die-hards and refuse to try different ideas.
Then there is the issue of reasoning about working systems. The job of the IDE ends when a software is built. If you encounter a bug though, having a runtime that has the smarts so that you can go in an poke around allow and even encourage experimentation, and improves comprehension.
Finally, there's the issue of code organization. A well artichected piece of software is tidy, because everything is in the right place. While a language-aware IDE can make sure you put the words in the right order, it has no concept of the architecture. A higher level DSL that is supported by the development environment directly might help. If we can somehow raise the abstraction level of the IDE, certain classes of programming problems could be as easy as filling in a form.
> Modern IDEs are not text editors. They are heavily augmented with syntax highlighting, completion, code-folding, refactoring, squiggly red lines.
How do any of those features make something 'not a text editor'? I'm pretty sure vim is still a text editor, and my vim does all of those things, with the possible exception of refactoring (and I'm not sure I want a program doing my refactoring in the first place).
A plane with auto-pilot may be still a plane, but the pilot's ability has been heavily augmented.
Incidentally, I spoke to a guy who had been developing Java on EMACs for 12 years. He tried Eclipse a month ago and was won over. Large languages - rightly or wrongly, like Java, benefit from having tight tool integration.
> It's because the above list of things are not trivial to get right...
It is a hard problem but solvable. We've been working on it for a few years. The "hardest" part was figuring out how to design away the need for complex interfaces (complex APIs). Once we solved this problem, it was a lot easier to build out a visual object language and associated framework (or lack thereof).
Something that is a bit difficult to figure out in a visual language is the merging of branches.
I would like to get your input on your experiences with visual coding in the past.
I think there are (at least) two very different kinds of talks: those that are meant to teach you worthwhile things, and those that are meant to inspire you to invent worthwhile things. All the talks I've seen from him are in the latter category.
His talks constantly feature working demos of the ideas he is pushing, subtly demonstrating a lot of well-thought-out interaction design details. If you watch his "Media for Thinking the Unthinkable" (http://vimeo.com/67076984) it's a gold mine of specifics. I've watched it several times and always pick some new ideas for my UI design work.
The difference to a run-of-the-mill talk is that he is showing the details, not telling the details.
I have the exact opposite reaction to the video. He is solving toy problems with toy ideas. I think his page Kill Math (http://worrydream.com/KillMath/) illuminates this point. I don't think he can think symbolically very well (no insult intended, I can't think visually very well). There are certainly times where graphing things make a lot of sense, but to throw out analytical math? Come on. By and large he is getting the "feel" of a system, but he cannot really reason about it, prove things about it, extend it, or design new systems with vision (there are obvious counterexamples).
In another video he shows an IDE where he scrubs constants, and it changes the behavior of the concurrently running program (changing the size of an ellipse or tree branch). It's neat. But, again, toy problem. First of all, we shouldn't be programming with constants. Second, anything complicated will have relationships between the data - scrubbing one value will just end up giving you nonsense. Third, it just doesn't make any sense in many contexts. I work in computer vision currently, and I can't think of anything but the most superficial way I could incorporate scrubbing. He made some comment about how no one could know what a bezier curve is unless they had a nice little picture of it in their IDE to match the function call. That's silly. I actually use splines and other curve fitting in my work, and I have to actually understand the math. Do I use cubic splines, a Hermite interpolation, bezier, or something else? I don't decide that by drawing some pictures - the search space is too big, I'll never cover all the possibilities. I have to do math to figure out the best choice.
In that same video he went on to demonstrate programming binary search using visual techniques. Unfortunately he wrote a buggy implementation, and stood there exclaiming how his visual technique found a different bug. It did, a super trivial one, but it completely failed to reveal the deeper issue. And, there was no real way for his visual method to have found it.
Visualization is an very powerful tool, but it is one tool in the toolchest. There is a scene in the movie Contact with Jodie Foster using headphones to listen to the SETI signal. We all know that is bogus - the search space is far too vast for aural search to work.
His ideas are terribly wrong headed. Make interfaces to help give us intuition? Absolutely! Use graphics where analytics fail. Of course! But don't conclude that math is a "freakish knack", as he does, or that math is some sort of temple (he calls mathematicians "clergy", and then goes on to throw in an insult that many are just pretending to understand).
I posted in another comment how crazy it would be to have a calculator that scrubs. Well, he shows one on that page. Really? The day bridge designers start using scrubbing apps to design our bridges is the day I'm never crossing a bridge again.
Edit to add: his website is another example of this. I can't find anything on it. There are a bunch of pictures, and my eyes saccade around, but what is here, what is his point? I dunno. I can click, and click, and click, and start to get an idea, but there is always more hidden away behind pictures. It's barely workable as a personal website, and would be a disaster as a way to organize anything larger. I don't mean to pick on it - as an art project or glimpse into how he thinks, it's great. I just point out it illustrates (pun kind of intended) the strengths and limits of visual presentation. You tell me, for example, without grep or google search, whether he has written about coffee.
If you disagree, please reply in pictures only! ;)
Is this an actual talk he gave in 1973 or is this a spoof or something?
If so, it seems he missed the mark (significantly) on web development.
He said "if in a few decades we get a document format on some sort of web of computers, I am sure we will be creating those documents by direct manipulation - there won't be any markup languages or stylesheets, that will make no sense."
So that is either very sarcastic and cheeky, or straight up wrong.
It's pure cheekiness. He is making the point that we're currently doing all sorts of things that would have seemed backwards to some researchers even 40 years ago.
It's not an actual talk or a spoof. It's probably best described as a farce because he's using a lot of irony to make his points. I guess you could call it sarcasm.
I think he's wrong as well. Often non-technical managers assume that since something is simple to describe, it will be simple to implement. This is the tech talk equivalent of that attitude.
Also, there are CMSs and WYSIWYG webpage creators that operate at various levels of success. Markup languages and stylesheets coexist partly because they meet different use cases. For example, I've never heard of a spec for a WYSIWYG "language", so you're guaranteed to have to deal with vendor lock-in and a lack of portability unless you can then generate some text documents in a standardized language.
Well, implementing the ideas we had 40 years ago using today's dogma took 40 years, so the fact that he doesn't specify his idea on replacing 40 years of engineering cruft in a 20 minute presentation can be overlooked, imho.
350 comments
[ 2.9 ms ] story [ 285 ms ] threadIn any field, the Establishment is seldom in pursuit of the truth, because it is composed of those who sincerely believe that they are already in possession of it.
From Probability Theory: The Logic of Science, E.T. Jaynes, 2003.
In my case, my work on Light Table has certainly proven at least one thing: what we have now is very far from where we could be. Programming is broken and I've finally come to an understanding of how we can categorize and systematically address that brokeness. If these ideas interest you, I highly encourage you to come to my StrangeLoop talk. I'll be presenting that next step forward: what a system like this would look like and what it can really do for us.
These are exciting times and I've never been as stoked as I am for what's coming, probably much sooner than people think.
EDIT: Here's the link to the talk https://thestrangeloop.com/sessions/tbd--11
Share a thought or two with the peons who won't/can't travel :)
I guess one thing I will say is that our definition of programming is all over the place right now and that in order for us to get anywhere we need to scale it back to something that simplifies what it means to program. We're bogged down in so much incidental complexity that the definitions I hear from people are convoluted messes that have literally nothing to do with solving problems. That's a bad sign.
My thesis is that given the right definition all of the sudden things magically "just work" and you can use it to start cleaning up the mess. Without giving too much away I'll say that it has to do with focusing on data. :)
I'm curious what you mean by data though. Is it data in the "big data" sense? What I mean is, are we talking about gathering a lot of data on coding? My approach is based on that, anyway: lots of data on code with a number of different analyzers (static and dynamic) that allows for extraction of common idioms and constraints, while allowing for the system to more easily help the user.
Of course, there's no magic and a lot of times I reach dead-ends, and while I'm eager to have enough to show the world, progress has been kinda slow lately.
Looking forward for your talk, be sure to link here on HN.
That's what inspired me to work on my [nameless graph language](http://nickretallack.com/visual_language/#/ace0c51e4ee3f9d74...). I thought it would be simpler to express a program by connecting information sinks to information sources, instead of ordering things procedurally. By using a graph, I could create richer expressions than I could in text, which allowed me to remove temporary variables entirely. By making names irrelevant, using UUIDs instead, I no longer had to think about shadowing or namespacing.
Also, by avoiding text and names, I avoid many arguments about "coding style", which I find extremely stupid.
I find that people often argue about programming methodologies that are largely equivalent and interchangeable. For example, for every Object Oriented program, there is an equivalent non-object-oriented program that uses conditional logic in place of inheritance. For every curried program, there is an equivalent un-curried program that explicitly names its function arguments. In fact, it wouldn't even be that hard to write a program to convert from one to the other.
I'm pretty excited about the array of parallel processors in the presentation though. If we had that, with package-on-package memory for each one, message passing would be the obvious way to do everything. Not sure how to apply this to my own language yet, but I'll think of something.
The closest things to my language that I have seen are Kismet and UScript. Mine is different though because it is lazily evaluated and uses recursion as the only method of looping.
Some other things that look superficially similar such as Quartz Composer, ThreeNode, PureData, etc. are actually totally different animals. They are more like circuit boards, and my language is a lot more like JavaScript.
I've been trying to do something similar with a pet language :) Human names should never touch the compiler, they are annotations on a different layer.
But writing an editor for such a programming environment with better UX and scalability than a modern text-based editor is... an engineering challenge.
It's not perfect, and making lambdas is still a little awkward because I haven't made them resizable. Also, eventually I'd like the computer to automatically arrange and scale the nodes for you, for maximum readability. But I think it's pretty fun to use. It'd probably be even more fun on an iPad.
I'd love to make my IDE as fun to use as DragonBox
It would be good if, while clicking and dragging a new connection line that will replace an old one, the latter's line is dimmed to indicate that it will disappear. Also, those blue nodes need a distinguishing selection color.
It sounds like you're aiming more toward a fun tablet-usable interface, but:
Have you thought about what it would take to write large programs in such an editor? For small fun programs a graph visualization is cool, but larger programs will tend toward a nested indented structure (like existing text) for the sake of visual bandwidth, readability of mathematical expressions, control flow, etc.
Use the arrow keys to move the box around. I suppose that's still a bit primitive, but I'll make some more involved programs once I fix up the scoping model a bit.
When I first started on this project, I thought at some point I would need to make a "zoom out" feature, because you might end up making a lot of nodes in one function. However, I have never needed this. As soon as you have too much stuff going on, you can just box-select some things and hit the "Join" button to get a new function. The restricted workspace actually forces you to abstract things more, and the lack of syntax allows you to reduce repetition more than would be practical in a textual language.
For example, in textual languages, reducing repetition often requires you to introduce intermediate variables, which could actually make the program's text longer, so people will avoid doing it. However, in my language you get intermediate variables by connecting two sinks to the same source. The addition in program length hardly noticeable.
I don't think it is possible to make a program without conditional branches.
Somebody posted a link below about "Data Driven" design in C++. In it was an example of a pattern where each object has a "dirty" flag, which determines whether it needs processing, but they found that failing branch prediction here took more cycles than simply removing the branch.
My thought was, instead, what if you created two versions of that method -- one to represent when the dirty flag is true, and another to represent when the dirty flag is false -- and then instead of toggling the dirty flag, you could change the jump address for that method to point to the version it should use. If this toggle happens long enough before the the processor calls that method, you would remove any possibility of branch prediction failure =].
I have no idea if this is practical or not, but it is amusing to consider programs that modify jump targets instead of using traditional conditional branches.
Read more: http://en.wikipedia.org/wiki/Branch_predication EDIT: Also: http://en.wikipedia.org/wiki/Branch_predictor
I think we more commonly use the latter, which tries to guess which way the code will branch and load the appropriate jump target. It's actually typically very successful in modern processors.
(PS angular-js has done all that dirty flag checking if you like that approach)
Chuck Moore, the inventor of Forth, is working on these processors.
http://www.greenarraychips.com/home/products/index.html
It hasn't been an easy road.
http://colorforth.com/blog.htm
Max/MSP, Pure Data, vvvv, meemoo, Quartz Composer, Touch Designer, LabView, Grasshopper, WebAudioToy, just to name a few.
I'm used to JavaScript, so that's what I based my language on. It's really a traditional programming language in disguise, kinda like JavaScript with some Haskell influence. It's nothing like a dataflow language. On that front, perhaps those languages are a lot more avante-guarde than mine.
In the same way that HN frowns upon stealth startups, shouldn't we frown upon 'stealth theories'? If your thoughts are novel and deep enough, revealing something about them will only increase interest in your future talks, since you are definitionally the foremost thinker in your unique worldview. If the idea fails scrutiny in some way, you should want to hear about it now so you can strengthen your position.
What's the downside, outside of using mystery to create artificial hype?
I agree.
For example, people do seem to assume that programming must involve, in some way, coding. Do we really need to code in some programming-language to be programming?
Changing security settings, for example, in a browser lead to quite different behaviors of the program. Isn't the user of the browser programming because they change the behavior of the program?
And this leads to....
> with focusing on data
If we focus on data, and hopefully better abstractions on how to manipulate that data, then wouldn't any user able to alter a program because they can adjust "settings" at almost any point within the program: in real time.
Wouldn't this then enable a lot more people to become programmers?
Anyway, just some thoughts.
A program is the result of the automation of some process (system) that people have thought up (even things that couldn't exist before computers). Programming is the act of taking that process (system) and describing it in a computing device of some kind.
Programming currently requires some kind of mapping from the "real world" to the "computer world". The current mapping is done primarily with source code. So, it currently seems that people who are good at programming are good at mapping from the "real world" into the "computer world" via coding.
You seem to be making the point that some people are just good at programming because they can do things like "re-discover the bubble sort algorithm" or understand CAP theorem. These are very domain specific problems.
For people who are able to "re-discover inventory control management" they would do a great job of automating it (programming) if they had an easier way to map that process (system) to a computing device.
The ultimate goal (other than maybe AI) is a 1-to-1 mapping between a "real world" process (system) and a computing device that automates it.
I think, the differences between reading and writing code are as big as sending and receiving packets. It's difficult to write code that extrapolates the base information in your head driving the decisions. Not only that, but you also have to juggle logic puzzles as you're doing it. And on the other side, you have to learn new domain languages (or type hierarchies), as well as what the program is supposed to do in the first place.
I think the idea of interacting with code as you build it is great, but how can we do that AND fix the information gap at the same time?
I'll (hopefully) be looking forward to a vid of it on infoq at some point. :)
Either way, looking forward too it!
Programming in APL, for me at least, was like entering into a secondary zone after you were in the zone. The first step is to be in the "I am now focused on programming" zone. Then there's the "I am now in my problem space" zone. This is exactly how it works with APL.
I used the language extensively for probably a decade and nothing has ever approached it in this regard. Instead we are mired in the innards of the machine, micromanaging absolutely everything with incredible verbosity and granularity.
I really feel that for programming/computing to really evolve to another level we need to start loosing some of the links to the ancient world of programming. There's little difference between what you had to do with a Fortran program and what you do with some of the modern languages in common use. That's not he kind of progress that is going to make a dent.
http://www.jdl.ac.cn/turing/pdf/p444-iverson.pdf
Not that I dislike the idea -- on the contrary, I'm inclined to conclude from my excitement over this and Haskell that I dislike success...
On a related note, if one plans to sell the Language of The Future Of Programming, I swear this thing will know the same fate as Planner, NLS, Sketchpad, Prolog, Smalltalk and whatnot if it cannot help me with the problems I have to solve just tomorrow.
It's mostly good for being able to express mathematical formulas with very little translation from the math world - "executable proofs," I think the quote is - and having matrices of arbitrary dimension as first-class values is unusual if not unique. But for any practical purpose it's to Haskell what Haskell is to Java.
Can you elaborate on this? As I understand, the core strengths of APL are succinct notation, built-in verbs which operate on vectors/matrices, and a requirement to program in a point-free style. All of this can be done in Haskell.
A Haskell programmer unfamiliar with APL looks at an APL program and...
Of course, understanding the individual symbols is a different matter, but hardly requiring a conceptual leap.
And says "what's the big deal?". That's exactly the question, what is the big deal. APL isn't scary, I'm not shouting "I can't make sense of this", I am asking "how is this better than haskell in the same way haskell is better than java?".
Your question is fine, but not what he meant by the analogy.
Now, I didn't learn APL from a tutorial, I learned it (in 1976) from a book. This book: http://www.jsoftware.com/papers/APL.htm from 1962.
If my memory hasn't been completely corrupted by background radiation, I've seen papers as early as the mid 1950s about this notation.
APL started out as a notation for expressing computation (this is not precise but good enough). As far as I'm concerned it's sitting at a level of abstraction higher than Haskell (arguably like a library overtop Haskell).
Now, in the theme of this thread, APL was able to achieve all of this given the constraints at the time.
The MCM/70 was a microprocessor based laptop computer that shipped in 1974 (demonstrated in 1972, some prototypes delivered to customers in 1973) and ran APL using an 80 kHz (that kilo) 8008 (with a whole 8 bytes of stack) with 2 kBytes (that's kilo) RAM or maxed out at 8 kB (again, that's kilo) of RAM. This is a small slow machine that still ran APL (and nothing else). IEEE Annals of Computer History has this computer as the earliest commercial, non-kit personal computer (IEEE Annals of the History of Computing, 2003: pg. 62-75). And, I say again, it ran APL exclusively.
Control Data dominated the super computer market in the 70s. The CDC 7600 (designed by Cray himself, 36.4 MHz with 65 kWord (a word was some multiple of 12 bits, probably 60 bits but I'm fuzzy on that) and about 36 MFLOPS according to wikipedia) was normally programmed in FORTRAN. In fact, this would be a classic machine to run FORTRAN. However, the APL implementation available was often able to outperform it, almost always when coded by an engineer (and I mean like civil, mechanical, industrial, etc engineer, not a software engineer) rather than someone specialising in writing fast software.
I wish everyone would think about what these people accomplished given those constraints. And think about this world and think again about Bret Victor's talk.
Were those destroyed tutorials published books?
EDIT: I just opened the drop down on the paper covered versions. Prices between $34.13 and $1806.23!!! Is that real?!? Wow, I had five or six copies of something that seems to be incredibly valuable. Too late for an insurance claim on that basement flood.
This is one area where Haskell really shines. If you want the machine to be able to do what you want without micromanaging how, than you need a way to formally specify what you mean in an unambiguous and verifiable way. Yet it also needs to be flexible enough to cross domain boundaries (pure code, IO, DSLs, etc).
Category theory has been doing exactly that in the math world for decades, and taking advantage of that in the programming world seems like a clear way forward.
The current state of the industry seems like team of medieval masons (programmers) struggling to build a cathedral with no knowledge of physics beyond anecdotes that have been passed down the generations (design patterns), while a crowd of peasants watch from all angles to see if the whole thing will fall down (unit tests).
Sure, you might be able to build something that way, but it's not exactly science, is it?
Gimme a break.
A better analogy would be being mad that the Tesla can't drive on the interstate.
Don't confuse local maxima for maxima. We need people exploring other slopes for the chance of an apex, or at least some higher local maxima.
We had some great discussions at LIXD a couple of weeks ago, wish you could have been there. Everyone seems to be reinventing programming these days. We are definitely in competition to some extent. The race is on.
That's exactly what I'm up to :)
http://stackoverflow.com/questions/15214526/why-hypermedia-a...
"'The most dangerous thought you can have a creative person is to think you know what you're doing.'
It's possible to misinterpret what I'm saying here. When I talk about not knowing what you're doing, I'm arguing against "expertise", a feeling of mastery that traps you in a particular way of thinking.
But I want to be clear -- I am not advocating ignorance. Instead, I'm suggesting a kind of informed skepticism, a kind of humility.
Ignorance is remaining willfully unaware of the existing base of knowledge in a field, proudly jumping in and stumbling around. This approach is fashionable in certain hacker/maker circles today, and it's poison."
> Learn tools, and use tools, but don't accept tools. Always distrust them; always be alert for alternative ways of thinking. This is what I mean by avoiding the conviction that you "know what you're doing".
These two statements have done a better job explaining my feelings on expertise than almost any of my attempts. Thank you, Bret.
Any more abstraction on this statement?
I'm interpreting it as "don't try new things because you don't know what you're doing", which just so happens to feel like the exact opposite of what Bret is trying to convey.
I don't think it's cautioning against diving in prematurely. It's cautioning against thinking you'll do better than those who have come before by pure virtue of not knowing what yhey've done.
This guy is not a good or great or fabulous computer scientist, this guy is something else entirely. He's a true creative Thinker. He doesn't have a vision, he's got tons of them. Every subject he starts thinking about he comes with new ideas.
He shouldn't be doing presentations, he should run a company.
Woody Allen did this great movie some time ago, "Midnight in Paris", where the main character, living in present times, dreams of moving back in time to the 1920s as the best time for literature ever. When the occasion to really go back appears though, he discovers the writers of the 1920s thought the best literature was done in 1890s, and so he has to go back again, then again, ... This talk is like this, sentiment blinding a sober assessment.
I loved that movie, but I don't think it is too relevant here. I mean, you can rediscover and read any literature written in the 20s or the 1890s, which is exactly what our field is not doing.
Look at the languages that come out of academia, then look at the languages that have been invented over the last few decades which have gained traction. The latter list includes a lot of crazy items, things like Perl, PHP, Javascript, Ruby, and Python.
Some of them with their merits but for the most part hugely flawed, in some cases bordering on fundamentally broken. But what do they have in common? They were all invented by people needing to solve immediate problems and they are all designed to solve practical problems. Interestingly, Python was invented while its author was working for a research institute but it was a side project.
The point being: languages invented by research organizations tend to be too distanced from real-world needs of everyday programmers to be even remotely practical. Which is why almost all of the new languages invented over the past 3 decades that have become popular have either been created by a single person or been created by industry.
I agree with the denotation of your comment, but I disagree with its connotation. We need more long term, and less "practicality".
He is pointing out experts tend to deny a perfectly valid way of exploring technology, because it doesn't follow the defined community-accepted standards built on assumptions of hardware and efficiency.
He's not not knocking the current model, he's not even saying these other models shouldn't have died, he's saying they shouldn't be forgotten and should often be reexamined in light of new technology which might make a better home for it.
Yes, he is actually, repeatedly. For instance, at 9:30 in the video: "There won't be any, like, markup languages, or stylesheet languages, right? That would make no sense".
But the same philosophy is used in the softer analytics, where using state of the art really is better. Sure giant clunky Excel sheets _work_, but we can build far better charting tools. We can run statistics easier than MiniTab. Data can be interactive, searchable, and computable instead of rituals and incantations to lousy proprietary one-off enterprise buzz-word-a-tron programs.
We _could_ be using analytical tools that shape themselves to the data. Instead, we have to convince management that it's _possible_ to analyze and map data easily in these new ways. But once they see how much more powerful these ideas are - how much faster and cheaper they work - lower mgt. is thrilled. And if upper management is profit oriented, they'll like it too.
*marketing defined as clearly communicating the benefits of the product/technology.
http://dbpokorny.blogspot.com/2013/07/permission-based-progr...
Like Bret's other talk, "Inventing on Principle", this talk has affected me deeply. I don't want this anymore. I want to invent the future.
For my own part I would also look into metaphor based research. By this I mean that looking to Biology for metaphors worked really well for OO programming so do the same thing here. Humans have been dealing with the mapping of their native language to that of another language for centuries now. I am sure that amongst anthropologists and linguists there is a pretty good body of research on how "first-contact" communication has been accomplished in the past and probably people have attempted to figure out principles to apply as well. There is probably a lot of fertile field here to till from a computer science perspective. NASA might have even sponsored some interesting research in this field, how did we design the voyager plaque, for instance.
This specialization, in my opinion, is the root cause problem in programming computing systems.
Bret Victor had this to say "The only way it (communication between systems) can scale, they (computers) have to figure out (dynamically), a common language".
Here I feel he is missing a key point. It is not a common language we are looking for, but a common architecture by which information is communicated between systems. Or, in this case, a non-architecture or anti-API by which communication takes place between systems.
His analysis of the "API" problem reminds me of some of the ideas Jaron Lanier was floating around about ten years ago. I can't recall the name of it, but it was some sort of biologically inspired handshake mechanism between software 'agents'.
What I think such things require is an understanding of what is lacking in order to search for it; as near as I can tell, that requires some fashion of self-awareness. This, as far as I can conceive, recurses into someone writing code, whether it be Planner or XML. But my vision is cloudy on such matters.
I should note that I think Brett is one of the leading thinkers of his (my) generation, and have a lot of respect for his ideas.
http://discovermagazine.com/2007/jul/jaron2019s-world
I dug around for a bit when I came across the idea but never could figure out where the reification of the idea went.
I'll eyeball RNA, but at first glance it doesn't appear quite the same idea.
The reason we still code in text is because visual programming is not a hard problem -- it's a dozen hard problems. Think about all of the tools we use to consume, analyze, or produce textual source code. There are code navigators, searchers, transformers, formatters, highlighters, versioners, change managers, debuggers, compilers, analyzers, generators, and review tools. All of those use cases would need to be fulfilled. Unlike diagrams, text is a convenient serialization and storage format, you can leverage the Unix philosophy to use the best of breed of the tools you need. We don't have a lingua franca for diagrams like we do for text files.
It's not due to dogma or laziness that we use text to write code. It's because the above list of things are not trivial to get right and making them work on pictures is orders of magnitude harder than making them work with text.
EDIT: Wordsmithing
YES! YES! YES! I CAN SEE IT! KEEP GOING! YOU'RE A GENIUS! TELL IT, BROTHER!
"Visual programming . . ."
Oh, for God's sake . . .
Programming needs to be Democratized and I think one of the best ways to do this is by removing coding as a necessary step in programming process.
In my opinion, the ability for someone to take a few observations about the world around them and turn it into something new and amazing is what makes them brilliant.
We are now at a point in history where a lot of people are able to take in a lot of different ideas leading to a lot of new discoveries (one of the reasons why I think new technology is now being created at an almost exponential rate).
You seem to be implying that a particular problem can't be solved because brilliant people in the past have not solved it yet. In my opinion, problems aren't solved yet because someone has not "connected the dots" yet.
Every step in the development process moves those people with the domain-expertise/vision/creative process/etc. further from the solution. Removing steps, like coding, brings the solution closer to the domain experts/visions/create process/etc.
Visual programming makes it a lot easier for people to work collaboratively. For example, those with the domain-expertise can work closer with those that have programming experience in a visual language.
Just a few ways that visual languages could democratize programming.
> why bother with the visual notation instead of just putting it in text they understand equally well?
Consistency of implementation - even across different domains.
Learning/Thinking - different people learn and think in different ways (Visual Learning - https://en.wikipedia.org/wiki/Visual_learning, Auditory Learning - https://en.wikipedia.org/wiki/Auditory_learning, Kinesthetic Learning - https://en.wikipedia.org/wiki/Kinesthetic_learning)
Ease of Use - It is not possible to have syntax errors. (Logical errors/misunderstandings of the problem being solved are still possible).
I'm not quite sure what "text they understand" means. Are you talking about natural language interpreters (as you mention above)? That would/will be some cool technology and my feeling is that it is a "next step" in software evolution. Maybe, more likely, the next step is a planned or constructed language interpreter (http://en.wikipedia.org/wiki/Constructed_language). Natural language is so tricky (but maybe not for very domain specific problems).
If it targets, say, a visual learner, I think a graph language won't help unless they are already visualising the program as a graph.
Do I think that in 40 years or 100 years we will still be coding in a way that is compatible with using vim? Probably. And I don't see how that makes programming less "democratic".
At one time iterators were considered a technique and a design pattern. Now, they are a part of most languages. They are transparent. They are taken for granted.
Currently, programming takes place within the domain of software development. It is not surprising then that we value advanced techniques within the industry. Just like there are advanced techniques that are used within the domains of electrical engineering, mechanical engineering and biology (just to name a few).
As we get better at our job as programmers, we further make our "advanced techniques" transparent to those that use our systems. Sure, currently, these systems are usually very domain specific. However, there is nothing to say that we can not build better software development environments which are both non-domain specific and, at the same time, hide the underlying complexities that require experienced developers.
In my opinion, these development environments would use a type of visual language enabling a lot more people to program. I am biased because this is a problem I've been working on for quite a few years now.
If we can teach kids to analyse process, teaching them a programming language, whatever the paradigm, is trivial.
I have no idea what coding will look like in 40 years (although a very solid percentage of it will be no different to now) but it will be driven as much by fashion as by any perceived need to democratise it.
Of course, the alternative view is that programming is already democratised - I have seen the future and it is VB in Excel spreadsheets. /slits wrists
I've done a lot of programming at the white board and it involved a lot of drawing. And I suck at drawing. But I was able to get my ideas across to others.
This might also be of interest: http://www.agilemodeling.com/essays/communication.htm.
You might also want to consider that people learn and communicate best in different ways:
* Visual Learning - https://en.wikipedia.org/wiki/Visual_learning * Auditory Learning - https://en.wikipedia.org/wiki/Auditory_learning * Kinesthetic Learning - https://en.wikipedia.org/wiki/Kinesthetic_learning
and others.
A mischaracertization. Software like Reaktor is extremely successful in its domain and widely deployed: http://www.native-instruments.com/en/products/komplete/synth... as is Max/MSP: http://cycling74.com/videos/product/
We don't have a lingua franca for diagrams like we do for text files.*
What is UML, then? If you feel stuck with this then maybe you need to look outside the text = code bubble and get some input on tool design from other sources. I agree that text is a convenient serialization and storage format, but it's a terrible design and analysis medium.
I mean, consider CSound, which is a tool for writing music with computers that has a venerable heritage going back to the 1970s. You have one set of code for defining the charactersistics of the sound, and another for defining the characteristic of the ntoes you play with those sounds: http://www.csounds.com/man/qr/score.htm and http://www.csounds.com/manual/html/index.html
CSound is a moderately good teaching tool, and given its heritage it's an impressive piece of technology. But nobody writes music in Csound except a few computer music professors and the students in their departments that have to do as part of their assignments, and 99% of music composed in CSound is a) dreadful and b) could have been done much faster on either a modular synthesizer or with Max/MSP. Electronic musicians feel the same way about CSound that you as a programmer would feel about an elderly relative that keeps talking about when everything was done with vacuum tubes and toggle switches...you respect it but it seems laughably primitive and has nothing to do with solving actual problems. The very few people that need low-level control on specific hardware platforms work in C or assembler.
I think this is pretty relevant here because one of Bret Victor's more impressive achievements is having written some very impressive operating software for a series of synthesizers from Alesis. I'd be pretty astonished if he even considered CSound for the task.
Now, I agree that higher levels of abstraction will be needed in the future, but I disagree that visual programming is an obviously superior abstraction. In fact, I believe that people have been earnestly barking up that tree for decades with little success for reasons unrelated to old-fashioned attitudes. There are practical and technical reasons why developing visual programming tools and ecosystems will always be more difficult than developing text-based ones.
Take merging for example. Merging two versions of a source file is many times over a solved problem (not that there aren't new developments to be made). In contrast, merging two versions of a UML diagram is very much a manual process (to the extent that it's possible at all). Now consider creating a change management tool allows you to branch and merge UML diagrams. This is orders of magnitude harder yet. These are essential and straightforward use cases that are much more complex in a visual medium. Without these basic features, visual programming will not scale well to even medium-size teams.
I can go into more detail about issues with visual programming if I still haven't made my case. And I would love to hear from people with visual programming experience that have contradicting opinions. It's always possible that I missed something.
Merging two versions of a source file is many times over a solved problem
Granted - but isn't this also a limiting factor? It's not that I don't think anything should ever be reducible to code form, but why is that visual mapping of a complete program isn't a standard everyday tool? I mean, it's all very well that we have syntax highlighters showing keywords, variables and so on, but why is it that when I open a program there isn't a tool to automatically show me loops, arrays and so on?
Loops are one of the simplest programming structures; 90% of loops look like:
I mean, software engineering shouldn't be about syntax, it should be about structure, and yet there don't seem to be many tools around that open up a source file and build branching diagrams and loop modules automatically. Why is that? Why don't we even have structural highlighting rather than syntax highlighting?Code Bubbles: http://www.andrewbragdon.com/codebubbles_site.asp
:)
Then there is the issue of reasoning about working systems. The job of the IDE ends when a software is built. If you encounter a bug though, having a runtime that has the smarts so that you can go in an poke around allow and even encourage experimentation, and improves comprehension.
Finally, there's the issue of code organization. A well artichected piece of software is tidy, because everything is in the right place. While a language-aware IDE can make sure you put the words in the right order, it has no concept of the architecture. A higher level DSL that is supported by the development environment directly might help. If we can somehow raise the abstraction level of the IDE, certain classes of programming problems could be as easy as filling in a form.
How do any of those features make something 'not a text editor'? I'm pretty sure vim is still a text editor, and my vim does all of those things, with the possible exception of refactoring (and I'm not sure I want a program doing my refactoring in the first place).
Incidentally, I spoke to a guy who had been developing Java on EMACs for 12 years. He tried Eclipse a month ago and was won over. Large languages - rightly or wrongly, like Java, benefit from having tight tool integration.
It is a hard problem but solvable. We've been working on it for a few years. The "hardest" part was figuring out how to design away the need for complex interfaces (complex APIs). Once we solved this problem, it was a lot easier to build out a visual object language and associated framework (or lack thereof).
Something that is a bit difficult to figure out in a visual language is the merging of branches.
I would like to get your input on your experiences with visual coding in the past.
His talks constantly feature working demos of the ideas he is pushing, subtly demonstrating a lot of well-thought-out interaction design details. If you watch his "Media for Thinking the Unthinkable" (http://vimeo.com/67076984) it's a gold mine of specifics. I've watched it several times and always pick some new ideas for my UI design work.
The difference to a run-of-the-mill talk is that he is showing the details, not telling the details.
I have the exact opposite reaction to the video. He is solving toy problems with toy ideas. I think his page Kill Math (http://worrydream.com/KillMath/) illuminates this point. I don't think he can think symbolically very well (no insult intended, I can't think visually very well). There are certainly times where graphing things make a lot of sense, but to throw out analytical math? Come on. By and large he is getting the "feel" of a system, but he cannot really reason about it, prove things about it, extend it, or design new systems with vision (there are obvious counterexamples).
In another video he shows an IDE where he scrubs constants, and it changes the behavior of the concurrently running program (changing the size of an ellipse or tree branch). It's neat. But, again, toy problem. First of all, we shouldn't be programming with constants. Second, anything complicated will have relationships between the data - scrubbing one value will just end up giving you nonsense. Third, it just doesn't make any sense in many contexts. I work in computer vision currently, and I can't think of anything but the most superficial way I could incorporate scrubbing. He made some comment about how no one could know what a bezier curve is unless they had a nice little picture of it in their IDE to match the function call. That's silly. I actually use splines and other curve fitting in my work, and I have to actually understand the math. Do I use cubic splines, a Hermite interpolation, bezier, or something else? I don't decide that by drawing some pictures - the search space is too big, I'll never cover all the possibilities. I have to do math to figure out the best choice.
In that same video he went on to demonstrate programming binary search using visual techniques. Unfortunately he wrote a buggy implementation, and stood there exclaiming how his visual technique found a different bug. It did, a super trivial one, but it completely failed to reveal the deeper issue. And, there was no real way for his visual method to have found it.
Visualization is an very powerful tool, but it is one tool in the toolchest. There is a scene in the movie Contact with Jodie Foster using headphones to listen to the SETI signal. We all know that is bogus - the search space is far too vast for aural search to work.
His ideas are terribly wrong headed. Make interfaces to help give us intuition? Absolutely! Use graphics where analytics fail. Of course! But don't conclude that math is a "freakish knack", as he does, or that math is some sort of temple (he calls mathematicians "clergy", and then goes on to throw in an insult that many are just pretending to understand).
I posted in another comment how crazy it would be to have a calculator that scrubs. Well, he shows one on that page. Really? The day bridge designers start using scrubbing apps to design our bridges is the day I'm never crossing a bridge again.
Edit to add: his website is another example of this. I can't find anything on it. There are a bunch of pictures, and my eyes saccade around, but what is here, what is his point? I dunno. I can click, and click, and click, and start to get an idea, but there is always more hidden away behind pictures. It's barely workable as a personal website, and would be a disaster as a way to organize anything larger. I don't mean to pick on it - as an art project or glimpse into how he thinks, it's great. I just point out it illustrates (pun kind of intended) the strengths and limits of visual presentation. You tell me, for example, without grep or google search, whether he has written about coffee.
If you disagree, please reply in pictures only! ;)
Does anyone have an explanation for this reference? It was at the end of the concurrency section, while talking about the distributed graph model.
~27:20
http://en.wikipedia.org/wiki/Erlang_%28programming_language%...
http://en.wikipedia.org/wiki/Open_Telecom_Platform
If so, it seems he missed the mark (significantly) on web development.
He said "if in a few decades we get a document format on some sort of web of computers, I am sure we will be creating those documents by direct manipulation - there won't be any markup languages or stylesheets, that will make no sense."
So that is either very sarcastic and cheeky, or straight up wrong.
What am I missing?
I was wondering how comes the audience (and video) seems so "current", but the content looks so dated.
I think he's wrong as well. Often non-technical managers assume that since something is simple to describe, it will be simple to implement. This is the tech talk equivalent of that attitude.
Also, there are CMSs and WYSIWYG webpage creators that operate at various levels of success. Markup languages and stylesheets coexist partly because they meet different use cases. For example, I've never heard of a spec for a WYSIWYG "language", so you're guaranteed to have to deal with vendor lock-in and a lack of portability unless you can then generate some text documents in a standardized language.
I also think rational decision making requires some predictions and successful trials before confirming any theses.