8 ms·
Learning Squeak (2019)
- tyingq 5y agoI really liked DabbleDB[1], written in Squeak with the Seaside framework. Twitter bought them in 2010, and shut it down. [1] https://en.wikipedia.org/wiki/Dabble_DB https://en.wikipedia.org/wiki/Dabble_DB
- cwp 5y agoAlas. Hard to believe it was all ten years ago now.
- cultofmetatron 5y agodabble db went tragically obscure. they were arguably the first to have a server driven ui with state tracking done in the server. It was a brilliant solution to complex state at a time when spas were just crawling out of the ocean. The biggest challenge was scaling the management of all those individual user's states. Meteor and elixir liveview both are doing this now to varying degrees of success.
- sn41 5y agoSqueak gave me the greatest pleasure I had while programming. I was not a fan of IDEs till then, preferring vi at that point, with ctags. Sadly it is one of the places where computer science has gone backward, preferring more clunky systems and less elegant paradigms. Except when it comes to the higher reaches of the meta object hierarchy, Smalltalk itself is a great pleasure - Squeak was the icing on the cake for me.
- willtim 5y ago> one of the places where computer science has gone backward, preferring more clunky systems and less elegant paradigms I respectfully disagree. Smalltalk has had its time. OOP has had plenty of investment and exploration, but it's fundamentally non-compositional and is a poor fit for modern hardware. Other paradigms, for example statically typed functional languages, are just as expressive (the expressive parts of Smalltalk were functional features anyway) and have much more to offer in terms of building reliable software that does not crash and is secure. Programming is hard, there is no silver bullet, but computer science is moving forward.
- abecedarius 5y agoAs long as we're trading opinions: the OO vogue of 1990-2010ish and the anti-OO reaction since then were both too much a matter of fashion. OO and FP are both powerful ideas, neither dominates the other, sometimes you can combine them, and you don't have to declare allegiance to either.
- willtim 5y agoThe attraction of "functional programming" to academics and many others, is that the paradigm is underpinned by established and well studied mathematical logics. For example, the lambda calculus or more recently linear logic. You can view this as "fashion" if you like, but by making programming more formalized and less adhoc, it's probably better recognised as progress.
- pyuser583 5y agoThose advantages aren’t merely theoretical … implicitly gained knowledge is extremely powerful in FP.
- bmitc 5y agoI’m not sure that stronger type systems always means an improvement to writing programs. They simply move the needle on the scale of where the difficulty lies in writing programs. Untyped languages make it very easy to write programs while the stronger the type system, the harder it gets to write the program in the first place. I think balance is in order and this is one reason why we haven’t seen fancy type systems become mainstream except for niche domains. If I’m writing a program in F#, I have a balance between a type system constraining me but a language that allows me, the programmer, to do what I want to do for the most part. The stronger and fancier type systems means I now have to somehow teach the type system things that I already now how to do and are safe. Fancy type systems simply try to say that you should write down a specification of your program. But in the real world, this is an enormously difficult if not impossible task. It makes the programming process and program rigid and brittle and not robust, which is not necessarily properties of software you want. There’s a reason why certain language ecosystems like Erlang/Elixir say errors, unexpected input, and more pathological events will happen (i.e., they can’t be reasoned out of the system) and so you need a way to explicitly deal with them. This is also a big theme in the recent book Software Design for Flexibility in terms of expanding programs, getting them to handle things they couldn’t before. While fancy type systems are neat, like those in Idris, I think the most useful idea is to have mixed type systems and programming paradigms in a program, which seems to be relatively unexplored right now.
- jtchang 5y agoI had a whole semester worth of Squeak at Georgia Tech. Can't really remember much at this point except that everything was an object and the environment we worked in was super slow.
- rbanffy 5y agoSmalltalk has always been decades ahead of its time and it being slow on, say, the Alto or the Star, was kind of expected. That said, Squeak is very nimble compared to pretty much anything else currently in use. I’ll assume your memory is from the late 90’s and the computers were not particularly fast.
- jecel 5y agoSqueak's virtual machine was an interpreted one until the company Qwaq hired Eliot Miranda in 2008 or so to develop a JIT compiler virtual machine. His "Cog" VM is what is used for Squeak, Pharo, Cuis and NewSpeak on x86, x86-64 and various versions of ARM. This, combined with faster hardware, makes for a much nicer experience than in 2002, for example. Of course, some of the extra performance is lost when new layers of code get added, specially in the graphical user interface.
- rbanffy 5y agoIm not sure performance was ever the problem for Smalltalk after GUIs became mainstream. At first, it was license cost and, after free (as both speech and beer) versions became available, the main issue was the alien feel at a time apps were following desktop UI guidelines closely and the “doesn’t play well with others” feature. The UI conformity requirement has loosened up a lot with the web and web apps, but I guess that the time is still not right. It is objectively slow, but not slower than full featured IDEs like Visual Studio or IntelliJ, which offer a much more constrained environment and toolset. Python is also “slow” and we still use it. BTW, it’s nice to talk yo you again, Jecel.