Dreaming the future of software; Project Editor ECMAScript 2015;
Reformed Smalltalker
JavaScript historian dl.acm.org/doi/abs/10.114…
@allenwb@mastodon.social
If you need to ship in the foreseeable future, never take a dependency upon a standards group or a big company.
Typical time horizons:
Most dev projects < 1 year
Big Co projects 1-3 years
Standards projects 3-∞
2/
I think node/cjs made exactly the right decisions for what they wanted to accomplish in 2009. They took a pragmatic approach that built upon then currently used approaches to JS modularity that didn’t require language changes or deep engine modifications.
1/
I was involved in these conversations back in 2009. I still think we made the right choice with sync require and callbacks, given what we had at the time, and the current situation is, if not the best outcome now imaginable, far from the worst, and maybe the best possible. …
The revolutionary IBM System/360 computers were announced 55 years ago today. These mainframes ruled the computing industry for years. Their iconic consoles, covered with lights and switches, showed internal state. I explain these consoles in my article:
righto.com/2019/04/iconic-co…
ALT The IBM System/360 Model 30 was in a large red cabinet. It had a complex front panel with lights and knobs.
ALT The IBM System/360 Model 91 filled a large room. Its complex control panel had over 1000 lights.
ALT The control panel for the IBM System/360 Model 50 had numerous lights, knobs and toggle switches, along with a voltmeter.
ALT The System 360/Model 85 filled a room. Tape drives, printers, disk drives, and card readers fill the background. In this IBM photo, the computer cabinets are red.
DTSS was the first system where I did any HLL programming (Oh Noz, I guess that means that BASIC was my first programming language).
I thought that DTSS was originally built for the 235 and latter the 265. Perhaps @Grady_Booch's 255 is really 265
en.wikipedia.org/wiki/GE-200…
We would had saved a lot of errors due to working just with numbers instead of measures. We implemented units in #Smalltalk and presented at OOSPLA in 2005, and there were many previous implementations. github.com/Cuis-Smalltalk/Me…
In 1998-2000 there were serious proposals to add numeric units to ECMAScript/JavaScript and they were part of early ES4 proposals. I wonder how modern languages would be different if units had made it into ES3 (1999).
And Java is only one of many attempts at such a platform. Seems to me that creating a successful Web Assembly universal platform will require both research into failings of previous attempts & an understanding of how modern requirements differ from past.
Good luck, webasm folks!
I'm excited by PWAs, especially for cross-platform app dev... don't get me wrong... but that's not a "non-web" target for webassembly.
But I'm struggling with how webassembly achieves the cross-platform *app* (incl web) holy grail that Java tried (and ultimately failed) to do?
In 1998-2000 there were serious proposals to add numeric units to ECMAScript/JavaScript and they were part of early ES4 proposals. I wonder how modern languages would be different if units had made it into ES3 (1999).
YES! It is both! That is one of the root causes of the problem. Blueprints are paper while buildings are wood and stone. But software blueprints are code, and code is code. Programmers are confused by that, but carpenters are not.
Got a CO2 meter for work, as I suspect the air gets very bad in some longer crowded meetings. Findings so far:
* Team room with 10 people: 450 ppm
* Meeting room with 5 people: 650 ppm after 15 minutes
* Same meeting room with 9 people: 875 ppm after 15 minutes (and climbing)
When we did the Self IDEs, we thought about how the human visual system works, short-term spatial memory, the illusion of causality, directness, and exploiting analogs to physical reality. I miss that focus.