6 ms·

I find the jab at Bret Victor especially undeserved. He's an interaction designer (a really good one who sees through all the fads[0], which is kind of the oppo

I find the jab at Bret Victor especially undeserved. He's an interaction designer (a really good one who sees through all the fads[0], which is kind of the opposite of what this one-liner implies). His focus is on better interface design, not formal language design; why criticize someone for something they're not trying to do? And it's not useless; we probably wouldn't have had Elm without Bret Victor's Inventing on Principle[1][2]. And there has been some progress in that direction of interface design of, for a lack of a better term, "programmable environments": look at Apparatus, for example[3]. Where would you even fit that on these slides? [0] http://worrydream.com/ABriefRantOnTheFutureOfInteractionDesign/ http://worrydream.com/ABriefRantOnTheFutureOfInteractionDesi... [1] http://elm-lang.org/ http://elm-lang.org/ [2] https://vimeo.com/36579366 https://vimeo.com/36579366 [3] http://aprt.us/ http://aprt.us/

TuringTest 9y ago
Quite true. I find likely that the next revolution in programming languages will come from designing a PL that's a good fit for these programmable environments. Maybe it should break from current undisputed conventions like the radical separation between "data" and "source code", and be more like a spreadsheet. End-User Development has lots of under-explored ideas on how to build software automatisms that don't require the end user to learn a hard formalism (even if such formalism exists as the basis for the system). Though I understand that programming language theorists are not interested in that angle of the evolution of PLs.
- fnord123 9y ago
  There is a dichotomy between sealed programs and evolving programs. Evolving programs like Smalltalk or REPLs are great for exploratory work. Almost everyone wants sealed programs for systems to work reliably. This runs along the lines of Ousterhout's dichotomy as well - scripting vs systems languages. The engineering break through will be when we have a scripting/evolving system that can be more easily distilled into sealed systems. So people poking around in a spreadsheet will be able to turn that into a reliable application. IMO, TDD and BDD could be seen as attempts to do exactly this.
  - TuringTest 9y ago
    > The engineering break through will be when we have a scripting/evolving system that can be more easily distilled into sealed systems. So people poking around in a spreadsheet will be able to turn that into a reliable application. Yeah, I see that as a likely evolution as well. In some ways, an IDE is already an exploratory system with a focus on delivering a sealed system - the final compiled software represented by the source code. I believe this combination is what made IDEs so successful and universally desirable, and future programmable environments should share these traits. Auto-completion, refactoring and code-browsing tools support the exploratory work. The problem is that IDEs are not so good at exploration as a REPL because they're unable to store intermediate results and states. TDD could then be seen as an ad-hoc way to store such intermediate state.
    - shalabhc 9y ago
      Agree on the benefits of IDEs and REPLs. An IDE/language with integrated notebook-style REPLs might be useful too. Maybe you want to create parts of the system by interacting with a REPL (instead of writing a static block of text) - and then you'd want to record how you created this specific artifact. The other thing that would help, and my personal wish, is better simulation and the ability to see indirect effects of changes - instead of only showing what is directly modified (i.e. a line of code) and leaving the simulation up to the human.
      - TuringTest 9y ago
        > Maybe you want to create parts of the system by interacting with a REPL (instead of writing a static block of text) - and then you'd want to record how you created this specific artifact. Yes, exactly. You get that with a REPL (e.g. Lisp or Python) and copy-pasting to the source code files, but it's far from ideal. > The other thing that would help, and my personal wish, is better simulation and the ability to see indirect effects of changes So, sort like explorable explanations[1][2], but aimed at developing a new model and not just exploring one that has been already made? That's what I'd like to see, too. [1] http://worrydream.com/ExplorableExplanations/ http://worrydream.com/ExplorableExplanations/ [2] http://worrydream.com/TenBrighterIdeas/ http://worrydream.com/TenBrighterIdeas/

TuringTest 9y ago

Quite true. I find likely that the next revolution in programming languages will come from designing a PL that's a good fit for these programmable environments. Maybe it should break from current undisputed conventions like the radical separation between "data" and "source code", and be more like a spreadsheet. End-User Development has lots of under-explored ideas on how to build software automatisms that don't require the end user to learn a hard formalism (even if such formalism exists as the basis for the system). Though I understand that programming language theorists are not interested in that angle of the evolution of PLs.

fnord123 9y ago
There is a dichotomy between sealed programs and evolving programs. Evolving programs like Smalltalk or REPLs are great for exploratory work. Almost everyone wants sealed programs for systems to work reliably. This runs along the lines of Ousterhout's dichotomy as well - scripting vs systems languages. The engineering break through will be when we have a scripting/evolving system that can be more easily distilled into sealed systems. So people poking around in a spreadsheet will be able to turn that into a reliable application. IMO, TDD and BDD could be seen as attempts to do exactly this.
- TuringTest 9y ago
  > The engineering break through will be when we have a scripting/evolving system that can be more easily distilled into sealed systems. So people poking around in a spreadsheet will be able to turn that into a reliable application. Yeah, I see that as a likely evolution as well. In some ways, an IDE is already an exploratory system with a focus on delivering a sealed system - the final compiled software represented by the source code. I believe this combination is what made IDEs so successful and universally desirable, and future programmable environments should share these traits. Auto-completion, refactoring and code-browsing tools support the exploratory work. The problem is that IDEs are not so good at exploration as a REPL because they're unable to store intermediate results and states. TDD could then be seen as an ad-hoc way to store such intermediate state.
  - shalabhc 9y ago
    Agree on the benefits of IDEs and REPLs. An IDE/language with integrated notebook-style REPLs might be useful too. Maybe you want to create parts of the system by interacting with a REPL (instead of writing a static block of text) - and then you'd want to record how you created this specific artifact. The other thing that would help, and my personal wish, is better simulation and the ability to see indirect effects of changes - instead of only showing what is directly modified (i.e. a line of code) and leaving the simulation up to the human.
    - TuringTest 9y ago
      > Maybe you want to create parts of the system by interacting with a REPL (instead of writing a static block of text) - and then you'd want to record how you created this specific artifact. Yes, exactly. You get that with a REPL (e.g. Lisp or Python) and copy-pasting to the source code files, but it's far from ideal. > The other thing that would help, and my personal wish, is better simulation and the ability to see indirect effects of changes So, sort like explorable explanations[1][2], but aimed at developing a new model and not just exploring one that has been already made? That's what I'd like to see, too. [1] http://worrydream.com/ExplorableExplanations/ http://worrydream.com/ExplorableExplanations/ [2] http://worrydream.com/TenBrighterIdeas/ http://worrydream.com/TenBrighterIdeas/