5 ms·

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 missin

by JunkDNA 13y 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.

InclinedPlane 13y 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.
- StandardFuture 13y ago
  Hrmmm ... you seem to still be tremendously missing the overarching purpose of this speech. Obviously to delve proficiently into every aspect of programming through the ages and why things are the way they are now (e.g. what 'won' out and why) would require a Course and not a talk. You seem to think that the points brought up in this talk diminish the idea that things now DO work. However, what was stressed was avoiding the trap of discontinuing the pursuit of thinking outside the box. I am also questioning how much of the video you actually paid attention too (note: I am not questioning how much you watched). I say this because your critique is focused on the topics that he covered in the earlier parts of the video and then (LOL) you quickly criticize him for talking about concurrency (in your previous comment)... I clearly remember him talking about programming on Massively Parallel architectures without the need for sequential logic control via multiplexing using threads and locks. I imagine, though, it is possible you did not critique this point because it is obvious (to everyone) that this is the ultimate direction of computing (synchronously with the end of Moore’s law as well). Ahhh now that’s interesting, we are entering an era where there could possibly be a legitimate use to trying/conceiving new methods of programming? Who would have thought? Maybe you just realized that you would have looked extremely foolish spending time on critiquing that point? IDK … excuse my ignorance. Also you constantly argue FOR basic management techniques and methods (as if that countermoves Bret’s arguments) … but you fail to realize that spatial structuring of programs would be a visual management technique in itself that could THEN too have tools developed along with it that would be isomorphic to modern integration, testing management. But I won’t bother delving into that subject as I am much more ignorant on this and more importantly … I would hate to upset you, Master. Oh and btw (before accusations fly) I am not a Hero worshiper … this is the first time I have ever even heard of Bret Victor. Please don’t gasp too loud.
  - Ygg2 13y ago
    I definetely get what OP was trying to say. Bret presented something that sounds a lot like the future even though it definitely isn't. Some of listed alternatives like direct data manipulation, or visual languages or non-text languages have MAJOR deficiences and stumbling blocks that prevented them from achieving dominance. Though in some cases it basically does boil down to which is cheaper, more familiar.
joe_the_user 13y 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).
- floobynewb 13y ago
  I agree with this. To get out of this local trap we are going to need something revolutionary. This is not something you can plow money into, it will come, if indeed it ever comes, from left field. My bet is there is a new 'frame' to be found somewhere out in the land of mathematical abstraction. I think to solve this one we are going to have to get right down to the nitty gritty, where does complexity come from, how specifically does structure emerge from non structure? How can we design such systems?
  - joe_the_user 13y ago
    It's true you couldn't plow money into such a project. But I always wondered why, when confronted with a problem like this, you couldn't hire one smart organizers who hire forty dispersed teams who'd each follow a different lead. And hire another ten teams who'd be tasked with following and integrating the work of the forty teams (numbers arbitrary but you get the picture). I suppose that's how grants are supposed to work already but it seems these mostly degenerated to all following the intellectual trend with the most currency.
bulatb 13y 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.
- oskarth 13y ago
  What if programming consists of only refactoring? Then there is no separate "refactoring step", just programming and neglect. This is what Bret Victor is getting at. It is about finding the right medium to work in.
  - Ygg2 13y ago
    We have that already i.e. coding to a test. It sucks because you never seem to grasp the entirety of a program but instead just hack until every flag is green. It doesn't prevent entropy either. Only thing that prevents code entropy is careful and deliberate application of best practices when needed i.e. a shit ton of extreme effort.
    - minor_nitwit 13y ago
      he shows an example in his talk of inventing on principle where the test happen in real time as the code is written. It's pretty neat.
- dustingetz 13y ago

by JunkDNA 13y ago

InclinedPlane 13y 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.

StandardFuture 13y ago
Hrmmm ... you seem to still be tremendously missing the overarching purpose of this speech. Obviously to delve proficiently into every aspect of programming through the ages and why things are the way they are now (e.g. what 'won' out and why) would require a Course and not a talk. You seem to think that the points brought up in this talk diminish the idea that things now DO work. However, what was stressed was avoiding the trap of discontinuing the pursuit of thinking outside the box. I am also questioning how much of the video you actually paid attention too (note: I am not questioning how much you watched). I say this because your critique is focused on the topics that he covered in the earlier parts of the video and then (LOL) you quickly criticize him for talking about concurrency (in your previous comment)... I clearly remember him talking about programming on Massively Parallel architectures without the need for sequential logic control via multiplexing using threads and locks. I imagine, though, it is possible you did not critique this point because it is obvious (to everyone) that this is the ultimate direction of computing (synchronously with the end of Moore’s law as well). Ahhh now that’s interesting, we are entering an era where there could possibly be a legitimate use to trying/conceiving new methods of programming? Who would have thought? Maybe you just realized that you would have looked extremely foolish spending time on critiquing that point? IDK … excuse my ignorance. Also you constantly argue FOR basic management techniques and methods (as if that countermoves Bret’s arguments) … but you fail to realize that spatial structuring of programs would be a visual management technique in itself that could THEN too have tools developed along with it that would be isomorphic to modern integration, testing management. But I won’t bother delving into that subject as I am much more ignorant on this and more importantly … I would hate to upset you, Master. Oh and btw (before accusations fly) I am not a Hero worshiper … this is the first time I have ever even heard of Bret Victor. Please don’t gasp too loud.
- Ygg2 13y ago
  I definetely get what OP was trying to say. Bret presented something that sounds a lot like the future even though it definitely isn't. Some of listed alternatives like direct data manipulation, or visual languages or non-text languages have MAJOR deficiences and stumbling blocks that prevented them from achieving dominance. Though in some cases it basically does boil down to which is cheaper, more familiar.

joe_the_user 13y 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).

floobynewb 13y ago
I agree with this. To get out of this local trap we are going to need something revolutionary. This is not something you can plow money into, it will come, if indeed it ever comes, from left field. My bet is there is a new 'frame' to be found somewhere out in the land of mathematical abstraction. I think to solve this one we are going to have to get right down to the nitty gritty, where does complexity come from, how specifically does structure emerge from non structure? How can we design such systems?
- joe_the_user 13y ago
  It's true you couldn't plow money into such a project. But I always wondered why, when confronted with a problem like this, you couldn't hire one smart organizers who hire forty dispersed teams who'd each follow a different lead. And hire another ten teams who'd be tasked with following and integrating the work of the forty teams (numbers arbitrary but you get the picture). I suppose that's how grants are supposed to work already but it seems these mostly degenerated to all following the intellectual trend with the most currency.

bulatb 13y 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.

oskarth 13y ago
What if programming consists of only refactoring? Then there is no separate "refactoring step", just programming and neglect. This is what Bret Victor is getting at. It is about finding the right medium to work in.
- Ygg2 13y ago
  We have that already i.e. coding to a test. It sucks because you never seem to grasp the entirety of a program but instead just hack until every flag is green. It doesn't prevent entropy either. Only thing that prevents code entropy is careful and deliberate application of best practices when needed i.e. a shit ton of extreme effort.
  - minor_nitwit 13y ago
    he shows an example in his talk of inventing on principle where the test happen in real time as the code is written. It's pretty neat.
dustingetz 13y ago