3 ms·

There are many such things in historical PL design. I consider immutability in Erlang to be another example... what Erlang needed was processes to not be able t

by jerf 4y ago

There are many such things in historical PL design. I consider immutability in Erlang to be another example... what Erlang needed was processes to not be able to send each other mutable references. Full immutability in data achieves that goal, but is an over reaction. It was sufficient when the type system simply doesn't have references in it. Another example is the whole dynamic scripting language world considered as a reaction to the terrible static world of the 1990s. Yes, the 1990s were too static, no question, but that didn't mean we needed to turn all objects into hash tables, be able to dynamically re-write classes on both the class and the instance level, and just generally make everything, everywhere so dynamic that the language spends the majority of its runtime basically checking to see that nothing has dynamically changed since last time it did something. The PL design world is learning and growing and I find it an interesting story over time. Unfortunately when proving out a theory takes a minimum of about 20 years from thousands of programmers it's a slow process. (Also, while my comments above are certainly in some sense criticisms of the languages, I actually don't intend them as criticisms of the people involved. It is still an amazing achievement to move the state of the art ahead at all in such a harsh environment; I'm not angry that they didn't in one fell swoop fix all problems forever, even for decades not yet here.)

cmrdporcupine 4y ago
re: dynamism/late-binding; it was seen as very exciting at the time. At least to me. Maybe under the influence of Self and Smalltalk, which were doing interesting things with object behaviour composition using delegation and slots and all sorts of late-bound magic. It definitely let people experiment. In JavaScript especially a thousand (inelegant) flowers bloomed and then some practices were codified into later revisions of the language and the door shut on that kind of experimentation. I'm a big fan of static type systems generally. But I do think dynamic scripting languages have their place. In particular as prototyping/scripting languages embedded in larger more robust runtimes. e.g. the original goal of JavaScript (which has now become a full blown application development language). AutoCAD had/has its lisp dialect. Emacs its own (ok it's more than just embedded scripting in that case). Many FPGA and HW eng tools use Tcl. Various games have Lua etc etc. This is a useful pattern potentially.
- jerf 4y ago
  "But I do think dynamic scripting languages have their place." My thought isn't actually static/dynamic, but rather the amount of dynamicness. I suspect we could get 99%+ of the benefits of static languages at a fraction of the runtime cost if someone redid a dynamic language from scratch today to be dynamic only in selected ways. You pay a lot of runtime performance in Python to be able to do things like at any time edit a method three levels up the inheritance hierarchy, but you almost never actually do that sort of thing. One idea I cite often is to have a declaration phase versus a runtime phase, because the vast, vast bulk of "dynamicness" is achieved at startup. A JIT could be really aggressive about a lot of optimizations if the language itself guaranteed that after a program (or a module, or a function, or whatever makes sense in the end) declares itself "done being dynamic" that there will be no more changes. In fact I think there's a niche for a high-performance "mostly" dynamic language with threading built in from the beginning in the next 5-10 years. Static languages are getting most of the attention right now, and there's reasons for that, but I think there's a niche here that is not being well explored. Personally I'm having a hard time using dynamically-typed languages right now because the amount of performance I'm throwing away almost makes me nauseous. That's a combination of the problem with being too dynamic, as I said, and multi-decade-old implementations not being able to be multithreaded very easily. I think a language that solved those two things could be very interesting.
  - zozbot234 4y ago
    Modern static languages generally support opt-in "dynamic" facilities. For instance, C++ has its RTTI support, Haskell has 'Dynamic' and Rust has the 'Any' trait.
  - cmrdporcupine 4y ago
    The thing is that behind the scenes it's just all really hashtables, so while all that that pointless dynamism is expensive computationally it's also "free" from an implementation PoV, so that's what people do. And then later optimize with caching dispatch tables, etc. etc. Honestly I'm surprised after all these years that there hasn't been any success getting serious hardware support for the kinds of dynamic dispatch tables used in late bound languages. Like hardware accelerated string hash tables, etc.

by jerf 4y ago

cmrdporcupine 4y ago

re: dynamism/late-binding; it was seen as very exciting at the time. At least to me. Maybe under the influence of Self and Smalltalk, which were doing interesting things with object behaviour composition using delegation and slots and all sorts of late-bound magic. It definitely let people experiment. In JavaScript especially a thousand (inelegant) flowers bloomed and then some practices were codified into later revisions of the language and the door shut on that kind of experimentation. I'm a big fan of static type systems generally. But I do think dynamic scripting languages have their place. In particular as prototyping/scripting languages embedded in larger more robust runtimes. e.g. the original goal of JavaScript (which has now become a full blown application development language). AutoCAD had/has its lisp dialect. Emacs its own (ok it's more than just embedded scripting in that case). Many FPGA and HW eng tools use Tcl. Various games have Lua etc etc. This is a useful pattern potentially.

jerf 4y ago
"But I do think dynamic scripting languages have their place." My thought isn't actually static/dynamic, but rather the amount of dynamicness. I suspect we could get 99%+ of the benefits of static languages at a fraction of the runtime cost if someone redid a dynamic language from scratch today to be dynamic only in selected ways. You pay a lot of runtime performance in Python to be able to do things like at any time edit a method three levels up the inheritance hierarchy, but you almost never actually do that sort of thing. One idea I cite often is to have a declaration phase versus a runtime phase, because the vast, vast bulk of "dynamicness" is achieved at startup. A JIT could be really aggressive about a lot of optimizations if the language itself guaranteed that after a program (or a module, or a function, or whatever makes sense in the end) declares itself "done being dynamic" that there will be no more changes. In fact I think there's a niche for a high-performance "mostly" dynamic language with threading built in from the beginning in the next 5-10 years. Static languages are getting most of the attention right now, and there's reasons for that, but I think there's a niche here that is not being well explored. Personally I'm having a hard time using dynamically-typed languages right now because the amount of performance I'm throwing away almost makes me nauseous. That's a combination of the problem with being too dynamic, as I said, and multi-decade-old implementations not being able to be multithreaded very easily. I think a language that solved those two things could be very interesting.
- zozbot234 4y ago
  Modern static languages generally support opt-in "dynamic" facilities. For instance, C++ has its RTTI support, Haskell has 'Dynamic' and Rust has the 'Any' trait.
- cmrdporcupine 4y ago
  The thing is that behind the scenes it's just all really hashtables, so while all that that pointless dynamism is expensive computationally it's also "free" from an implementation PoV, so that's what people do. And then later optimize with caching dispatch tables, etc. etc. Honestly I'm surprised after all these years that there hasn't been any success getting serious hardware support for the kinds of dynamic dispatch tables used in late bound languages. Like hardware accelerated string hash tables, etc.