Amber Smalltalk
amber-lang.net
amber-lang.net
What if the entire system is visible and editable live within a single IDE? - the "entire system" including everything that's running within clients of your service and everything that's running on all your scaled out servers .. and everything that's running in your "IDE".
Without having to make it smalltalk, can we borrow this idea today and implement it in JS?
In the short term, I can imagine a system which exposes a REPL from each backend instance and a websocket-driven REPL from each browser client, and ties them together in a unified interface that allows enumeration and provides convenient syntax for evaluation against multiple targets. Such a system might offer some interesting possibilities around realtime client and server hot-patching and problem investigation, if it could be made bulletproof enough not to also serve as a gigantic SPoF or security vulnerability. But I don't know if it's really similar to what you're thinking of.
I may be underestimating the complexity of this, but it does seem doable with some clarifications to concepts. For example, in the smalltalk world, every GUI object created is expected to be inspectable and modifiable. If we then require that we want to call a button instantiated in every browser an independent object, that would be a misfit. It might be adequate to treat that button presented in the IDE context as the object that manifests on all connected browsers. So when I look for messages sent by the button, I tap into the logstream for those events that the system received from all browsers connected. But when I manipulate its appearance, it reflects on all connected browsers. I don't literally need to tap into each connected browser client.
This really shows its age. NPM is now the preferred choice for both front and backend JS development. I really haven't seen any FE tooling lately that use Bower.
What has ES5 to do with this? It didn't come out of nowhere - it was being planned for those many years.
I've been developing JS for years and I've been using NPM for frontend components for... 3 years minimum? Wow, such a quick pace, unbearable.
How is it bad that new tools and libraries are being developed? Nobody forces you to use the new shiny toys until they're established (and almost nobody does, unless you can afford the uncertainty). You call it churn, I call it advancing the trade and getting better tools made for free by passionate people. Some of those get established as de facto standards. Most don't. The churn rate is not high unless you count experimental technology.
> That something using Bower can be considered old really seems quite astonishing to me.
Bower was one of those shiny toys. It's not old: it's just that people used Bower on its infancy and it never got as much traction as NPM did. If someone bets on Bower and then blames churn rate when it gets less traction than competitors... maybe they should stop using the new shiny toys and wait until an established tool emerges?
> FUD is generally a strategy to influence perception by disseminating negative and dubious or false information and a manifestation of the appeal to fear.
In this case I suspect it's self-inflicted FUD and not intentionally trying to misinform other people, but FUD nonetheless.
That would needlessly tie front and back-end, imposing restrictions on both sides for a minimum common denominator.
Seaside explicitly chose a "heterodox" approach in being session based and producing URLs that are clearly not RESTful. That being said, the Seaside book covers the Seaside REST package which handles building RESTful APIs.
Amber is interesting because of how it evolves and what it can do, like having real compiler producing JS as output.
One can learn quite a bit by studying it.
Tools have to be better and there are some limitations but still, an interesting experience.
Enterprise was adopting Smalltalk when Java came out.
Even Eclipse was actually Visual Age for Smalltalk refurbished.
Can you imagine if the standard language of enterprise development today were Smalltalk? Can you imagine if the standard language of the Web were Lisp (or Scheme)? Can you imagine if we'd sunk all the work into making Lisp & Smalltalk great that we instead sunk into making Java & JavaScript not so terrible that they cause spontaneous seppuku?
Which is why after my initial enchantment with UNIX, I grew tired of using a graphical workstation to manage xterms.
Terminals are effectively guaranteed to be there when all else fails: whether that be due to a misconfigured computer, or to a slow connection that means that you're using SSH only, or because you're stuck using a rubbish chromebook linked to your Real Computer back home via SSH (which happens to me a lot).
So while I admire things like acme and smalltalk, my personal philosophy, partly for flexability, and partly out of necessity, is that if you can't run within a terminal window, I can't depend on you, or integrate you too heavily into my workflow. Because when I need you most, you'll let me down.
This is the second reason I hate most IDEs, by the way. The first reason is that most IDEs believe that if your language is verbose, the solution is more automated code generation. I believe that if most of your code is being generated automatically, you need a new programming language.
Naturally, the Smalltalk IDE gets a pass, because it's not an IDE in the common sense. It's more like a real-time introspective debugging environment which you happen to write all your code in. It's not even technically required for the language, as GST aptly demonstrates.
But the first time you use the smalltalk debugger, you'll be sold on it. You'll want it thr smalltalk IDE in every language. Sadly, this isn't possible, unless you're a lisp programmer with either A) a lot of money or B) a lot of spare time on your hands, you can't have it.
*Edit Netscape, not Sun
That would've meant that TDD would've had to have been de rigeur. So likely, this would've been an alternative universe where Extreme Programming got created earlier to overcome some of the weaknesses of Smalltalk as an enterprise language. It would also have helped if some of the internecine fighting between Smalltalk companies (and parts of merged Smalltalk companies) didn't happen. Also, this would have required an ANSI standard for Smalltalk that wasn't manipulated by big companies into something toothless and hazy. This would've helped to create a more cohesive greater language community outside of individual implementations. Because of the toothless standard, combined with the ease of rolling your own, the Smalltalk community balkanized itself into different incompatible dialects.
Can you imagine if the standard language of the Web were Lisp (or Scheme)?
There would have been, possibly, a true "write once run everywhere" environment. Squeak demonstrates the feasibility of this. The thing runs with a bit identical virtual machine model on something like a hundred different platforms. However, there would have been a serious rash of network security problems. Because it's hard to prove things in Smalltalk, the preferred model for web app security was signed code, which is far from a panacea. There were some people thinking about sandbox schemes, including myself, but Smalltalk VMs are also generally prone to the same kinds of security holes as other VMs, like Dalvik.
Can you imagine if we'd sunk all the work into making Lisp & Smalltalk great that we instead sunk into making Java & JavaScript not so terrible that they cause spontaneous seppuku?
Actually, Sun approached ParcPlace -- or whichever was the "original" Smalltalk company at the time -- and asked to use their VM for their set top box project. The Smalltalkers rebuffed them, so they went on to create their own VM. This Java was born. Smalltalk was almost Java, and missed its chance many times over, mainly because of culture. Smalltalk could've been LightTable decades earlier, if we'd only had faster hardware, the internet with something like YouTube, and a better community attitude towards outreach.
OTOH, Java makes me want to stab myself repeatedly. It's literally less pleasant than assembler. It's object-oriented COBOL with a pretty face.
Files work. Images work. Trying to emulate one inside the other really doesn't.