> Fun challenge: try making a smalltalk app that isn't easily recognizable as a smalltalk app.
It is true that both Lisp and Smalltalk make it very easy for people to build things that would normally take a team and an architecture. This has the down side that if it's easy to build something that acts sort of like a button, that's what ships rather than bridging to some OS button. It's a lot of work to implement for no obvious benefit, especially to the Smalltalk programmer who is using the system because they like it and don't mind the differences. This seems like exactly the sort of thing that would make for-pay Smalltalk systems viable, but nobody seems to be willing to pay for a language now. Even if it would be cheaper in the long run, it's harder to do the math and it's hard to compete with free.
> I hope too there can be a "Clojure for smalltalk", if you will.
I think this is a concept that should be explored in more depth. Some things I'd toss out as worth discussing:
- Having a standard library or syntax for defining classes (GNU Smalltalk addresses this)
- Real namespacing, because I'm sick of seeing XXYYZZClassName
- Sexy, dirt-simple FFI to C or Java. Probably, as you point out, through a standard calling convention for external stuff (maybe borrow the Block API, something f value: a value: b value: c).
I think apart from these things you could really build the Smalltalk of tomorrow in the Smalltalk of today. You need really good OS integration, especially graphically but every other way as well. You probably need to be able to serialize the system to ordinary flat text files so you can use modern VC.
I know Juan Vuletich has been rebuilding the standard image his way from the ground up with Cuis but as far as I can tell progress is stalled. Other than that I don't know of any big project besides Pharo, which is even more modest, really just about removing crap from Squeak and producing a professional shame-free open source Smalltalk.
It is true that both Lisp and Smalltalk make it very easy for people to build things that would normally take a team and an architecture. This has the down side that if it's easy to build something that acts sort of like a button, that's what ships rather than bridging to some OS button. It's a lot of work to implement for no obvious benefit, especially to the Smalltalk programmer who is using the system because they like it and don't mind the differences. This seems like exactly the sort of thing that would make for-pay Smalltalk systems viable, but nobody seems to be willing to pay for a language now. Even if it would be cheaper in the long run, it's harder to do the math and it's hard to compete with free.
> I hope too there can be a "Clojure for smalltalk", if you will.
I think this is a concept that should be explored in more depth. Some things I'd toss out as worth discussing:
- Having a standard library or syntax for defining classes (GNU Smalltalk addresses this)
- Real namespacing, because I'm sick of seeing XXYYZZClassName
- Sexy, dirt-simple FFI to C or Java. Probably, as you point out, through a standard calling convention for external stuff (maybe borrow the Block API, something f value: a value: b value: c).
I think apart from these things you could really build the Smalltalk of tomorrow in the Smalltalk of today. You need really good OS integration, especially graphically but every other way as well. You probably need to be able to serialize the system to ordinary flat text files so you can use modern VC.
I know Juan Vuletich has been rebuilding the standard image his way from the ground up with Cuis but as far as I can tell progress is stalled. Other than that I don't know of any big project besides Pharo, which is even more modest, really just about removing crap from Squeak and producing a professional shame-free open source Smalltalk.