I wish that emacs / vi, GBD, and the Unix shell had anything close to the "n00b mode" provided by Squeak in terms of inline documentation, tool tips, menus etc.. But, yeah, Squeak has serious problems, and you're absolutely right that it's too hard to tinker with the core of it, just like every other computing system on the planet. When you hack your kernel, should you be free enough to do so, you *expect* to break everything... don't you? You'll notice we've been discussing things like Worlds, which might be one way to address this particular issue.
Pioneering isn't for everyone, but the conventional roads don't lead where I want to go. My daily software environment has been over-engineered to solve too many problems I don't have. I'd like to be able to shed some of the excess complexity of a conventional OS while retaining the media capabilities and increasing the overall expressive power. I don't mind giving up the comfort of familiar habits, and I don't give a whit about delivering a product to anyone. That's why I read this list. -- Max On Wed, Jun 22, 2011 at 8:21 PM, Julian Leviston <jul...@leviston.net>wrote: > > On 23/06/2011, at 12:35 PM, Max OrHai wrote: > > > People who want a "small" language should be prepared to be somewhat > idiosyncratic, if they want to express "big" or complex programs. I mean > 'language' here not just in terms of a programming language definition but > rather to mean all constructs (or, more fundamentally, concepts and > conventions) which are shared, which belong in some sense to a culture > rather than an individual. If they don't enlarge the language (usually via > some library) they enlarge their personal idiom instead, which may not be as > "portable". Progress depends on the ability of individuals to nonetheless > communicate these new ideas 'uphill' so to speak, but more immediately on > the ability to make them, so as to make them better. Some leverage here may > be available through improvements in the notion of expressivity itself. > There is a wonderfully large number of experiments being done in dynamic > language design these days, from Ruby to REBOL... If more of them would take > what I'd say is the major lesson of Smalltalk and become fully integrated > personal computing environments, rather than living off the previous > generation's operating systems, perhaps they might be able to move some of > the uncomfortable fixed points of usability and complexity, as well as gain > more user-programmers altogether. I think FONC is, at least, a pointer in > the right direction; a reminder that there's plenty of room out there beyond > the familiar. > > > > So, by that reasoning, GNU SmallTalk doesn't exhibit what you'd express as > being the "major lesson from SmallTalk"? > > Interestingly, one of the most irritating things for me was the User > Interface when I first came to Squeak, having programmed in GemStone > SmallTalk for a number of years (which we were programming via snippets > plugged into HTML, and sometimes via GemStone/J, on a mac natively, not > inside a SmallTalk environment at all). > > At that point I had experience in AmigaDOS, MacOS (pre X), Windows 95, NT > and GEOS (commodore 64 based GUI) would you believe... Squeak was supremely > irritating for two reasons: Firstly, the UI was completely different without > having any easy way to say "hey, I'm a n00b, turn on n00b mode so I can > learn this thing", and second it seemed far too easy to make irreparable > damage, or even lose what I was doing... (probably due to point 1). > > So I'd be very much against your "build the whole world so you can express > the language" philosophy. Potentially, though, I'd say having the idea of a > SmallTalk-like image loaded into a fully graphical interface AS AN OPTION is > awesome... I'd love to have a visual debugger for my Ruby code the likes of > the SmallTalk ones... (to a degree, MagLev kind of allows this as a > possibility). > > My issue seems to be that if you change the language at a base level while > in one of those environments, you kind of break everything... don't you? > They don't really lead to experimentation very well. > > Julian. > > > _______________________________________________ > fonc mailing list > fonc@vpri.org > http://vpri.org/mailman/listinfo/fonc >
_______________________________________________ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
