[squeak-dev] what is holding back Smalltalk?
Locked
12345
12345
[squeak-dev] Re: what is holding back Smalltalk?
 
|
>> I presume by "these sorts of responses" you mean Paolo's response to >> me. My response is driven by my responsibility as being an elected member >> of the leadership team, to ensure that Squeak 4.0 will have a completely >> clean license. We worked very hard over the last few years to track down >> every contribution to squeak since its beginning, obtaining legal documents >> updating the license, and it would be a shame if a mistakenly derived work >> from GNU Smalltalk were to taint the distribution once again. Note that if (*if*) this were to happen, I would consider relicensing the wrong pieces on a case-by-case basis to MIT. Another point (and a follow up on the "return class variable Blue") is that the very fact of having created a class variable Blue whose value is (Color red: 0 green: 0 blue: 1) might be construed as owning copyright on part of the image. You are so proud of living in a world of objects, and then restrict yourselves to old fashioned source code when it is better to do so... So face it, Squeak's image will never be clean. Paolo |
Re: [squeak-dev] Re: what is holding back Smalltalk?
|
|
In reply to this post by Paul D. Fernhout
Dear Paul,
> In the syntax case, I am continuing to point out that Smalltalk's keyword > syntax (e.g. "Point x: 10 y: 20" versus "Point(10, 20)" ) produces code > where all arguments are labeled and so it is easier to read and > understand. In Smalltalk we write 10 @ 20 written that way, aPoint emerges from the dialogue (a message WAS sent) between two universal objects (named 10 and 20). The result, aPoint occurs as a concecuence of an action, and it can help (a person) to try what he/she can do with the resulting object whithout previous reading. With Point(10,20), you need to know about Point theory, you force understanding before acting (why?). Transform an action on universal objects in a responsibility of a global object (named Point... that can be, e.g. aClass). Smalltalk is a support for education, it do not impose apriory-understanding; no instruction is requiered. And most of the times, people "enter" and actOn: Smalltalk before be instructed, and most times before reading any book on it. Smalltalk is interesting for children, not because it preserves innocence. It is interesting because it preserves freedom, that is related with uncertanty (of evaluating before understanding) and not with security and instruction (e.g. war ... Point() ). It is not important how much versions of free software exists, it is important how much free people exists. When we born, be are inmenselly rich. We can be anything. >From there we can only become more of what we are, loosing possibility to be an instance of another class (Point preceding the numbers that are also constrained by brakets). Smalltalk show (at each "doit") that you can doIt whithout apriory understanding. The important point is to learn how to doIt without breaking the system, e.g. with compromise in stability of a system (and using more the senses than the mind). And it also help to understand that you can change all the parts of a system, and if you doit without breaking it, the identity of the system is preserved (as has been occurring w/smalltalk in the last +35years, and in our bodies that change all the cells doing our life). It is not related with syntax nor structure, nor intention. It is related with identity and freedom. have fun with smalltalk and success with preserving innocence of people that love brackets, ... and simplicity Ale. |
Re: [squeak-dev] what is holding back Smalltalk?
|
|
In reply to this post by Bert Freudenberg
Bert Freudenberg wrote:
> Smalltalk is powerful precisely because it is different than today's > popular programming environments. The idea of a "live system" is too > strange for the masses. > > The thing with the popular languages is that they all are used in pretty > much the same way - write source code in a file in an editor or IDE of > your choice, build your program, run it, debug it, ship it. This makes > it relatively easy to switch to a new language, it's basically just a > different syntax and a change in the makefiles. You can easily replace > parts of your project with pieces in another language. The SCM can work > the same. You can continue to use the editor you know in your sleep. > Smalltalks like GNU Smalltalk, one possibility is to build up an IDE similar to Squeak around a text-based Smalltalk: Using the existing sources, a "live system" containing the IDE classes and objects is built around them. Changed sources are propagated to the file system and vice versa. Such a hybrid system (which perhaps has already been done - I don't know) would combine advantages from both worlds. A python scripter can still use text editors, a Smalltalk world user can still image based development (for instance, GNU ST also has image saving), while both work on the same system. This also (almost) solves the deployment issues in Squeak, like having to hide all IDE facilities from my end-users. IMHO, if - and only *if* - the Smalltalk open source community wants to reach a wider range of possibile users, it has to open itself and take some step towards existing solutions, whether they might be inferior or not. This does not necessarily mean, to give up Smalltalk's special characteristics. For now, I see no reason why a Pythonist or Rubyist should completely throw away almost everything he has learnt about file-based software development in order to use an admittedly more expressive and powerful, but incomplete (where is my USB support? :( ) and unmodular system? Why does everything have to be replaced, like SCM, UI, editors...? Squeak does not have the manpower to provide bug-free tool-support for everything, which is BTW called "reinvention". I believe, things like "image as a file-system", SqueakSVN, SqueakGTK and similar projects are the right direction but still not enough... Best regards, Martin |
Re: [squeak-dev] what is holding back Smalltalk?
|
|
Some guys at IBM are working on exactly this. File-based Smalltalk
under Eclipse. Based on IBM Smalltalk, replacing Envy with CVS. Originally called project Black Knight and Wrath, I think it is now known by the more pedestrian Smalltalk Development Tools (stdt): http://www.ibm.com/developerworks/blogs/page/stdt It sounds to me like it is a hybrid system. There is an in-memory image but all of the tools work on the parallel source. The image isn't loaded on startup, though. IBM uses it internally (sounded like one of the reasons was in producing the J9 Java VM, which makes sense historically). Someone from the team presented at a conference. It and a separate interview are both available from the Industry Misinterpretations podcast. I believe there is an effort to open-source stdt, but I'm sure we can appreciate the complications of a task like that! If Eclipse had support, I could see NetBeans might someday have support for Smalltalk. Tor Norbe made a joke about it on the Java Posse podcast after discussing Squeak on the JVM. There certainly are a lot of ex- and closet Smalltalkers at Sun. If Seaside gets enough buzz with the web developer community... On Sat, Nov 22, 2008 at 5:40 AM, Martin Beck <[hidden email]> wrote: > Bert Freudenberg wrote: >> >> Smalltalk is powerful precisely because it is different than today's >> popular programming environments. The idea of a "live system" is too strange >> for the masses. >> >> The thing with the popular languages is that they all are used in pretty >> much the same way - write source code in a file in an editor or IDE of your >> choice, build your program, run it, debug it, ship it. This makes it >> relatively easy to switch to a new language, it's basically just a different >> syntax and a change in the makefiles. You can easily replace parts of your >> project with pieces in another language. The SCM can work the same. You can >> continue to use the editor you know in your sleep. >> > While this still leaves the question, what is holding back "scripty" > Smalltalks like GNU Smalltalk, one possibility is to build up an IDE similar > to Squeak around a text-based Smalltalk: Using the existing sources, a "live > system" containing the IDE classes and objects is built around them. Changed > sources are propagated to the file system and vice versa. > > Such a hybrid system (which perhaps has already been done - I don't know) > would combine advantages from both worlds. A python scripter can still use > text editors, a Smalltalk world user can still image based development (for > instance, GNU ST also has image saving), while both work on the same system. > This also (almost) solves the deployment issues in Squeak, like having to > hide all IDE facilities from my end-users. > > IMHO, if - and only *if* - the Smalltalk open source community wants to > reach a wider range of possibile users, it has to open itself and take some > step towards existing solutions, whether they might be inferior or not. This > does not necessarily mean, to give up Smalltalk's special characteristics. > For now, I see no reason why a Pythonist or Rubyist should completely throw > away almost everything he has learnt about file-based software development > in order to use an admittedly more expressive and powerful, but incomplete > (where is my USB support? :( ) and unmodular system? Why does everything > have to be replaced, like SCM, UI, editors...? Squeak does not have the > manpower to provide bug-free tool-support for everything, which is BTW > called "reinvention". I believe, things like "image as a file-system", > SqueakSVN, SqueakGTK and similar projects are the right direction but still > not enough... > > Best regards, > Martin > > |
Re: [squeak-dev] Re: what is holding back Smalltalk?
|
|
In reply to this post by Antony Blakey-3
2008/11/22 Antony Blakey <[hidden email]>:
> > On 22/11/2008, at 6:14 PM, Igor Stasenko wrote: > >> 2008/11/22 Antony Blakey <[hidden email]>: >>> >>> On 22/11/2008, at 2:41 PM, Igor Stasenko wrote: >>> >>>> As someone said: nobody pays a license fee to the architect who >>>> designed the building each time someone entering it. >>> >>> In fact, you pay an architect for a design each time you build it. You >>> can't >>> reuse an architect's design without paying for it, or negotiating a >>> license. >>> The fact that you live in a house designed by an architect gives you no >>> rights to the design. >>> >> >> Right, you pay for design, but nobody pays the fee for entering his >> authentic house (read - get a copy). > > No, not 'get a copy'. The appropriate equivalent is 'use the software'. > > And in any case, there are buildings for which you are charged entry, and > sometimes purely on the basis of the architect. Falling Water might be like > that (although I think I read that it's no longer open due to structural > issues). > > Anyway, this argument is off-topic for this list, so I'll leave it to you to > have the last word ... :) > Neither do i want to continue with this. I just don't like the perception that reading anybody's open-source code and then implementing same things might taint the squeak. > Antony Blakey > -------------------------- > CTO, Linkuistics Pty Ltd > Ph: 0438 840 787 > > 75% of statistics are made up on the spot. > > > > -- Best regards, Igor Stasenko AKA sig. |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |