26 ms·

The Future of Programming

• rpearl 13y ago
  "The most dangerous thought you can have as a creative person is to think you know what you're doing."
  • tmoertel 13y 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 13y ago
    I believe this so deeply, I love hearing him make such a compelling argument for it.
• asselinpaul 13y ago
  Watching this now but I expect greatness like all his talks.
• ibdknox 13y 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 https://thestrangeloop.com/sessions/tbd--11
  • groby_b 13y 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 :)
    • ibdknox 13y 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. :)
      • groby_b 13y ago
        This reminds me of the "data-oriented design" debate that's been raging in game programming for a while. I assume you've seen e.g. http://harmful.cat-v.org/software/OO_programming/_pdf/Pitfalls_of_Object_Oriented_Programming_GCAP_09.pdf http://harmful.cat-v.org/software/OO_programming/_pdf/Pitfal... (or similar papers)
        • ibdknox 13y ago
          I actually have a post about data-centricity in games, though from a very different angle. http://www.chris-granger.com/2012/12/11/anatomy-of-a-knockout/ http://www.chris-granger.com/2012/12/11/anatomy-of-a-knockou...
          • johnrob 13y ago
            It seems like one large breakthrough in programming could simply be using the features of a language in a manner that best suits the problem. That's what I get from your blog post: design for what makes sense - not for what looks normal during a review. One thing I envy from LISP is that there seem to be few 'best practices' that ultimately make our applications harder to modify.
• rasur 13y 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 ;) )
• deleted 13y ago
  [deleted]
• ibudiallo 13y ago
  I am half way there and i have never been disappointed by Bret Victor. He comes from the future.
  • grey-area 13y ago
    Or, in this case, the past.
• _pius 13y ago
  This is a brilliant, trenchant indictment of the state of our industry.
• hcarvalhoalves 13y ago
  Love Bret's style. Also love how the crowd went silent after the "API" slide.
  • kintamanimatt 13y 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 13y 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-api http://stackoverflow.com/questions/15214526/why-hypermedia-a...
• zekenie 13y 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 13y 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!
• ThomPete 13y ago
  "they didn't know what they were doing, so they tried everything"
• michaelrbock 13y 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."
• tel 13y 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 13y 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.
    • tel 13y 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 13y 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.
  • rdouble 13y 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 13y 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.
  • sunnybythesea 13y ago
    He is a modern day Renaissance man.
    • sunnybythesea 13y ago
      Why was this downvoted?
  • agilebyte 13y 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 13y 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.
  • pestaa 13y 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.
    • InclinedPlane 13y 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.
• creed0r 13y ago
  ABSOLUT.MUST.SEE.
• dbpokorny 13y ago
  I wrote down some thoughts on this subject. http://dbpokorny.blogspot.com/2013/07/permission-based-programming-languages.html http://dbpokorny.blogspot.com/2013/07/permission-based-progr...
• Kronopath 13y 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.
• deleted 13y ago
  [deleted]
• calibraxis 13y ago
  What should I read to understand his anti-API point better? Learn about RDF? Or is there something better?
  • Kafka 13y ago
    I'm not sure but I came to think of the HATEOAS constraint of REST.
  • jgon 13y 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.
  • ericHosick 13y 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.
    • 13y ago
• pnathan 13y 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.
  • AsymetricCom 13y ago
    I think you might be thinking of the RNA metaprotocol or Recursive Network Architecture.
    • pnathan 13y ago
      Phenotropics, actually. http://discovermagazine.com/2007/jul/jaron2019s-world 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.
• humanrebar 13y 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 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
  • sramsay 13y 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 . . .
    • anigbrowl 13y ago
      Why, what have you got?
    • ericHosick 13y 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.
• ionforce 13y ago
  This talk is so fluffy and empty. Surely there must be someone else who did not enjoy it.
  • cia_plant 13y 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.
    • sanderjd 13y 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 13y 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 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.
      • RogerL 13y ago
        Thanks for the link. I have the exact opposite reaction to the video. He is solving toy problems with toy ideas. I think his page Kill Math (http://worrydream.com/KillMath/ http://worrydream.com/KillMath/) illuminates this point. I don't think he can think symbolically very well (no insult intended, I can't think visually very well). There are certainly times where graphing things make a lot of sense, but to throw out analytical math? Come on. By and large he is getting the "feel" of a system, but he cannot really reason about it, prove things about it, extend it, or design new systems with vision (there are obvious counterexamples). In another video he shows an IDE where he scrubs constants, and it changes the behavior of the concurrently running program (changing the size of an ellipse or tree branch). It's neat. But, again, toy problem. First of all, we shouldn't be programming with constants. Second, anything complicated will have relationships between the data - scrubbing one value will just end up giving you nonsense. Third, it just doesn't make any sense in many contexts. I work in computer vision currently, and I can't think of anything but the most superficial way I could incorporate scrubbing. He made some comment about how no one could know what a bezier curve is unless they had a nice little picture of it in their IDE to match the function call. That's silly. I actually use splines and other curve fitting in my work, and I have to actually understand the math. Do I use cubic splines, a Hermite interpolation, bezier, or something else? I don't decide that by drawing some pictures - the search space is too big, I'll never cover all the possibilities. I have to do math to figure out the best choice. In that same video he went on to demonstrate programming binary search using visual techniques. Unfortunately he wrote a buggy implementation, and stood there exclaiming how his visual technique found a different bug. It did, a super trivial one, but it completely failed to reveal the deeper issue. And, there was no real way for his visual method to have found it. Visualization is an very powerful tool, but it is one tool in the toolchest. There is a scene in the movie Contact with Jodie Foster using headphones to listen to the SETI signal. We all know that is bogus - the search space is far too vast for aural search to work. His ideas are terribly wrong headed. Make interfaces to help give us intuition? Absolutely! Use graphics where analytics fail. Of course! But don't conclude that math is a "freakish knack", as he does, or that math is some sort of temple (he calls mathematicians "clergy", and then goes on to throw in an insult that many are just pretending to understand). I posted in another comment how crazy it would be to have a calculator that scrubs. Well, he shows one on that page. Really? The day bridge designers start using scrubbing apps to design our bridges is the day I'm never crossing a bridge again. Edit to add: his website is another example of this. I can't find anything on it. There are a bunch of pictures, and my eyes saccade around, but what is here, what is his point? I dunno. I can click, and click, and click, and start to get an idea, but there is always more hidden away behind pictures. It's barely workable as a personal website, and would be a disaster as a way to organize anything larger. I don't mean to pick on it - as an art project or glimpse into how he thinks, it's great. I just point out it illustrates (pun kind of intended) the strengths and limits of visual presentation. You tell me, for example, without grep or google search, whether he has written about coffee. If you disagree, please reply in pictures only! ;)
• deleted 13y ago
  [deleted]
• tmarthal 13y 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
  • deleted 13y ago
    [deleted]
  • zalew 13y ago
    Ericsson - Erlang http://en.wikipedia.org/wiki/Erlang_%28programming_language%29 http://en.wikipedia.org/wiki/Erlang_%28programming_language%... http://en.wikipedia.org/wiki/Open_Telecom_Platform http://en.wikipedia.org/wiki/Open_Telecom_Platform
  • grey-area 13y ago
    It's a reference to Erlang at Ericsson. See the notes below the video.
  • deleted 13y ago
    [deleted]
• marcamillion 13y 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?
  • sanderjd 13y 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.
    • marcamillion 13y ago
      Oh ok. I was wondering how comes the audience (and video) seems so "current", but the content looks so dated.
  • humanrebar 13y 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.
    • AsymetricCom 13y 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.
• 6ren 13y ago
  Could someone upload this to youtube, please? vimeo is unwatchable on old/underpowered devices.
  • slacka 13y ago
    Here you go: http://youtu.be/8pTEmbeENF4 http://youtu.be/8pTEmbeENF4
• artagnon 13y 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.
• dman 13y ago
  Eternally relevant when discussing worlds of computing that could have been - http://www.dreamsongs.com/RiseOfWorseIsBetter.html http://www.dreamsongs.com/RiseOfWorseIsBetter.html
• jjindev 13y 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 13y ago
  Subtext seemed like a good abstraction what happened there? http://www.oscon.com/oscon2010/public/schedule/detail/15484 http://www.oscon.com/oscon2010/public/schedule/detail/15484
• InclinedPlane 13y 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.
• gdonelli 13y ago
  Bret Victor is awesome
• oh_teh_meows 13y 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.
  • ericHosick 13y 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 13y ago
  1. coding -> direct manipulation of data 2. procedures -> goals and constraints 3. text dump -> spatial representations 4. sequential -> parallel
• nickmain 13y 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 13y 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 13y 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.)
• xlayn 13y 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 13y 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 13y ago
  I wonder if there were people like this during the printing press days... ?
• arikrak 13y 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 13y 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.
  • humanrebar 13y 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 13y 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 13y 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 13y ago
  Does anyone know what font he uses in his slides? I really like their look.
  • masswerk 13y ago
    Me too! – It has this classic modern look with a distinct impact printer feel about it.
• nikso 13y 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.