Dreaming the future of software; Project Editor ECMAScript 2015;
Reformed Smalltalker
JavaScript historian dl.acm.org/doi/abs/10.114…
@allenwb@mastodon.social
I'm excited to share The Whole Code Catalog: my reviews of two-dozen programming-ish tools to inspire the creators of tomorrow's programming languages and computational mediums futureofcoding.org/catalog/
Speaking of history& conferences. Progamming language connoisseurs: the 4th History of Programming Languages Conference (HOPL IV) will be in London next June.
HOPLs only happen every 12-15 years so attending will be an unique opportunity.
hopl4.sigplan.org/
BTW, I just came up with the term “Heirloom Software/Systems”. Really like it.
Has anybody else used heirloom in this context?
I’ve been looking for something better term than “legacy” especially for significant software that grappled with (and perhaps solved) “modern” problems.
This is a great idea. Although it doesn’t need to be a separate track. It would be great if most conferences simply included “history of relevant [to the topic of the conference] technologies and heirloom solutions.
So you can dynamically import, but not dynamically delete in Javascript.
I think I just found my next spec to write
@TC39 expect something from me soon.
The brief of language standards committees usually only cover the core language, not language related tools.
Yet, the best developer experiences are with languages that are co-designed/co-evolved with their dev environment allowing lang/env trade-offs.
1/
JavaScript is a weird language, normal linear code editors choke on it (aka "callback hell"). The committee that designs the language changed JS to try to make it fit the editors most people use and now it has become a chaotic mess.
scripting.com/2019/08/19.htm…
Classic high productivity (and usually fun) programming experiences like Smalltalk, Visual Basic, @davewiner's Frontier, C#+Visual Studio, etc are all co-designed language+editor environments.
(Remember, the "i" in IDE stands for integrated.)
2/
There are good reasons non-integrated languages have usually prevailed: multiple suppliers, familiarity, easier to adopt, cleaner semantics, easier to evolve and adapt, etc.
Challenge: create a new co-designed language/dev env w/ explicit intent of overcoming the barriers.
3/3
The primary motivation was ensuring that, in the presence of Proxy, host & implementation defined exotic objects, execution sandboxes could still depend upon integrity related constraints such as what it means for objects to be "frozen" or for a property to be non-configurable.
For many years, the common wisdom was that the only way to make 1995-2005 era JS faster was to add new syntax (e.g., nominal static class & machine types, etc.). Then engine implementors proved otherwise. Usually, engines figure out how to make important things faster.
I think keeping a language simpler for its users at the cost of requirng work from engine implementors is a good trade-off.
Making things fast is one of the primary jobs for implementors of mature languages. Let’s maintain full employment for language implementors!
👍 However, this problem isn't new to JS.
The worse code I ever saw was a many page (actually boxes of cards) COBOL program that had been manually transcribed into a single Smalltalk class.
They took the "Smalltalk is the successor to COBOL" marketing slogan literally
Just learn and use JS to write JS. What works in Java or C++ or Kotlin or Go or... whatever... leave those things to those languages.
If you really just want to write those languages, great. Do so! And then let tools transpile it to JS for you.
But stop writing not-JS-in-JS.
My suggestion is, and always will be, drop the mindset that JS was designed poorly or non-intuitively.
Instead try to learn how JS works, embrace it, and go with its grain. So much more pleasant to write JS the way it works most naturally, than to keep trying to make it not-JS.
SCORE! When writing the ES6 module specification algorithms, "self import" was one of the use cases I used to make sure that circular module imports and the module object binding mechanisms played well together. Self reference is the base-case of circularity.
TIL: A module can import itself to get access to all it's exports wrapped in a neat little object (thanks to the module cache)
Use case: migrating legacy code that put their exports onto a global object to ES modules.
From the short period (1992-1995) when Smalltalk make a serious run at being the “successor to COBOL” for the IT world.
The photo on the left is the cover of a product brochure featuring almost all of Digitalk’s staff. The complete brochure is at wirfs-brock.com/allen/files/…
Looking closer, I think the the brochure primarily shows the product development/engineering staff.
There were lots of other great people in other roles at Digitalk.