Stef writes: > Do not dream guys. Sun just let David doing that but he is alone with > two students. Very true. And what's new there? Leaving aside the relative merits of Self per se, what are they doing that the Squeak team didn't do ten years ago? -C -- Craig Latta improvisational musical informaticist www.netjam.org Smalltalkers do: [:it | All with: Class, (And love: it)] |
In reply to this post by Alejandro F. Reimondo
Hi Ale-- > Some words we use and... *must* [revisit] are: > > - Smalltalk as a (dynamic) language. > > No comment now on the topic, because I have written on it in the past > and no answer has been received in this list (why?). You seem to be forgetting my responses. :) I think the main reason you haven't gotten much response is that, sadly, people tend not to speak up when they agree with you. (So I'll take this opportunity to say that, generally, I agree with you. :) > - Variables > > We use the term "instance variable" for the collaborators of an > object. The word "variable" has a well-known meaning in traditional > computing, and refers to a place in memory, the contents of which > "varies". We put "names" to objects in Smalltalk, but do not use > variables because we do not consider memory as addressable (via names > or numbers). I thought Self's use of the word "slot" was an improvement. Even the PARC-era use of "field" seems better than "variable". > ...ambience... You keep misusing that word. :) Seriously, please go look it up in an English dictionary. The word you want is "environment" (more familiar to most speakers), or perhaps "biosphere" (less familiar but refers explicitly to living organisms). An "ambience", in English, is the atmosphere or mood created by an environment. It is not the environment itself, it refers to the environment's psychological effect. greetings! -C -- Craig Latta improvisational musical informaticist www.netjam.org Smalltalkers do: [:it | All with: Class, (And love: it)] |
In reply to this post by ccrraaiigg
>From the paper it is actually quite new and interesting.
1) Where Squeak is statically translated from Slang to C to binary, The VM will use dynamic compilation at run-time to translate the VM and the user code in the same address space/image. This of course needs a bootstrap that can persist the dynamic compilation results for enough of the system to allow it to run on its own. 2) This will allow parts of the VM to be dynamically inlined into the code generated for user code. 3) As part of the work they are working with 2 images so that the tools run in one image while the system under development runs in another image. This allows a lighter execution environment without "stripping" the image. It is not clear if they intend this to be the long-term use or only during bootstrapping. The goal is to have the full language available for the VM to use while allowing global optimization on user and VM code. If they pull it off they should get significant performance value out of the effort. I did not realize it was such a small team however. That certainly reduces the odds of success, or lengthens the development time. On the other hand small teams in Smalltalk/Self can get a lot more done than large teams in C or Java. The paper suggests that they are targeting PPC OS/X machines, which are of course obsolete. It will be interesting to see if they choose to support x86 or remain on the existing hardware they have. One of the downsides of research work is that it does not always care about applicability of the artifacts, only the concepts generated from the work. Michael -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Craig Latta Sent: Thursday, May 11, 2006 12:50 PM To: [hidden email] Subject: re: Requiem or Resurgence? Stef writes: > Do not dream guys. Sun just let David doing that but he is alone with > two students. Very true. And what's new there? Leaving aside the relative merits of Self per se, what are they doing that the Squeak team didn't do ten years ago? -C -- Craig Latta improvisational musical informaticist www.netjam.org Smalltalkers do: [:it | All with: Class, (And love: it)] |
On 11-May-06, at 1:28 PM, Michael Latta wrote: > 3) As part of the work they are working with 2 images so that the > tools run > in one image while the system under development runs in another > image. This > allows a lighter execution environment without "stripping" the > image. It is > not clear if they intend this to be the long-term use or only during > bootstrapping. Oh, you mean Spoon. :-) tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Useful random insult:- Living proof that nature does not abhor a vacuum. |
In reply to this post by Klaus D. Witzel
> Another little chance for Smalltalk (again ...) could be a reborn of
> dynamically typed languages. I believe it will be the case and I like this excellent presentation/screencast of a NASA engineer (JPL) on this subject: http://discuss.joelonsoftware.com/default.asp?joel.3.314850.18 francois |
In reply to this post by timrowledge
If spoon allowed me to update the VM from the remote tools, set breakpoints
in the VM and use blocks to implement the VM, then yes. Spoon does allow migration of objects from one VM to another. I do not know if it has seamless debugging of the target image from the tools image. Michael -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of tim Rowledge Sent: Thursday, May 11, 2006 1:51 PM To: The general-purpose Squeak developers list Subject: Re: Requiem or Resurgence? On 11-May-06, at 1:28 PM, Michael Latta wrote: > 3) As part of the work they are working with 2 images so that the > tools run > in one image while the system under development runs in another > image. This > allows a lighter execution environment without "stripping" the > image. It is > not clear if they intend this to be the long-term use or only during > bootstrapping. Oh, you mean Spoon. :-) tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Useful random insult:- Living proof that nature does not abhor a vacuum. |
> If Spoon allowed me to update the VM from the remote tools, set > breakpoints in the VM and use blocks to implement the VM, then yes. Surely those are part of items #1 and #2 in your previous message, not #3, as Tim was referring to. And I expect they would be addressed by combining Spoon with Exupery (which *does* target x86). > Spoon does allow migration of objects from one VM to another. Right (although I think "from one object memory to another" would be a better way to phrase it). It also allows interaction between objects on different machines without moving them around, which is more common. > I do not know if it has seamless debugging of the target image from > the tools image. It certainly does. Any context can be the sender of any context on any other machine. So, for example, you can have context stacks that span multiple machines (as happens during remote debugging and remote exception handling). You could even do really strange things like continuations that span multiple machines (perhaps Seaside could use this?). Spoon is a distributed object memory. Ungar's team asked me out to lunch a couple of years ago to discuss my work with them, so it's no surprise to me that they were thinking of similar things. Who thought of what first I don't know, but I did conceive and implement these ideas independently. -C -- Craig Latta improvisational musical informaticist www.netjam.org Smalltalkers do: [:it | All with: Class, (And love: it)] |
In reply to this post by Michael Latta
On 5/10/06, Michael Latta <[hidden email]> wrote:
> While Squeak can do far more than Ruby or Python, they > get much more press. In part this is because Smalltalk is seen as old. The out-of-the-box UI is very old-fashioned; quaint, with the mousey eyes, and the little window with the balloon, and the quirky colors. Maybe a slick update -- for programmers, rather than kids -- would help dispell the "old" image. Maybe LCARS . . . :-) - Bob |
In reply to this post by ccrraaiigg
Cool. Spoon looks to be more than I thought it was.
-----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Craig Latta Sent: Thursday, May 11, 2006 2:50 PM To: [hidden email] Subject: re: Klein (was "Requiem or Resurgence?") > If Spoon allowed me to update the VM from the remote tools, set > breakpoints in the VM and use blocks to implement the VM, then yes. Surely those are part of items #1 and #2 in your previous message, not #3, as Tim was referring to. And I expect they would be addressed by combining Spoon with Exupery (which *does* target x86). > Spoon does allow migration of objects from one VM to another. Right (although I think "from one object memory to another" would be a better way to phrase it). It also allows interaction between objects on different machines without moving them around, which is more common. > I do not know if it has seamless debugging of the target image from > the tools image. It certainly does. Any context can be the sender of any context on any other machine. So, for example, you can have context stacks that span multiple machines (as happens during remote debugging and remote exception handling). You could even do really strange things like continuations that span multiple machines (perhaps Seaside could use this?). Spoon is a distributed object memory. Ungar's team asked me out to lunch a couple of years ago to discuss my work with them, so it's no surprise to me that they were thinking of similar things. Who thought of what first I don't know, but I did conceive and implement these ideas independently. -C -- Craig Latta improvisational musical informaticist www.netjam.org Smalltalkers do: [:it | All with: Class, (And love: it)] |
In reply to this post by Bob Erb
I really do not have an issue with the Squeak UI. It is different from the
platform UI but seems reasonably well implemented and such. The size of scroll bars and borders is a bit small for my taste and eyes these days. But, since this is Smalltalk I can always change them! Mostly I was referring to the perception of Smalltalk as a language/system that had its day and was on the decline. That is generally the response I get when mentioning it to those that have not actually used it on a project, or who have been converted to the mainstream of Java or .Net. The VisualWorks UI is a bit dated and still has the annoying 10 year old bug of not always repainting windows properly. That bug alone makes it look dated. Michael -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Bob Erb Sent: Thursday, May 11, 2006 3:03 PM To: The general-purpose Squeak developers list Subject: Re: Smalltalk: Requiem or Resurgence? {Dr. Dobb's Journal (05/06/06) Chan, Jeremy} On 5/10/06, Michael Latta <[hidden email]> wrote: > While Squeak can do far more than Ruby or Python, they > get much more press. In part this is because Smalltalk is seen as old. The out-of-the-box UI is very old-fashioned; quaint, with the mousey eyes, and the little window with the balloon, and the quirky colors. Maybe a slick update -- for programmers, rather than kids -- would help dispell the "old" image. Maybe LCARS . . . :-) - Bob |
I'm a total squeak novice still, even though I've poked at it
occasionally for a while. The big problem is, with respect to typical desktop applications, Squeak is a tiny isolated Universe. It's really it's own platform. So, it can't be compared to Python, Ruby etc. It's more comparable to AppleScript, except AppleScript is not nearly as restrictive, because your not locked into an AppleScript only platform. If you have an application in mind, do you want to make it be an application that is only usable by a tiny group of people using the Squeak platform? Or, do you want to make it available to the vast universe outside of Squeak? I like the language Smalltalk, but I have trouble justifying the time it takes to comprehend the undocumented and terminally obscure Squeak platform. The main justification I use is that I want to learn more about smalltalk and the alternative smalltalks are much less developed or are closed and corporate proprietary. Michael Latta wrote: > I really do not have an issue with the Squeak UI. It is different from the > platform UI but seems reasonably well implemented and such. The size of > scroll bars and borders is a bit small for my taste and eyes these days. > But, since this is Smalltalk I can always change them! > > Mostly I was referring to the perception of Smalltalk as a language/system > that had its day and was on the decline. That is generally the response I > get when mentioning it to those that have not actually used it on a project, > or who have been converted to the mainstream of Java or .Net. > > The VisualWorks UI is a bit dated and still has the annoying 10 year old bug > of not always repainting windows properly. That bug alone makes it look > dated. > > Michael > > > > -----Original Message----- > From: [hidden email] > [mailto:[hidden email]] On Behalf Of Bob Erb > Sent: Thursday, May 11, 2006 3:03 PM > To: The general-purpose Squeak developers list > Subject: Re: Smalltalk: Requiem or Resurgence? {Dr. Dobb's Journal > (05/06/06) Chan, Jeremy} > > On 5/10/06, Michael Latta <[hidden email]> wrote: > >> While Squeak can do far more than Ruby or Python, they >> get much more press. In part this is because Smalltalk is seen as old. > > The out-of-the-box UI is very old-fashioned; quaint, with the mousey > eyes, and the little window with the balloon, and the quirky colors. Maybe > a slick update -- for programmers, rather than kids -- would help dispell > the "old" image. Maybe LCARS . . . :-) > > - Bob > > > |
Kendall Shaw wrote:
> I'm a total squeak novice still, even though I've poked at it > occasionally for a while. > > The big problem is, with respect to typical desktop applications, > Squeak is a tiny isolated Universe. It's really it's own platform. So, > it can't be compared to Python, Ruby etc. It's more comparable to > AppleScript, except AppleScript is not nearly as restrictive, because > your not locked into an AppleScript only platform. Gee... I see it as just the opposite. Why do you think Squeak is restrictive? > > If you have an application in mind, do you want to make it be an > application that is only usable by a tiny group of people using the > Squeak platform? Or, do you want to make it available to the vast > universe outside of Squeak? Hmm... Squeak runs on multiple OSs and you can deploy a run-only version of your "app". So... I don't understand the statement. Can you elaborate? > > I like the language Smalltalk, but I have trouble justifying the time > it takes to comprehend the undocumented and terminally obscure Squeak > platform. The main justification I use is that I want to learn more > about smalltalk and the alternative smalltalks are much less developed > or are closed and corporate proprietary. |
In reply to this post by Michael Latta
I think that the VW UI looks quite good under Windows and Mac OS. It has also had many changes to the look and the tools as it has progressed from version to version. Look at 7.* compared to 5i.4 and 3.0.
Squeak on the other hand looks wierd on all platforms with no sign of change. I am dedicated Smalltalker and Squeak's UI is a huge barrier for entry for me. I can't imagine that any non-smalltalker would see it and like it. It's strengths are far greater than it's weaknesses but it takes a certain level of proficiency to finally realize that.
I think dolphin has the look that makes it easier for people to want to look deeper.
We shouldn't judge books by their cover, but everyone does. That's totally normal. Even if it has a 350 under the hood, who wants to drive a rusted out chevy nova? Or who wants a ferrari painted with a bunch of wierd random pastels?
Getting a little sex appeal, together with the amazingly cool Smalltalk features would make a huge difference in drawing new users. Look at Apple for example. Why buy an ipod or a mac when they cost more for the same functions. Because you like using them. It is a pleasure to see the great design.
We always say how if you don't like how squeak looks you can change it. But why not make it handsome from the get go and let the guys who want it ugly change it?
Mike
On 5/11/06, Michael Latta <[hidden email]> wrote:
I really do not have an issue with the Squeak UI. It is different from the -- Mike Hales Engineering Manager KnowledgeScape www.kscape.com |
My comment on Visual Works was referring to
7.4. The UI looks like Windows 2000 gunmetal gray. I have not
looked at it under OS/X yet. I agree that the Squeak UI takes some
getting used to. In particular the set of targets on the window are not
obviously available. But, then all the Smalltalk UIs rely on mouse
buttons to trigger menus or other UI to issue commands. It does look like
Dolphin can look the slickest, but I have explored it the least. As a developer I do not like the VW or
Dolphin browsers nearly as well as the traditional system browser. Tree
controls are nasty things that require a very accurate mouse click to access,
and produce very long lists of items. Then again in Eclipse I basically
never use a browser but always do the equivalent of “find class” to
locate classes. The use of namespaces in VW seems a bit kludgy, and has
only limited value over a set of prefix letters. Using namespaces in Java
where the same class name is shared is a royal pain. It is far better to
have unique names. Michael From:
[hidden email]
[mailto:[hidden email]] On Behalf Of Mike Hales I think that the VW UI looks quite good under Windows and Mac OS.
It has also had many changes to the look and the tools as it has progressed
from version to version. Look at 7.* compared to 5i.4 and 3.0. Squeak on the other hand looks wierd on all platforms with no sign of
change. I am dedicated Smalltalker and Squeak's UI is a huge barrier for
entry for me. I can't imagine that any non-smalltalker would see it and
like it. It's strengths are far greater than it's weaknesses but it takes
a certain level of proficiency to finally realize that. I think dolphin has the look that makes it easier for people to want to
look deeper. We shouldn't judge books by their cover, but everyone does.
That's totally normal. Even if it has a 350 under the hood, who wants to
drive a rusted out chevy nova? Or who wants a ferrari painted with a
bunch of wierd random pastels? Getting a little sex appeal, together with the amazingly cool Smalltalk
features would make a huge difference in drawing new users. Look at Apple
for example. Why buy an ipod or a mac when they cost more for the same
functions. Because you like using them. It is a pleasure to see the
great design. We always say how if you don't like how squeak looks you can change
it. But why not make it handsome from the get go and let the guys who
want it ugly change it? Mike On 5/11/06, Michael
Latta <[hidden email]>
wrote: I really do not have an
issue with the Squeak UI. It is different from the
|
In reply to this post by Bob Erb
Bob Erb: "The out-of-the-box UI is very old-fashioned" Bingo. In addition to the above (which affects Squeak more than it does most other Smalltalk dialects,) Smalltalk's main problems have been: 1. Lack of a sponsor with sufficient marketing muscle and/or commitment. 2. Competitors who falsely claim to be essentially equivalent--but who do have a sponsor with sufficient marketing muscle/commitment. These competitors also cause problems because they redefine the language Smalltalk uses to describe itself, so that it is harder for observers to clearly discern how Smalltalk is different. 3. The perception that Smalltalk is "old," "slow," "a failure" and "weird." 4. The name of the language. 5. The balkanization of the language into numerous dialects. United we stand, divided we fall. 6. The refusal/failure of many Smalltalk dialects to address fundamental issues such as modules and namespaces. Note that I did not list Smalltalk's syntax. That issue is a red herring. Were that not so, all successful languages would have the same syntax as either COBOL, FORTRAN or BASIC. --Alan |
In reply to this post by Brad Fuller
Brad Fuller wrote:
> Kendall Shaw wrote: >> I'm a total squeak novice still, even though I've poked at it >> occasionally for a while. >> >> The big problem is, with respect to typical desktop applications, >> Squeak is a tiny isolated Universe. It's really it's own platform. So, >> it can't be compared to Python, Ruby etc. It's more comparable to >> AppleScript, except AppleScript is not nearly as restrictive, because >> your not locked into an AppleScript only platform. > Gee... I see it as just the opposite. Why do you think Squeak is > restrictive? I'm really just talking about squeak for desktop applications. For games or web applications etc., it's not as much of an issue. The fact that squeak has it's own desktop, effectively makes it it's own platform for the purposes of desktop applications. If your program doesn't look exactly like every other program and use exactly the same procedure they've had to use for every program, then game over, you might as well not have even bothered to write the program. In squeak, the controls don't look or behave like the other controls a user will use on their computer, so game over, you might as well not have even bothered to write the program. It doesn't matter what I think about it. It's what the user is likely to think about it. Most importantly though, I can't open emacs on squeak's desktop. Also, I can't easily check a squeak application into a version control system, separate from other squeak applications, but together with other source files in other languages, and other files. I can't run find on a combination of squeak classes and other files. I can't easily include it in a test procedure involving multiple languages. I don't think you could easily distribute it as an rpm or a debian package etc. and deal with dependencies between squeak applications. I can't use installshield to integrate it into someone's squeak applications. >> If you have an application in mind, do you want to make it be an >> application that is only usable by a tiny group of people using the >> Squeak platform? Or, do you want to make it available to the vast >> universe outside of Squeak? > Hmm... Squeak runs on multiple OSs and you can deploy a run-only version > of your "app". > So... I don't understand the statement. Can you elaborate? For all practical purposes, a desktop application written in squeak will only be used by squeak programmers. Note the term: "desktop application". |
In reply to this post by Klaus D. Witzel
Actually, it seems that these people get ahead by commanding more people. It makes them more "important". Much better from their perspective to have an army of 100 J--heads rather than 10 'talkers. Its a prestige thing. Then they justify it by "market availability of talent". On May 11, 2006, at 10:11 AM, Klaus D. Witzel wrote:
|
In reply to this post by Bob Erb
I agree - it would be cool if the community could pony up for a really good visual designer to design a slick "look" for the environment. We have a lot of graphics power and I think we're not making the best use of it from a 'be sexy' perspective. (And don't look at me - I'm an engineer - thus completely disqualified in the UI department). I would put up $100 for it though. On May 11, 2006, at 3:02 PM, Bob Erb wrote:
|
In reply to this post by Michael Latta
Sure, but look at MS's KPL (Kids Programming Language). The screenshots I've seen make it clear that the language is C#-lite (with all the attendant ugly C++-esque syntax). OTOH, they've got a lot of professionally developed graphical elements and it "looks" hot. I'm sure it sucks but it is initially attractive. On May 11, 2006, at 3:30 PM, Michael Latta wrote:
|
In reply to this post by tblanchard
On 11-May-06, at 7:18 PM, Todd Blanchard wrote: > I agree - it would be cool if the community could pony up for a > really good visual designer to design a slick "look" for the > environment. While the visual stuff is certainly important to initial perception we mustn't forget the feel half of look&feel. That is something that *does* need engineer type effort. My current pet peeve on 'feel' is the abysmal feedback provided (or rather not provided) by buttons and lists. When you click a button or a list item something visible should happen *immediately* to show that the press/click has been picked up. This is an attribute of the widget, not the application using it by the way. The application handling the press/click should also provide some visual feedback if there is any delay whatsoever in responding; it takes time to query sockets, open files, read data, whatever and if you're left hanging while that goes on you can end up stuffing the event queue with spurious events. My favourite example is using a remote MC repository. Click on a package. Wait (reasonably - it's going to Germany from Canada and those little nano-pigeons can only swim down the wire so fast). No feedback. Hmm, did my click actually select the package or merely move the focus to the MC browser window? Or even just move focus to the Squeak window from some other app? How long do I wait before clicking again - and finding that I've just deselected the package that is just being displayed! Arrgh! We have a pretty decent progress bar facility that needs to be used a lot more. It would also be useful to extend it so that it would have a small delay before appearing - say 1/3rd sec - so that operations that complete 'nearly instantly' don't clutter ones perception needlessly. RISC OS started doing something like this in around '88 and it can be very simple to use and helpful to users. For operations of indeterminable length a progress bar that regularly updates in some 'fuzzy' fashion would be nice. It would at least let the user know that something is going on and the system hasn't locked up! The old Perq workstation window system used to do some thing vaguely like those random-block page transitions so beloved of powerpoint abusers. One could even use the same feedback provide by the project loader with the bar moving back and forth like a Cylon eye. So my suggested plan would be to a) improve the button list immediate feedback b) improve and extend the progress bar c) make use of the progress bar in (many) more places Then it might be worth spending time or money to improve the visuals. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim World Ends at Ten! Pictures at 11 on Fox News! |
Free forum by Nabble | Edit this page |