5 ms·

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.

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/
      - shalabhc 9y ago
        Yes, somewhat like these, but having the ability to inspect and simulate effects on intermediate forms and systems. So something along the lines of light table but being able to show more than just the immediate program. Copying something I wrote in another thread: I want to see not just the immediate program I'm manipulating (text or otherwise) but also the implications - the affected parts of various other intermediate representations all the way to the running, live system that will be affected.
- shalabhc 9y ago
  Do you see this as a useful dichotomy? In reality no system is truly sealed - it's just temporarily sealed between evolution steps, no?
  - fnord123 9y ago
    I do find it a useful dichotomy because I work with people who evolve their code and wonder why I get my back up about monkey patching (because it's often my job to turn research or prototype quality code into reliable code). If you've ever had to make another person's research or prototype quality code more robust it can be easy to wonder how on Earth they work the way they do. Having this dichotomy in mind makes it easier to have more sympathy. It works both ways. Researchers need to understand why platform development moves so slow. This dichotomy helps reason about it. But you're right, between evolution steps the system is not sealed. That's a concern and why projects like Debian are keen to have reproducible builds. It's also a big part of why containerization is becoming so popular.
    - shalabhc 9y ago
      Ah I see. So with 'sealed' you mean things like reproducible builds and being able to determine the exact set of sources, etc? The containerization movement is interesting - while having these 'sealed' virtual environments and reproducible system builds is the right direction, I'm amazed at the size and weight of each of these.
      - fnord123 9y ago
        Sure. By sealed I mean you compiled the program, you might have a turing incomplete configuration (e.g. ini, toml, json) and you can reason about the program. And by evolving (or, I guess unsealed) you are in the process of editing the program. Or you monkey patch it when you run it. But with things like LD_PRELOAD, different .so minor versions, etc, a compiled program suddenly straddles the categories. Hence my comment about reproducible builds and containerization.

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/
    - shalabhc 9y ago
      Yes, somewhat like these, but having the ability to inspect and simulate effects on intermediate forms and systems. So something along the lines of light table but being able to show more than just the immediate program. Copying something I wrote in another thread: I want to see not just the immediate program I'm manipulating (text or otherwise) but also the implications - the affected parts of various other intermediate representations all the way to the running, live system that will be affected.
shalabhc 9y ago
Do you see this as a useful dichotomy? In reality no system is truly sealed - it's just temporarily sealed between evolution steps, no?
- fnord123 9y ago
  I do find it a useful dichotomy because I work with people who evolve their code and wonder why I get my back up about monkey patching (because it's often my job to turn research or prototype quality code into reliable code). If you've ever had to make another person's research or prototype quality code more robust it can be easy to wonder how on Earth they work the way they do. Having this dichotomy in mind makes it easier to have more sympathy. It works both ways. Researchers need to understand why platform development moves so slow. This dichotomy helps reason about it. But you're right, between evolution steps the system is not sealed. That's a concern and why projects like Debian are keen to have reproducible builds. It's also a big part of why containerization is becoming so popular.
  - shalabhc 9y ago
    Ah I see. So with 'sealed' you mean things like reproducible builds and being able to determine the exact set of sources, etc? The containerization movement is interesting - while having these 'sealed' virtual environments and reproducible system builds is the right direction, I'm amazed at the size and weight of each of these.
    - fnord123 9y ago
      Sure. By sealed I mean you compiled the program, you might have a turing incomplete configuration (e.g. ini, toml, json) and you can reason about the program. And by evolving (or, I guess unsealed) you are in the process of editing the program. Or you monkey patch it when you run it. But with things like LD_PRELOAD, different .so minor versions, etc, a compiled program suddenly straddles the categories. Hence my comment about reproducible builds and containerization.