Absolutely. I was waiting for him to mention what I think of as the Unix/Plan 9/REST principle the whole time. IMO this is one of the most important concepts in computing, but too few people are explicitly aware of it. Unfortunately he didn't mention it.
Really what Victor is complaining about is the web. He doesn't like the fact that we are hand-coding HTML and CSS in vim instead of directly manipulating spatial objects. (Although HTML is certainly declarative. Browsers actually do separate intent from device-specific details. We are not writing Win32 API calls to draw stuff, though he didn't acknowledge that.)
It has been impressed on me a lot lately how much the web is simply a distributed Unix. It's built on a file-system-like addressing scheme. Everything is a stream of bytes (with some additional HTTP header metadata). There are bunch of orthogonal domain-specific languages (HTML/CSS/etc vs troff/sed/etc). They both have a certain messiness, but that's necessary and not accidental.
This design is not accidental. It was taken from Unix and renamed "REST". The Unix/Plan 9/REST principle is essentially the same as the Alan Perlis quote: "It is better to have 100 functions operate on one data structure than 10 functions on 10 data structures." [1] The single data structure is the stream of bytes, or the file / file descriptor.
For the source code example, how would you write a language-independent grep if every language had its own representation? How about diff? hg or git? merge tools? A tool to jump to source location from compiler output? It takes multiple languages to solve any non-trivial problem, so you will end up with an M x N combinatorial explosion (N tools for each of M languages), whereas you want M + N (M languages + N tools that operate on ALL languages).
Most good programming languages have the same flavor -- they are built around a single data structure. In C, this is the pointer + offset (structs, arrays). In Python/Lua it's the dictionary. In R it's the data frame; in Matlab it's the matrix. In Lisp/Scheme it's the list.
Java and C++ tend to have exploding codebase size because of the proliferation of types, which cause the M * N explosion. Rich Hickey has some good things to say about this.
I would posit that Windows and certain other software ecosystems have reached a fundamental scaling limit because of the O(M*N) explosion. Even if you have $100 billion, you can't write enough code to cover this space.
Another part of this is the dichotomy between visually-oriented people and language-oriented people. A great read on this schism is: http://www.cryptonomicon.com/beginning.html . IMO language-oriented tools compose better and abstract better than visual tools. In this thread, there is a great point that code is not 2D or 3D; it has richer structure than can really be represented that way.
I really like Bret Victor's talks and ideas. His other talks are actually proposing solutions, and they are astounding. But this one comes off more as complaining, without any real solutions.
He completely misunderstands the reason for the current state of affairs. It's NOT because we are ignorant of history. It's because language-oriented abstractions scale better and let programmers get things done more quickly.
That's not to say this won't change, so I'm glad he's working on it.
> Most good programming languages have the same flavor -- they are built around a single data structure. In C, this is the pointer + offset (structs, arrays). In Python/Lua it's the dictionary. In R it's the data frame; in Matlab it's the matrix. In Lisp/Scheme it's the list.
Lists are not very important for Lisp, apart from writing macros.
> Java and C++ tend to have exploding codebase size because of the proliferation of types, which cause the M * N explosion. Rich Hickey has some good things to say about this.
Haskell has even more types, and no exloding codebases. The `M * N explosion' is handled differently there.
> For the source code example, how would you write a language-independent grep if every language had its own representation? How about diff? hg or git? merge tools? A tool to jump to source location from compiler output? It takes multiple languages to solve any non-trivial problem, so you will end up with an M x N combinatorial explosion (N tools for each of M languages), whereas you want M + N (M languages + N tools that operate on ALL languages).
You'd use plugins and common interfaces. (I'm all in favour of text, but the alternative is still possible, if hard.)
> Lists are not very important for Lisp, apart from writing macros.
I'm not sure I agree. Sure, in most dialects you are given access to Arrays, Classes, and other types that are well used. And you can choose to avoid lists, just like you can avoid using dictionaries in Python, and Lua. But I find that the cons cell is used rather commonly in standard Lisp code.
You can't --really-- avoid dictionaries in python, as namespaces and classes actually are dictionaries, and can be treated as such.
In Lua, all global variables are inserted into the global dictionary _G, which is accessible at runtime. This means you can't even write a simple program consisting of only functions becouse they are all added and exectued from that global dictionary.
There where also other languages which could have been mentioned. In Javascript for instance, functions and arrays are actually just special objects/dictionaries. You can call .length on a function, you can add functions to the prototype of Array.
I think Haskell handles the combinations explosion with its polymorphic types and higher-order abstractions. There are many, many types, but there are also abstractions over types. Java/C++ do not get that. `sort :: Ord a => [a] -> [a]` works for infinite amount of types that have `Ord` instance.
I don't agree that lists are not very important for Lisp, they're essential for functional programming as we know it today.
It's not an either-or. My prediction is that Victor's tools will be an optional layer on top of text-based representations. I'd go as far as to say that source code will always be represented as text. You can always build Visual Studio and IntelliJ and arbitrarily complex representations on top of text. It's just that it takes a lot of engineering effort, and the tools become obsolete as new languages are developed. We HAD Visual Studio for VB; it's just that everyone moved onto the web and Perl/Python/Ruby/JS, and they got by fine without IDEs.
There are people trying to come up with a common structured base for all languages. The problem is that if it's common to all languages, then it won't offer much more than text does. Languages are that diverse.
I don't want to get into a flame war, but Haskell hasn't passed a certain threshold for it to be even considered for the problem of "exploding code base size". That said, the design of C++ STL is basically to avoid the M*N explosion with strong types. It is well done but it also causes a lot of well-known problems. Unfortunately most C++ code is not as carefully designed as the STL.
>I don't want to get into a flame war, but Haskell hasn't passed a certain threshold for it to be even considered for the problem of "exploding code base size".
What threshold?
>It is well done but it also causes a lot of well-known problems.
Like what? And why do you assume those problems are inherent to having types?
>Java and C++ tend to have exploding codebase size because of the proliferation of types, which cause the M * N explosion.
I think haskell and friends demonstrate that your explanation for java and C++ "exploding" is incorrect. Haskell is all about types, lots of types, and making your own types is so basic and simple that it happens all the time everywhere. Yet, there is no code explosion.
Really what Victor is complaining about is the web. He doesn't like the fact that we are hand-coding HTML and CSS in vim instead of directly manipulating spatial objects. (Although HTML is certainly declarative. Browsers actually do separate intent from device-specific details. We are not writing Win32 API calls to draw stuff, though he didn't acknowledge that.)
It has been impressed on me a lot lately how much the web is simply a distributed Unix. It's built on a file-system-like addressing scheme. Everything is a stream of bytes (with some additional HTTP header metadata). There are bunch of orthogonal domain-specific languages (HTML/CSS/etc vs troff/sed/etc). They both have a certain messiness, but that's necessary and not accidental.
This design is not accidental. It was taken from Unix and renamed "REST". The Unix/Plan 9/REST principle is essentially the same as the Alan Perlis quote: "It is better to have 100 functions operate on one data structure than 10 functions on 10 data structures." [1] The single data structure is the stream of bytes, or the file / file descriptor.
For the source code example, how would you write a language-independent grep if every language had its own representation? How about diff? hg or git? merge tools? A tool to jump to source location from compiler output? It takes multiple languages to solve any non-trivial problem, so you will end up with an M x N combinatorial explosion (N tools for each of M languages), whereas you want M + N (M languages + N tools that operate on ALL languages).
Most good programming languages have the same flavor -- they are built around a single data structure. In C, this is the pointer + offset (structs, arrays). In Python/Lua it's the dictionary. In R it's the data frame; in Matlab it's the matrix. In Lisp/Scheme it's the list.
Java and C++ tend to have exploding codebase size because of the proliferation of types, which cause the M * N explosion. Rich Hickey has some good things to say about this.
I would posit that Windows and certain other software ecosystems have reached a fundamental scaling limit because of the O(M*N) explosion. Even if you have $100 billion, you can't write enough code to cover this space.
Another part of this is the dichotomy between visually-oriented people and language-oriented people. A great read on this schism is: http://www.cryptonomicon.com/beginning.html . IMO language-oriented tools compose better and abstract better than visual tools. In this thread, there is a great point that code is not 2D or 3D; it has richer structure than can really be represented that way.
I really like Bret Victor's talks and ideas. His other talks are actually proposing solutions, and they are astounding. But this one comes off more as complaining, without any real solutions.
He completely misunderstands the reason for the current state of affairs. It's NOT because we are ignorant of history. It's because language-oriented abstractions scale better and let programmers get things done more quickly.
That's not to say this won't change, so I'm glad he's working on it.
[1] http://www.cs.yale.edu/quotes.html