The Future of Programming

http://worrydream.com/dbx/

by rpearl • 13 years ago

614 341 13 years ago

worrydream.com

rpearl• 13 years ago

"The most dangerous thought you can have as a creative person is to think you know what you're doing."

tmoertel• 13 years ago

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.

the_cat_kittles• 13 years ago

I believe this so deeply, I love hearing him make such a compelling argument for it.

asselinpaul• 13 years ago

Watching this now but I expect greatness like all his talks.

ibdknox6• 13 years ago

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.

EDIT: Here's the link to the talk https://thestrangeloop.com/sessions/tbd--11

groby_b2• 13 years ago

Grumble. I understand that you can't really share the talk before the conference, but man, you're teasing.

Share a thought or two with the peons who won't/can't travel :)

ibdknox6• 13 years ago

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. :)

doorhammer2• 13 years ago

I always kick myself for not having made it to Strange Loop when I lived in St. Louis.

I'll (hopefully) be looking forward to a vid of it on infoq at some point. :)

ibdknox6• 13 years ago

FWIW, after the talk I'll likely end up putting up a big thing about it on the internet somewhere. :)

robomartin2• 13 years ago

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.

ced• 13 years ago

What makes APL different from, say, Lisp or Haskell? Do you have tutorials to recommend?

jhickner2• 13 years ago

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?

seanmcdirmid9• 13 years ago

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.

ibdknox6• 13 years ago

hopefully it involves a new programming model to make the problem more well defined

That's exactly what I'm up to :)

jongraehl• 13 years ago

"tenets"

bachback3• 13 years ago

@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).

rasur• 13 years ago

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 ;) )

ibudiallo• 13 years ago

I am half way there and i have never been disappointed by Bret Victor. He comes from the future.

grey-area2• 13 years ago

Or, in this case, the past.

_pius• 13 years ago

This is a brilliant, trenchant indictment of the state of our industry.

hcarvalhoalves• 13 years ago

Love Bret's style. Also love how the crowd went silent after the "API" slide.

kintamanimatt• 13 years ago

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.

peregrine• 13 years ago

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.

http://stackoverflow.com/questions/15214526/why-hypermedia-a...

zekenie• 13 years ago

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.

ganarajpr• 13 years ago

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!

ThomPete2• 13 years ago

"they didn't know what they were doing, so they tried everything"

michaelrbock• 13 years ago

A quote from the footnotes:

"'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."

tel2• 13 years ago

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.

ryanSrich• 13 years ago

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.

tel2• 13 years ago

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.

bsaul• 13 years ago

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.

rdouble2• 13 years ago

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.

TeMPOraL• 13 years ago

So maybe just give him the $100M and leave him alone to do whatever he feels like doing. I'm pretty sure something good could come out of it.

sunnybythesea2• 13 years ago

He is a modern day Renaissance man.

sunnybythesea2• 13 years ago

Why was this downvoted?

agilebyte• 13 years ago

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.

stiff• 13 years ago

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.

pestaa2• 13 years ago

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.

InclinedPlane10• 13 years ago

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.

tsunamifury• 13 years ago

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.

scribu• 13 years ago

He's not knocking the current model

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".

HCIdivision17• 13 years ago

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.

jpadkins3• 13 years ago

so you are saying marketing* is the problem, not technology.

*marketing defined as clearly communicating the benefits of the product/technology.

jonahx• 13 years ago

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.

voltagex_3• 13 years ago

You can tear me to shreds for this, but until I can code Haskell in Visual Studio, it's going to be hard for it to gain any traction in $BIGCORP.

squidsoup2• 13 years ago

F# is a first class citizen in Visual Studio, yet it doesn't appear to have gained much traction in 'enterprise software development'.

asdasf7• 13 years ago

That is $BIGCORP's loss, why would I care?

creed0r• 13 years ago

ABSOLUT.MUST.SEE.

dbpokorny• 13 years ago

I wrote down some thoughts on this subject.

http://dbpokorny.blogspot.com/2013/07/permission-based-progr...

Kronopath• 13 years ago

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.

calibraxis3• 13 years ago

What should I read to understand his anti-API point better? Learn about RDF? Or is there something better?

Kafka• 13 years ago

I'm not sure but I came to think of the HATEOAS constraint of REST.

jgon• 13 years ago

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.

ericHosick13• 13 years ago

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.

DigitalJack• 13 years ago

I don't think he meant a literal language. For communication you have to establish a common understanding of something between multiple entities.

pnathan2• 13 years ago

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.

AsymetricCom2• 13 years ago

I think you might be thinking of the RNA metaprotocol or Recursive Network Architecture.

pnathan2• 13 years ago

Phenotropics, actually.

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.

humanrebar6• 13 years ago

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.

EDIT: Wordsmithing

sramsay2• 13 years ago

Yep. "We need to think hard about . . . consider the past . . . the reigning paradigm . . . in fifty years . . ."

YES! YES! YES! I CAN SEE IT! KEEP GOING! YOU'RE A GENIUS! TELL IT, BROTHER!

"Visual programming . . ."

Oh, for God's sake . . .

anigbrowl4• 13 years ago

Why, what have you got?

ericHosick13• 13 years ago

Do you really think that in 20 to 40 years from now, we will still be hacking away in some computer language that only a very few "elite" people know?

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.

anigbrowl4• 13 years ago

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.*

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.

humanrebar6• 13 years ago

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.

spyder• 13 years ago

text = code bubble

Code Bubbles: http://www.andrewbragdon.com/codebubbles_site.asp

teyc2• 13 years ago

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.

nbouscal• 13 years ago

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).

ericHosick13• 13 years ago

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.

ionforce• 13 years ago

This talk is so fluffy and empty. Surely there must be someone else who did not enjoy it.

cia_plant• 13 years ago

Yeah I felt like this had even less content than most of Bret's other talks, which are always kind of short on specifics.

sanderjd2• 13 years ago

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.

dirtyaura• 13 years ago

Huh? Bret's talks short on specifics?

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.

tmarthal• 13 years ago

"I do think that it would be really cool if the actor model is like picked up by the Swedish phone company."

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

zalew• 13 years ago

Ericsson - Erlang

http://en.wikipedia.org/wiki/Erlang_%28programming_language%...

http://en.wikipedia.org/wiki/Open_Telecom_Platform

grey-area2• 13 years ago

It's a reference to Erlang at Ericsson. See the notes below the video.

marcamillion2• 13 years ago

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.

What am I missing?

sanderjd2• 13 years ago

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.

marcamillion2• 13 years ago

Oh ok.

I was wondering how comes the audience (and video) seems so "current", but the content looks so dated.

humanrebar6• 13 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.

AsymetricCom2• 13 years ago

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.

EvanMiller• 13 years ago

It is satire, not farce.

6ren• 13 years ago

Could someone upload this to youtube, please? vimeo is unwatchable on old/underpowered devices.

slacka3• 13 years ago

Here you go:

http://youtu.be/8pTEmbeENF4

artagnon11• 13 years ago

The art of programming is evolving steadily; more powerful hardware becomes available, and compiler technology evolves.

Ofcourse there will be resistance to change, and new compilers don't mature overnight. At the end of the day, it boils down to what can be parsed unambiguously, written down easily by human beings, and executed quickly. If you get off on reading research papers on dependent types and writing Agda programs to store in your attic, that's your choice; the rest of us will be happily writing Linux in C99 and powering the world.

Programming has not fundamentally changed in any way. x86 is the clear winner as far as commodity hardware is concerned, and serious infrastructure is all written in C. There is a significant risk to adopting any new language; the syntax might look pretty, but you figure out that the compiler team consists of incompetent monkeys writing leaking garbage collectors. We are pushing the boundaries everyday:

- Linux has never been better: it continues improve steadily (oh, and at what pace!). New filesystems optimized for SSDs, real virtualization using KVM, an amazing scheduler, and a new system calls. All software is limited by how well the kernel can run it.

- We're in the golden age of concurrency. Various runtimes are trying various techniques: erlang uses a message-passing actor hammer, async is a bit of an afterthought in C#, Node.js tries to get V8 to do it leveraging callbacks, Haskell pushes forward with a theoretically-sound STM, and new languages like Go implement it deep at the scheduler-level.

- For a vast majority of applications, it's very clear that automatic memory management is a good trade-off. We're look down upon hideous nonsense like the reference-counter in cpython, and strive to write concurrent moving GCs. While JRuby has the advantage of piggy-banking on a mature runtime, the MRI community is taking GC very seriously. V8 apparently has a very sophisticated GC as well, otherwise Javascript wouldn't be performant.

- As far as typing is concerned, Ruby has definitely pushed the boundaries of dynamic programming. Javascript is another language with very loosely defined semantics, that many people are fond of. As far as typed languages go, there are only hideous languages like Java and C#. Go seems to have a nice flavor of type inference to it, but only time will tell if it'll be a successful model. Types make for faster code, because your compiler has to spend that much less time inspecting your object: V8 does a lot of type inference behind the scenes too.

- As far as extensibility is concerned, it's obvious that nothing can beat a syntax-less language (aka. Lisp). However, Lisps have historically suffered from a lack of typesystem and object system: CLOS is a disaster, and Typed Racket seems to be going nowhere. Clojure tries to bring some modern flavors into this paradigm (core.async et al), while piggy-banking on the JVM. Not sure where it's going though.

- As far as object systems go, nothing beats Java's factories. It's a great way to fit together many shoddily-written components safely, and Dalvik does exactly that. You don't need a package-manager, and applications have very little scope for misbehaving because of the suffocating typesystem. Sure, it might not be be pleasant to write Java code, but we really have no other way of fitting so many tiny pieces together. It's used in enterprise for much the same reasons: it's too expensive to discipline programmers to write good code, so just constrain them with a really tight object system/typesystem.

- As far as functional programming goes, it's fair to say that all languages have incorporated some amount of it: Ruby differentiates between gsub and gsub! for instance. Being purely functional is a cute theoretical exercise, as the scarab beetle on the Real World Haskell book so aptly indicates.

- As far as manual memory management goes (when you need kernels and web browsers), there's C and there's C++. Rust introduces some interesting pointer semantics, but it doesn't look like the project will last very long.

Well, that ends my rant: I've hopefully provided some food for thought.

squidsoup2• 13 years ago

Nothing you've said really invalidates his argument - we are still typing mostly imperative code into text files, it is still very easy to introduce bugs into software, and software development is on the whole unnecessarily complex and unintuitive.

It's heartening to see a renewed interest in functional, declarative and logic based programming today, but also saddening that the poisonous legacy of C has prevented us from getting there sooner.

zxcdw2• 13 years ago

It's heartening to see a renewed interest in functional, declarative and logic based programming today, but also saddening that the poisonous legacy of C has prevented us from getting there sooner.

From the point of view of programming a computer, this doesn't make much sense to me personally.

But perhaps the problem is that I first and foremost see that I program a computer, a deterministic machine with limited resources and functionality, rather than "designing an user experience and letting computer take care of making it run as I describe". Guess I dwell in the depths of hardware/machine centric programming rather than fly high in user centric programming.

artagnon11• 13 years ago

Don't talk rubbish. Nobody enjoys spending 10 hours to accomplish something that can be accomplished in an hour. Ofcourse we're trying to build compilers for nicer languages. Programming isn't going to become any less complex or unintuitive by sitting around wishing for better solutions: it's going to happen by studying existing technology, and using it to build better solutions.

What has "prevented" us from getting there sooner is purely our incompetence. It's becoming painfully clear to me that people have absolutely no idea about how a compiler works.

munificent2• 13 years ago

We're in the golden age of concurrency. Various runtimes are trying various techniques: erlang uses a message-passing actor hammer, async is a bit of an afterthought in C#, Node.js tries to get V8 to do it leveraging callbacks, Haskell pushes forward with a theoretically-sound STM, and new languages like Go implement it deep at the scheduler-level.

No, a better analogy is that we're in the Cambrian explosion of concurrency. We have a bunch of really strange lifeforms all evolving very rapidly in weird ways because there's little selection pressure.

Once one of these lifeforms turns out to be significantly better, then it will outcompete all of the others and then we'll be in something more like a golden age. Right now, we still clearly don't know what we're doing.

artagnon11• 13 years ago

We've been doing concurrency for many years now; it's called pthreads. Large applications like Linux, web browsers, webservers, and databases do it all the time.

The question is: how do we design a runtime that makes it harder for the user to introduces races without sacrificing performance or control? One extreme approach is to constrain the user to write only purely functional code, and auto-parallelize everything, like Haskell does (it's obvious why this is a theoretical exercise). Another is to get rid of all shared memory and restrict all interaction between threads to message passing like Erlang does (obviously, you have to throw performance out the window). Yet another approach is to run independent threads and keep polling for changes at a superficial level (like Node.js does; performance and maintainability is shot). The approach that modern languages are taking is to build concurrency as a language primitive built into the runtime (see how go's proc.c schedules various channels in chan.c; it has a nice race detection algorithm in race.c).

There is more pressure than ever to build applications that leverages more cores to build highly available internet applications. Multi-cores have existed long enough, and are now prevalent even on mobile devices. No radically different solution to concurrency is magically going to appear tomorrow: programmers _need_ to understand concurrency, and work with existing systems.

seanmcdirmid9• 13 years ago

This is about right. The situation is even worse for parallelism.

blessmurk• 13 years ago

Haskel is the word from the god :)

pcwalton3• 13 years ago

Rust introduces some interesting pointer semantics, but it doesn't look like the project will last very long.

Why not?

artagnon11• 13 years ago

Let's take a couple of simple examples of when manual memory management is helpful:

- implement a complex data structure that requires a lot of memory: you can request a chunk of memory from the kernel, do an area-allocation and choose to allocate/free on your own terms.

- implement a performant concurrency model. You essentially need some sort of scheduler to give various threads access to the shm via cas primitives.

Let's take up the second point first: you have implemented tasks that communicate using pipes without sharing memory (rt/rust_task.cpp). You've exposed the lower-level rt/sync via libextra/sync.rs, but it's frankly not a big improvement over using raw pthreads. The scheduler is a toy (rt/rust_scheduler.cpp), and the memory allocator is horribly primitive (rt/memory_region.cpp; did I read correctly? are you using an array to keep track of the allocated regions?). The runtime is completely devoid of any garbage collection, because you started out with the premise that manual memory management is the way to go: did it occur to you that a good gc would have simplified the rest of your runtime greatly?

Now for the first point: Rust really has no way of accomplishing it, because you I don't get access to free(). The best you can do at this point is to use some sort of primitive reference counter (not much unlike cpython or shared-pointer in C++), because it's too late to implement a tracing garbage collector. And you just threw performance out the window by guaranteeing that you will call free() everytime something goes out of scope, no matter how tiny the memory.

Now, let's compare it to the go runtime: arena-allocator tracked using bitmaps (malloc.goc), decent scheduler (proc.c), decent tracing garbage collector (mgc0.c), and channels (chan.c). For goroutines modifying shared state, they even implemented a nice race-detection tool (race.c).

The fact of the matter is that a good runtime implementing "pretty" concurrency primitives requires a garbage collector internally anyway. It's true that go doesn't give me a free() either, but atleast I'm reassured by the decent gc.

Now, having read through most of libstd, observe:

  impl<'self, T> Iterator<&'self [T]> for RSplitIterator<'self, T>

What's the big deal here? The lifetime of the variable is named ('self), and the ownership semantics are clear (& implies borrowed pointer; not very different from the C++ counterpart). Whom is all this benefitting? Sure, you get annoying compile-time errors when you don't abide by these rules, but what is the benefit of using them if there's no tooling around it (aka. gc)? Yes, it's trivially memory-safe and I get that.

Lastly think about why people use C and C++. Primarily, it boils down to compiler strength. The rust runtime doesn't look like it's getting there; atleast not in its current shape.

malandrew3• 13 years ago

Dunno the OPs original reasoning, but I found this comment flippant and unsubstantiated. I don't code Rust myself, but both it and Go seem extremely promising and both "specialize" relative to C/C++ without stepping on each other's toes. There is room for both systems languages. As things stand now if it doesn't last very long, it will because of some future mistake by its creators or community, not because it loses out to some fitter competitor. AFAICT the multicore future doesn't have room for C/C++, so its logical that one or more practical systems language that do consider a multicore future will take the place of C/C++. Go and Rust seem like the most likely candidates on the horizon at this point in time.

lispm2• 13 years ago

x86 is the clear winner as far as commodity hardware is concerned, and serious infrastructure is all written in C.

Most of my computers now use ARM.

C is single-handedly responsible for 99% of all security problems on the Internet. It must die. Quick.

CLOS is a disaster

As far as object systems go, nothing beats Java's factories.

WTF?

I've hopefully provided some food for thought.

Not really.

artagnon11• 13 years ago

Most of my computers now use ARM.

Factually, there have been more commits to the arch/arm tree than the arch/x86 tree in the last six months. It's true that Linaro, Samsung, and many other companies are interested in taking ARM forward as it's great for minimizing power consumption on embedded devices (among other things). I'm not going to speculate about whether x86 or ARM will "win the battle" or whether they will co-exist, but the fact of the matter is that x86 dominates everything from consumer laptops to web infrastructure. It's a very mature architecture, and VT-x is slowly phasing out pvops. The virt/kvm/arm tree is very recent (3 months old): ARM doesn't have virtualization extensions, so I don't know how this works yet. So, yeah: ARM definitely has a long and exciting future.

C is single-handedly responsible for 99% of all security problems on the Internet.

Collecting evidence to back outrageous claims is left as an exercise to the reader.

BS

I'm not interested in "transcendental superiority" arguments. CLOS doesn't have users, and hasn't influenced object systems in prevalent languages; period.

WTF?

Factually, Java is a very popular language in industry, which requires code produced by different programmers to fit together reliably. I personally attribute it to the object system/ typesystem, although others might have a different view.

takikawa• 13 years ago

and Typed Racket seems to be going nowhere.

To the contrary, Typed Racket is under active development and new Racket libraries are written using it. I don't know where you got the impression that it's going nowhere, but it's incorrect.

artagnon11• 13 years ago

1411 results for https://github.com/search?q=%23lang+typed%2Fracket&type=Code

of the total

53k results for https://github.com/search?q=%23lang+racket&type=Code

I rest my case.

dman• 13 years ago

Eternally relevant when discussing worlds of computing that could have been - http://www.dreamsongs.com/RiseOfWorseIsBetter.html

jjindev3• 13 years ago

Isn't this all just evidence that "better" in most cases is a small margin? You can hate X, and prefer Y, but in most cases the X guys will finish their project. Methodology based crash and burns are pretty rare. And the things that are "not terrible" are not separated by that much.

0xdeadbeefbabe• 13 years ago

Subtext seemed like a good abstraction what happened there? http://www.oscon.com/oscon2010/public/schedule/detail/15484

InclinedPlane10• 13 years ago

An interesting talk, and certainly entertaining, but I think it falls very short. Ultimately it turns into typical "architecture astronaut" naval gazing. He focuses on the shortcomings of "traditional programming" while at the same time imagining only the positive aspects of untried methods. To be honest, such an approach is frankly childish, and unhelpful. His closing line is a good one but it's also trite, and the advice he seems to give leading up to it (i.e. "let's use all these revolutionary ideas from the '60s and '70s and come up with even more revolutionary ideas") is not practical.

To pick one example: he derides programming via "text dump" and lauds the idea of "direct manipulations of data". However, there are many very strong arguments for using plain-text (read "The Pragmatic Programmer" for some very excellent defenses of such). Moreover, it's not as though binary formats and "direct manipulations" haven't been tried. They've been tried a great many times. And except for specific use cases they've been found to be a horrible way to program with a plethora of failed attempts.

Similarly, he casually mentions a programming language founded on unique principles designed for concurrency, he doesn't name it but that language is Erlang. The interesting thing about Erlang is that it is a fully fledged language today. It exists, it has a ton of support (because it's used in industry), and it's easy to install and use. And it also does what it's advertised to do: excel at concurrency. However, there aren't many practical projects, even ones that are highly concurrency dependent, that use Erlang. And there are projects, such as couch db, which are based on Erlang but are moving away from it. Why is that? Is it because the programmers are afraid of changing their conceptions of "what it means to program"? Obviously not, they have already been using Erlang. Rather, it's because languages which are highly optimized for concurrency aren't always the best practical solution, even for problem domains that are highly concurrency bound, because there are a huge number of other practical constraints which can easily be just as or more important.

Again, here we have an example of someone pushing ideas that seem to have a lot of merit in the abstract but in the real world meet with so much complexity and roadblocks that they prove to be unworkable most of the time.

It's a classic "worse is better" scenario. His insult of the use of markup languages on the web is a perfect example of his wrongheadedness. It took me a while to realize that it was an insult because in reality the use of "text dump" markup languages is one of the key enabling features of the web. It's a big reason why it's been able to become so successful, so widespread, so flexible, and so powerful so quickly. But by the same token, it's filled with plenty of ugliness and inelegance and is quite easy to deride.

It's funny how he mentions unix with some hints of how awesome it is, or will be, but ignores the fact that it's also a "worse is better" sort of system. It's based off a very primitive core idea, everything is a file, and very heavily reliant on "text dump" based programming and configuration. Unix can be quite easily, and accurately, derided as a heaping pile of text dumps in a simple file system. But that model turns out to be so amazingly flexible and robust that it creates a huge amount of potential, which has been realized today in a unix heritage OS, linux, that runs on everything from watches to smartphones to servers to routers and so on.

Victor highlights several ideas which he thinks should be at the core of how we advance the state of the art in the practice of programming (e.g. goal based programming, direct manipulations of data, concurrency, etc.) but I would say that those issues are far from the most important in programming today. I'd list things such as development velocity and end-product reliability as being far more important. And the best ways to achieve those things are not even on his list.

Most damningly, he falls into his own trap of being blind to what "programming" can mean. He is stuck in a model where "programming" is the act of translating an idea to a machine representation. But we've known for decades that at best this is a minority amount of the work necessary to build software. For all of Victor's examples of the willingly blind programmers of the 1960s who saw things like symbolic coding, object oriented design and so forth as "not programming" and more like clerical work he makes fundamentally the same error. Today testing, integration, building, refactoring and so on are all hugely fundamental aspects of prototyping and critically important to end-product quality as well as development velocity. And increasingly tooling is placing such things closer and closer to "the act of programming", and yet Victor himself still seems to be quite blind to the idea of these things as "programming". Though I don't think that will be the view among programmers a few decades down the road.

seanmcdirmid9• 13 years ago

"Worse is better", aka "New Jersey style", as in RPG's famous essay? [1]

[1] http://www.dreamsongs.com/WorseIsBetter.html

InclinedPlane10• 13 years ago

Precisely.

fsck--off• 13 years ago

Daniel Weinreb's blog post response to "Worse is Better" is worth reading. DLW was "the MIT guy" and was a news.yc user (dlweinreb).

http://web.archive.org/web/20110709052759/http://danweinreb....

astral303• 13 years ago

Brilliant analysis! Navel gazing indeed. Typical NCA (Non-Coding Architect) stuff.

This reminds me of the UML and the Model-Driven Architecture movement of the days before, where architect astronauts imagined a happy little world where you could just get away from that dirty coding, join some boxes with lines in all sorts of charts and then have that generate your code. And it will produce code you actually want to ship and that does what you want to do.

This disdain for writing code is not new. This classic essay about "code as design" from 1992 (!) is still relevant today:

http://www.developerdotstar.com/mag/articles/reeves_original...

InclinedPlane10• 13 years ago

In the presenter's worldview it seems as though a lot of subtle details are ignored or just not seen, whereas in reality seemingly subtle details can sometimes be hugely important. Consider Ruby vs Python, for example. From a 10,000 foot view they almost look like the same language, but at a practical level they are very different. And a lot of that comes down to the details. There are dozens of new languages within the last few decades or so that share almost all of the same grab bag of features in a broad sense but where the rubber meets the road end up being very different languages with very different strengths. Consider, for example, C# vs Go vs Rust vs Coffeescript vs Lua. They are all hugely different languages but they are also very closely related languages.

I suspect that the killer programming medium of 2050 isn't going to be some transformatively different methodology for programming that is unrecognizable to us, it's going to be something with a lot of similarities to things I've listed above but with a different set of design choices and tradeoffs, with a more well put together underlying structure and tooling, and likely with a few new ways of doing old things thrown in and placed closer to the core than we're used to today (my guess would be error handling, testing, compiling, package management, and revision control).

There is just so much potential in plain jane text based programming that I find it odd that someone would so easily clump it into a single category and write it all off at the same time. It's a medium that can embrace everything from Java on the one hand to Haskell or lisp on the other, we haven't come anywhere close to reaching the limits of expressiveness available in text-based programming.

jrheard• 13 years ago

I don't think it's fair to call him a Non-Coding Architect. Have you seen his other talks, or the articles he's published via his website http://worrydream.com ? Bret clearly codes.

anigbrowl4• 13 years ago

Typical NCA (Non-Coding Architect) stuff.

I assure you that devices of this sort require a great deal of code: http://cachepe.zzounds.com/media/quality,85/Ion_front-c20cdb...

zapov• 13 years ago

Can you expand on what's wrong with declarative design? I'm not talking about UML, but modeling specifically.

Since I've been doing it for quite a few years I guess I know a thing or two about MDA/MDE. And it's not about disdain for writing code.

RogerL10• 13 years ago

Thanks for saying all that. I was thinking it, but restrained myself since there seemed to be a lot of hero worship over this person going on here. But it needs to be said. Everything in that video is of stuff that has been researched for decades. It isn't mainstream largely because it is facile to say 'declarative programming' or what have you, but something entirely different for it to be easier and better. Prolog is still around. Go download a free compiler, and try to write a 3D graphical loop that give you 60 fps. Try to write some seismic code with it. Try to write web browser. Not so easy. Much was promised by things like Prolog, declarative programming, logic programming, expert systems, and so on, but again it is easy to promise, hard to deliver. We didn't give up, or forget the ideas, it is just that the payoff wasn't there (except in niche areas where in fact all of these things are going strong, as you would expect).

Graphical programming doesn't work because programs are not 2 dimensional, they are N dimensional, and you spend all your time trying to fit things on a screen in a way that doesn't look like a tangled ball of yarn (hint, can't be done). I've gone through several CASE tools through my decades, and they all stink. Not to mention, I don't really think visually, but more 'structurally' - in terms of the interrelations of things. You can't capture that in 2D, and the problems that 2D create more than overwhelm whatever advantages you might get going from 1D (text files) to 2D.

Things like CSP have never been lost, though they were niche for awhile. Look at Ada's rendevous model, for example.

InclinedPlane10• 13 years ago

Right. Personally I've had plenty of experience with certain examples of "declarative programming" and "direct manipulation of data" programming and other than a few fairly niche use cases they are typically horrid for general purpose programming. Think about how "direct manipulation" programming fits into a source control / branching workflow, for example. Unless there's a text intermediary that is extremely human friendly you have a nightmare on your hands. And if there is such an intermediary then you're almost always better off just "directly manipulating" that.

meemoo5• 13 years ago

I have actually been thinking about 1D coding vs 2D coding. Isn't 2D describing nD a little bit closer? Like a photograph of a sculpture... a little easier to get the concept than with written description, no matter how eloquent.

Re: the ball of yarn, we're trying to design that better in NoFlo's UI. Think about a subway map that designs itself around your focus. Zoom out to see the whole system, in to see the 1D code.

ericHosick13• 13 years ago

you spend all your time trying to fit things on a screen in a way that doesn't look like a tangled ball of yarn (hint, can't be done)

The way we code now leads to tangled balls of yarn. That won't be fixed by simply moving to a graphical (visual) programming language.

williamcotton• 13 years ago

I'd list things such as development velocity and end-product reliability as being far more important.

Your main thesis is that software and computing should be optimized to ship products to consumers.

The main thesis of guys like Alan Kay is that we should strive to make software and computing that is optimized for expanding human potential.

Deep down most of us got in to computing because it is a fantastic way to manipulate our world.

Bret Victor's talks instill a sense of wonderment and discovery, something that has often been brow-beaten out of most of us working stiffs. The talks make us feel like there is more to our profession than just commerce. And you know what? There is. And you've forgotten that to the point where you're actually rallying against it!

Come back to the light, fine sir!

InclinedPlane10• 13 years ago

Your main thesis is that software and computing should be optimized to ship products to consumers.

Those were just examples of other things I thought were more important, it wasn't an exhaustive list. However, it's interesting that you focus in on "optimizing to ship products to consumers", when I made mention of no such thing. I mentioned development velocity and end-product reliability. These are things that are important to the process of software development regardless of the scale of the project or the team working on it or the financial implications of the project.

They are tools. Tools for making things. They enable both faceless corporations who want to make filthy lucre by shipping boring line-of-business apps and individuals who want to "expand human potential" or "instill a sense of wonderment and discovery".

Reliability and robustness are very fundamental aspects to all software, no matter how it's built. And tools such as automated builds combined with unit and integration tests have proven to be immensely powerful in facilitating the creation of reliable software.

If your point is that non-commercial software need not take advantage of testing or productivity tools because producing a finished product that runs reliably is unimportant if you are merely trying to "expand human potential" or what-have-you then I reject that premise entirely.

If you refuse to acknowledge that the tools of the trade in the corporate world represent a fundamentally important contribution to the act of programming then you are guilty of the same willful blindness that Bret Victor derides so heartily in his talk.

jjindev3• 13 years ago

You now, in some sense those early visionaries were beaten by the disruptive innovators of their day.

I think the argument here is that 1000 little choices favoring incremental advantage in the short term add up to a sub-optimal long term, but I'm not so sure. I have a *NIX machine in my phone. Designers "threw it in there" as the easy path. And it works.

xlayn5• 13 years ago

> I'd list things such as development velocity and end-product reliability as being far more important.

Your main thesis is that software and computing should be optimized to ship products to consumers.

No, the main thesis is that should be optimized to solve problems and to try to adjust it as easily as it could..

The main thesis of guys like Alan Kay is that we should strive to make software and computing that is optimized for expanding human potential.

we are, even with our current tools, now you have the opportunity to express yourself to a the world in this place, everything done with these limiting tools..., it's IMO the presentation about exploring if maybe there is a better approach...., quotes on maybe

Come back to the light, fine sir! All are lights... is just the adequate combination required... you don't put the ultra bright leds of your vehicle in your living room or viceversa ...

eggsby• 13 years ago

Your criticism seems to be framed against where we are at today.

As programmers we have a fragmented feedback cycle regardless of whether we are writing our software in Erlang or Lisp or C++.

While it is true that realistic matters like 'integration' and 'development velocity' are important enough in modern-day programming to determine what path we must take we shouldn't let it change our destination.

If you were to envision programming nirvana would it be mostly test coverage and scrum boards?

InclinedPlane10• 13 years ago

If you were to envision programming nirvana would it be mostly test coverage and scrum boards?

Far from it. Indeed I think that TDD is vastly over-used and often harmful and SCRUM is more often development poison than anything else. But the fact that these things are popular despite the frequent difficulty of implementing them correctly is, I think, indicative of two things. First, that there is something of serious and fundamental value there which has caused so many people to latch onto such ideas zealously, even without fully understanding where the value in such ideas comes from. And second, that due to their being distanced from the "practice of programming" they are more subject to misinterpretation and incorrect implementation (this is a hard problem in programming as even the fundamentals of object oriented design aren't immune to such problems even though they tend to be baked into programming languages fairly deeply these days).

I think that unquestionably a routine build/test cycle is a massive aid to development quality. It doesn't just facilitate keeping a shipping product on schedule it has lots of benefits that diffuse out to every aspect of development in an almost fractal fashion. For example, having a robust unit test suite vastly facilitates refactoring, which makes it easier to improve code quality, which makes it easier to maintain and modify code, which makes it easier to add or change features, and so forth. It's a snowball effect. Similarly I think that unquestionably a source control system is a massive aid to development quality and the pace. That shouldn't be a controversial statement today though it would have been a few decades ago. More so I think that unquestionably the branching and merging capabilities of advanced source control systems are a huge aid in producing software.

Development velocity has a lot of secondary and higher order effects that impact everything about the software project. It makes it easier to change directions during development, it lowers the overhead for every individual contributor, and so on. Projects with higher development velocity are more agile, they are able to respond to end-user feedback and test feedback and are more likely to produce a reliable product that represents something the end-users actually want without wasting a lot of developer time along the way.

Some people have tried to formalize such "agile" processes into very specific sets of guidelines but I think for the most part they've failed to do so successfully, and have instead created rules which serve a far too narrow niche of the programming landscape and are also in many cases too vague to be applied reliably. But that doesn't mean that agility or increased development velocity in general are bad ideas, they are almost always hugely advantageous. But they need to be exercised with a great deal of thought and pragmatism.

Also, as to testing, it also suffers from the problem of being too distanced from the task of programming. There are many core problems in testing such as the fact that test code tends to be of lower quality than product code, the problems of untested or conflicting assumptions in test code (who tests the tests?), the difficulty of creating accurate mocks, and so on. These problems can, and should, be addressed but one of the reasons why they've been slow to be addressed is that testing is still seen as something that gets bolted onto a programming language, rather than something that is an integral part of coding.

Anyway, I've rambled too long I think, it's a deep topic, but hopefully I've addressed some of your points.

chubot3• 13 years ago

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.

[1] http://www.cs.yale.edu/quotes.html

eru• 13 years ago

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.)

asdasf7• 13 years ago

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.

JunkDNA• 13 years ago

I see where you are coming from, but I think you're getting mired in some of the details of the talk that perhaps rub you the wrong way and are therefore missing the larger point. Brett in all his talks is saying the same thing: take an honest look at what we call programming and tell me that we've reached the pinnacle of where we can go with it.

Whether or not you like this specific talk or the examples he has chosen, I think you would probably agree there is a lot of room for improvement. Brett is trying to stir the pot and get some people to break out and try radical ideas.

Many of the things he talks about in this presentation have been tried and "failed" but that doesn't mean you never look at them again. Technology and times change in ways that can breathe life into early ideas that didn't pan out initially. Many forget that dynamic typing and garbage collection were once cute ideas but failures in practice.

He doesn't mention things like testing, integration, building, and refactoring because they are all symptoms of the bigger problem that he's been railing against: namely that our programs are so complex we are unable to easily understand them to build decent, reliable software in an efficient way. So we have all these structures in place to help us get through the complexity and fragility of all this stuff we create. Instead we should be focusing on the madness that causes our software to balloon to millions of lines of incomprehensible code.

InclinedPlane10• 13 years ago

Sure, but I think he ends up missing the mark. Ultimately his talk boils down to "let's revolutionize programming!" But as I said that ends up being fairly trite.

As for testing, integration, building, and refactoring I think it's hugely mistaken to view them as "symptoms of a problem". They are tools. And they aren't just tools used to grapple with explosions of complexity, they are tools that very much help us keep complexity in check. To use an analogy, it's not as though these development tools are like a hugely powerful locomotive that can drag whatever sorry piece of crap codebase you have out into the world regardless of its faults. Instead, they are tools that enable and encourage building better codebases, more componentized, more reliable, more understandable, etc.

Continuous integration techniques combined with robust unit and integration testing encourage developers to reduce their dependencies and the complexity of their code down as much as possible. They also help facilitate refactoring which makes reduction of complexity easier. And they actively discourage fragility, either at a component level or at a product/service level.

Without these tools there is a break in the feedback loop. Coders would just do whatever the fuck they wanted and try to smush it all together and then they'd spend the second 90% of development time (having already spent the first) stomping on everything until it builds and runs and sort of works. With more modern development processes coders feel the pain of fragile code because it means their tests fail. They feel the pain of spaghetti dependencies because they break the build too often. And they feel that pain much closer to the point of the act that caused it, so that they can fix it and learn their lesson at a much lower cost and hopefully without as much disruption of the work of others.

With any luck these tools will be even better in the future and will make it even easier to produce high quality code closer to the level of irreducible complexity of the project than is possible today.

These aren't the only ways that programming will change for the better but they are examples which I think it's easy for people to write off as not core to the process of programming.

joe_the_user2• 13 years ago

The thing is that computing has both reached the limits of where "text dump" programming can go AND has found the text-dump programming is something like a "local maximum" among the different clear options available to programmers.

It seems like we need something different. But the underlying problem might be that our intuitions about "what's better" don't seem to work. Perhaps an even wider range of ideas needs to be considered and not simply the alternatives that seem intuitively appealing (but which have failed compared to the now-standard approach).

bulatb• 13 years ago

Please forgive my liberties with science words. :)

The purpose of refactoring is to remove the entropy that builds up in a system, organization, or process as it ages, grows in complexity, and expands to meet demands it wasn't meant to handle. It's not a symptom of a problem; it's acknowledgement that we live in a universe where energy is limited and entropy increases, where anything we humans call a useful system is doomed to someday fall apart—and sooner, not later, if it isn't actively maintained.

Refactoring is fundamental. Failure to refactor is why nations fall to revolutions, why companies get slower, and why industries can be disrupted. More figuratively, a lack of maintenance is also why large stars explode as supernovas and why people die of age. And as a totally non-special case, it's why programs become giant balls of hair if we keep changing stuff and never clean up cruft.

A system where refactoring is not a built-in process is a system that will fail. Even if we automate it or we somehow hide it from the user, refactoring still has to be there.

foobarian• 13 years ago

To add to the UNIX thought, it goes beyond text configuration--the very design of system calls that can fail with EINTR error code was a kind of worse is better design approach.

n00b1012• 13 years ago

it turns into typical "architecture astronaut" naval gazing

I take exception to your critique of your Mr Victor's presentation. I am sad to see that your wall of text has reached the top of this discussion on HN. To be honest, it's probably because no one has the time to wade through all of the logical fallacies, especially the ad hominem attacks and needlessly inflammatory language ("falls very short," "architecture astronaut naval gazing," "untried methods," "frankly childish, and unhelpful,"trite," "not practical," etc)

You seem to be reacting just like the "absolute binary programmers" that Bret predicts. As far as I can gather, you are fond of existing web programming tools (HTML, CSS, JS, etc) and took Bret's criticism as some sort of personal insult (I guess you like making websites).

I think that Bret's talk is about freeing your mind from thinking that the status quo of programming methodologies is the final say on the matter, and he points out that alternative methodologies (especially more human-centric and visual methodologies) are a neglected research area that was once more fruitful in Computer Science's formative years.

Bret's observations in this particular presentation are valid and insightful in their own right. His presentation style is also creative and enjoyable. Nothing in this presentation deserves the type of language that you invoke, especially in light of the rest Bret's recent works (http://worrydream.com/) that are neatly summed up by this latest presentation.

david927• 13 years ago

I'm not surprised at the language; it's war, after all. Bret and Alan Kay and others are saying, "We in this industry are pathetic and not even marginally professional." It's hard to hear and invokes sometimes an emotional response.

And what makes it hard to hear is that we know deep in our hearts, that's it's true, and as an industry, we're not really trying all that hard. It used to be Computer Science; now it's Computer Pop.

jasonwatkinspdx• 13 years ago

Characterizations like 'wrongheadedness' have no part in this discussion. If his conclusions are wrong you can explain why without generalizing to his nature as a person.

jowiar2• 13 years ago

It's funny that you mention testing. TDD/BDD/whatever IS declarative programming, except you're doing the declarative-to-imperative translation yourself.

TDD has always felt sort of wrong to me because it really felt like I was writing the same code twice. Progress, in this regard, would be the spec functioning as actual code.

rdtsc• 13 years ago

And there are projects, such as couch db, which are based on Erlang but are moving away from it. Why is that?

That is news to me. CouchDB is knee deep in Erlang and loving it. They are merging with BigCouch (from Cloudant) which is also full on Erlang.

Come to think of it, you are probably thinking of Couchbase, which doesn't really have much "couch" in except for name and couch's original author working on it.

Rather, it's because languages which are highly optimized for concurrency aren't always the best practical solution, even for problem domains that are highly concurrency bound, because there are a huge number of other practical constraints which can easily be just as or more important.

That is true however what is missing is that Erlang is optimized for _fault_tolerance_ first then, concurrency. Fault tolerance means isolation of resources and there is a price to pay for that. High concurrency, actor model, functional programming, immutable data, run-time code reloading all kind of flow from "fault tolerance first" idea.

It is funny, many libraries/languages/project that try to copy Erlang completely miss that one main point about and go on implementing "actors" run the good 'ol ring benchmark and claim "we surpassed Erlang, look at these results!". Yeah that is pretty amusing. I want to see them do a completely concurrent GC and hot code reloading (note: those are hard to add on, they have to be baked in to the language).

stass3• 13 years ago

They also seem to miss the preemptive scheduling, built-in flow-control and per-process GC (which leads to minimal GC pauses). Those are impossible to achieve without a purposely built VM. No solution on Sun JVM will ever be able to replace Erlang for applications which require low-latency processing. Similarly, no native-code solution can do so either: you need your runtime to be able to preempt user code at any point of time (i.e. Go is not a replacement for erlang).

crististm• 13 years ago

Some ideas worth mentioning are in Gerry Sussman's video.

The link in the presentation.

bachback3• 13 years ago

@InclinedPlane: I would suggest to you to ask yourself one question: what is the difference between a programmer and a user? if I code in language XY I'm already a consumer of a library called XY (and the operating system and the global network). most "programmers" today have nothing to do with memory (and the hardware of course). the next big thing is never just a simple iteration of the current paradigm. the problem with many ideas he mentions were not practical for a long time. On the other hand much of computing has simply to do with conventions (protocols of different kinds).

aufreak32• 13 years ago

Similarly, he casually mentions a programming language founded on unique principles designed for concurrency, he doesn't name it but that language is Erlang.

I haven't seen the talk yet and just browsed the slides, but just from your description Mozart/Oz could also fit the bill since it was designed for distributed/concurrent programming as well. Furthermore, Oz's "Browser" has some f-ing cool interactive stuff made possible due to the specific model of concurrency in the system. I must say that programming in Mozart/Oz feels completely different to Erlang, despite that fact that both have a common origin in Prolog.

<edit: adding more ..>

He is stuck in a model where "programming" is the act of translating an idea to a machine representation. But we've known for decades that at best this is a minority amount of the work necessary to build software.

There is a school of thought whereby "programming" is the act of coding itself. To put it in other words, it is a process of manipulating a formal system to cause effects in the world. That system could be a linear stream of symbols, or a 2D space of tiles, or any of myriad forms, but in the end much of the "pleasure of programming" is attributable to the possibility of play with such a system.

To jump a bit ahead, consider the Leap Motion controller. What if we had a system built where we can sculpt 3D geometries and had a way to map these "sculptures" to programs for doing various things? I say this 'cos "programming", a lot of the times, feels like origami to me when I'm actually coding. Lisps, in particular, evoke that feeling strongly. So, I'm excited about Leap Motion for the potential impact it can have on "programming".

I think representations are important, and the "school of direct manipulation" misses this point. Just because we have great computing power at our finger tips today, we won't revert to using roman numerals for numbers. One way to interpret the claims of proponents of direct manipulation is that programming ought to be a dialogue between a representation and the effect on the world instead of a monologue or, at best, a long distance call.

Bret has expressed favour for dynamic representations in some of his writings, but I'm not entirely sure that they are the best for dynamic processes. There is nothing uncool about static representations like code. (Well, that's all we've had for ages now, anyway.) What we've been lacking is a variety of static representations, since language has been central to our programming culture and history. What would an alien civilization program in if they had multidimensional communication means?

To conclude, my current belief is that anyone searching for "the one language" or "the one system" to rule them all is trying to find Joshu's "Mu" by studying scriptures. Every system (a.k.a. representation) is going to have certain aspects that it handles well and certain others that it does poorly on. That ought to be a theorem or something, but I'm not sophisticated enough, yet, to formally articulate that :)

aufreak32• 13 years ago

Ok, just saw the talk and Bret's certainly referring to Erlang here.

gdonelli• 13 years ago

Bret Victor is awesome

oh_teh_meows• 13 years ago

I think much of the motivation for developing new paradigms stems from growing frustration with tool-induced blindness, for lack of a better term. We spend much of our time chasing that seg-fault error instead of engineering the solution to the problem we're trying to solve.

A new programming paradigm allows us to reframe a problem in a different space, much like how changing a matrix's basis changes its apparent complexity, so to speak.

The ultimate goal, I think, is to come up with a paradigm that would map computational problems, without loss of generality, to what our primate brains would find intuitive. This lowers our cognitive burden when attempting to describe a solution, and also to allow us to see clearer what the cause of a problem may be. For example, if you're a game developer, and you find some rendering problems due to some objects intersecting each other, but you're not sure where it happens, Instead of poring over text dump of numerical vector coordinates, it'd be better to visualize them. The abnormality would present themselves clearly, even to a layman's eyes. I suspect this is what Victor is trying to get at. Imagine, if you will, that you have a graphical representation of your code, and a piece of code that could potentially segfault shows up as an irregularity of some form (different textures, different color, different shape, etc), so you can spot them and fix them right away. The irregularity is not a result of some static error analysis, but is instead the result of some emergent property resulting from graphical presentation rules (mapping from problem space to graphic space). We're good at spatial visualization, so I wonder if it's valid to come up with a programming language that would leverage more of our built-in capability in that area. This may seem like wishful thinking or even intractable (perhaps due to a certain perception limitation...which we have to overcome using more cognitive resources), but I certainly hope we'll get there in our life time.

ericHosick13• 13 years ago

The ultimate goal, I think, is to come up with a paradigm that would map computational problems, without loss of generality, to what our primate brains would find intuitive.

I really agree with this statement.

mmphosis• 13 years ago

  1. coding -> direct manipulation of data
  2. procedures -> goals and constraints
  3. text dump -> spatial representations
  4. sequential -> parallel

nickmain2• 13 years ago

I hope that in another 40 years the fact that programming and programmers ever existed is seen as temporary blip in the evolution of computing.

chj• 13 years ago

I don't think the future of programming is necessarily visual programming. Nature didn't program human bodies visually, and yet we are the most powerful living machines with powerful operating systems. But we do need to find a new "programing medium" like proteins that can build up ideas "organically".

dschiptsov• 13 years ago

Yeah, all the fundamental things were invented and researched before I was born.) and everything is still relevant and actual even in the midst of J* mass hysteria.)

xlayn5• 13 years ago

Come to wonder when I try to see the places on where this can be applied in my particular working field. If I check my everyday working flow, it seems like I'm constrained to all the scenarios that he mention, and I'm aware of how limiting it can be for what the technology and multiple cores... I'm talking about working on files, not interacting visually with the computer, not letting the computer figure out the stuff... not working parallely

and then I notice...

how I deliver software to a distributed environment of virtual machines some running on the same cpu, some boxes with their own one and realize that maybe the everyday cpu that you buy for your everyday box, is that small cpu on the cpu grid he shows.... network between the cpus are the lines that connects them.... and notice that I don't remember when it was the last time that I wrote the last tcp stack for connecting those machines.... so they somehow are figuring they out on they own how to talk to each other (notice how this is different from having a goal and try to achieve it) I still think we are way far from this happening (probably luckily for us)...

so: what if all he mentions here does somehow exist but it requires to shift the way you see stuff?

tomasien• 13 years ago

I just learned today that Smalltalk was the inspiration for a lot of what NeXT ended up doing with Objective C, which makes so much sense. At the end of the day, Xcode is just another set of text files in many ways, but in so many others it's so much more.

cconroy• 13 years ago

I wonder if there were people like this during the printing press days... ?

arikrak• 13 years ago

I like his overall message, but I wonder about the details. E.g. he attacks the existence of HTML and CSS, but there needs to be some universal format to store the markup and design in. So I guess he's attacking the idea of hand-coding them instead of using a WYSIWYG editor. But you can use something like Dreamweaver, Expression Web, or even more recent web apps like Divshot. I guess the problem in that they're not good enough yet, but that's not because people aren't trying to do it, it's because it is hard to do.

agentultra• 13 years ago

One thing I can't help but noticing is that the majority of discussions regarding this talk are focusing on the examples presented.

I thought it was pretty clear that the talk wasn't about whether constraint-based solvers and visual programming environments were the "future of programming." It was a talk about dogma. Brent points out that none of the examples he's mentioned are inherently important to what he was trying to get across: they were just examples. The point he was trying to elucidate was that our collective body of knowledge limits our ability to see new ways of thinking about the problems we face.

It is at least somewhat related to the adage, when you have a hammer every problem looks like a nail. He's just taking a historical view and using irony to illustrate his point. When computer technology reached a certain level of power there was a blossoming garden of innovative ideas because the majority of people didn't know what you cannot do.

What I think he was trying to say, and this is partly coloured by my own beliefs, is that beginner's mind is important. Dogma has a way of narrowing your view of the world. Innovation is slow and incremental but there's also a very real need to be wild and creative as well. There's room for both and we've just been focusing on one rather than the other for the last 40 years.

humanrebar6• 13 years ago

In this discussion I've been trying to make the point that he's missed the mark even in the idea that developer attitude is the inherent barrier preventing these breakthroughs. I believe he's stealing bases here. At least with respect to visual programming, there is objective evidence (that is easily google-able) that this problem is actively being tackled but with very little success. Active and recently failed projects seem to be glaring counterexamples to his broader point, at least with respect to the visual programming domain.

I suspect that my point about presuming developer attitudes are the biggest problems here can more broadly applied though I do not have enough experience with constraint-based solvers and his other examples to do more than wildly speculate.

jingo• 13 years ago

At the end of the video he warns of the dangers of "dogma".

He looks really nervous and impatient in this talk. He seems afraid that it won't be well received. If so, it is interesting to note that this is what dogma in fact leads to... repression of new ideas, fear of free thinkers and the stagnation of true scientific progress. It means guys like Bret Victor will feel awkward giving a talk that questions the status quo.

"Breakthroughs" do not happen when we are all surrounded by impenetrable walls of dogma. I wonder if we today could even recognize a true breakthrough in computing if we saw one. The only ones I see are from the era Bret is talking about. What happens when those are forgotten?

My friends, there is a simple thing I learned in another discpline outside of computing where I witnessed doing what others thought impossible: the power of irreverance. This is where true innovation comes from.

It means not only questioning whether you know what you are doing, but questioning whether others do. That frees you up to work on what you want to work on, even when it is in a different direction than everyone else. That is where innovation comes from: irreverance.

Knotwilg• 13 years ago

It will not help the discussion forward to behave like fans and treat any substantial critique as "you are one of those old fashioned mindless programming dudes".

On the other hand, in the light of Victor's achievements in industry (including "shipping" stuff) one cannot dismiss him as a smooth talking TEDdie either.

Victor has provided many crafted examples of what can be achieved in the fields of engineering, mathematics and programming, or any field of science and technology, if the feedback loop between the tool and its user is improved.

Indeed, this 30 minute talk does not compare to an industrial delivery. It has some theatre and some deliberate exaggerations or unfair treatment of society evolutions. Such is the nature of talks.

I do not think he sees the current state of affairs as a great mistake. He will surely acknowledge all practical circumstances and conceptual challenges that have made certain inferior designs survive while superior ones did not materialize.

The message is: we shouldn't accept this state of affairs as final or as one that can only be marginally improved. It can still be radically improved. The industry is still fresh - even ideas from the 60s are valid and underachieved.

I see his critique as a positive statement of hope and encouragement, not as a pointing finger to all you silly programmers.

rusew• 13 years ago

Does anyone know what font he uses in his slides? I really like their look.

masswerk• 13 years ago

Me too! – It has this classic modern look with a distinct impact printer feel about it.

nikso• 13 years ago

A powerful thought.

We should feel lucky that what we love is such novel and unexplored field.

I'm quite confident that we will eventually move forward from this seemingly stale period of programming paradigms. Because after all, we all know the frustration brought from the initial stages of learning a new thing; and we all know the much greater awe of mastering it.

The Future of Programming

Related Stories