Squeak Foundation Board 2007 Candidates
Locked
1234567
1234567
Re: election details *PLEASE READ*
 
|
I'm well aware (and a big fan of) Philippe's work.
In fact, I built this with it: http://objectiveclips.com Last I checked - ProjectX was using it for its constraints mechanism. -Todd Blanchard On Feb 21, 2007, at 2:03 PM, Roel Wuyts wrote: > Not that all of these languages are object-oriented programming > languages. Several features found in functional, logic or > constraint languages might be interested to integrate. Note the > (really excellent) paper of Philippe Mougin and Stephane Ducasse, > that integrated APL-like constructs with Smalltalk collections. > > OOPAL: Integrating Array Programming in Object-Oriented > Programming , Philippe Mougin, Stéphane Ducasse. OOPSLA 2003 (18th > Annual ACM SIGPLAN Conference on Object-Oriented Programming, > Systems, Languages, and Applications). Technical Paper, October > 2003, Anaheim, USA. > > On 21 Feb 2007, at 21 February/09:55, Todd Blanchard wrote: > >> >> On Feb 21, 2007, at 12:40 AM, Andreas Raab wrote: >>> I must admit I'm not particularly impressed with that overall >>> assessment. >> >> Then don't vote for me. Sheesh. >> >> Given that AFAICS you've spent the better part of your career >> hacking Smalltalk rather than working in the mudpits, I'm not >> giving your view from a distance a lot of weight. >> >> I have years of full time development in these languages - C++ >> expert, Java expert, Objective C expert. Smalltalk - I'm just >> pretty good. >> >> Namespaces I've seen the effect of in C++, Java and VW. I think >> they are a bigger PITA than they are worth. Honestly, I prefer >> sticking two letter prefixes in front of stuff. >> >> Modules are so overloaded you'll have to define what you mean. >> >> Interfaces - not a fan of the hardwired interface ala Java. I do >> like informal protocols as implemented in ObjectiveC. >> Specifically, I like that I can define a protocol, and then ask an >> object if it conforms to the protocol without having to go back >> and say "this object will implement this protocol". Not that >> explicit protocols isn't occasionally useful, but I think the >> current subclassResponsibility mechanism gets the same point across. >> > > |
RE: election details *PLEASE READ*
|
|
In reply to this post by Ken Causey-3
<Ken Causey>...this subject was an important one early in the history of the
OED and even earlier English dictonaries (to be descriptive and not prescriptive)</Ken Causey> Prescriptive:Descriptive::Static-Typing:Dynamic-Typing Well, not really, but there is a somewhat-analogous contrast: Authoritarian control vs. organic collaboration. English works as a communicaions medium no worse than do languages with strict, authoritarian control over their vocabulary and syntax--the dire predictions of grammarians and language purists notwithstanding. Smalltalk programs work just as well, if not better, than those written in statically-typed languages--the dire predictions of the static-type constraint fundamentalists notwithstanding. --Alan |
Re: election details *PLEASE READ*
|
|
In reply to this post by Cees De Groot
Cees de Groot wrote:
> On 2/21/07, Andreas Raab <[hidden email]> wrote: >> Should we actively pursue changes? > > [I take it you won't mind getting answers from other candidates :-)] Of course. I'm interested in getting a basic feeling for what the candidates think about rate of change, directions of change, how (or if) to deal with them etc. And your comments are right on topic. Cheers, - Andreas > Yes. > > The biggest weakness in Smalltalk/Squeak atm is that it doesn't scale > well. At the very least, something in the area of namespacing is > needed - this is one thing that Java got right. And personally, I > think Goran's approach should be adopted ASAP because it is minimal > while getting a long way into the direction of solving the problem at > hand. > > Beyond that - modules, components, or what you want to call them. I'm > a Jini adept, and I've seen the power of having a network of > cooperating components work for you. I also like E a lot, and think > that some sandboxing system is required to scale Squeak - we must > clean up the kernel to make it fully capability-based (also something > that Java got more right than most people assume). > > Also - I'm discussing this sort of stuff with a friend who's > experimenting with a homebrew language - these components should carry > around more information than just bytecode. They need to be > "multimedial" in a sense, carrying diagrams, design notes, maybe even > various partly-complete views of the source code, whatever it takes to > make components (and sets of components) understandable to "users". > > As what the board's role should be here: encouragement, and actively > rallying to get things included. Also, I think that the primary focus > of financial support should be in this area. > > Oh- and the dogma of backwards compatibility has done more unnecessary > damage than I can begin to tell, IMNSHO, so I'm all for > easing/releasing that restriction between major releases. > > |
Re: election details *PLEASE READ*
|
|
In reply to this post by tblanchard
Todd Blanchard wrote:
> The question was - What do you believe is the future of Smalltalk? My > answer was from a social/market/adoption perspective - you seem to have > taken it from a technical roadmap perspective. To be blunt, I have imagined you giving a talk at O'Reilly and being asked by the audience "So what is the future of Squeak and Smalltalk?". And I was cringing reading that response in the face of twenty years of blatant stagnation of Smalltalk compared to almost daily visible progress in other (both mainstream and not) languages. Cheers, - Andreas |
Re: election details *PLEASE READ*
|
|
I can see that now that youve mentioned it - but that's not the
context in which I answered it. There are many futures being pursued. Some will pan out - some won't. I can't really tell what will. I could go down the laundry list of nifty efforts that will benefit me most - like exupery, seaside, pier/magritte, better networking, traits... but you know these as well as I do. Plus there are a number of pain points around code management/modularity that could use attention. The key is to stay alert and look for opportunities. On Feb 21, 2007, at 11:20 PM, Andreas Raab wrote: > Todd Blanchard wrote: >> The question was - What do you believe is the future of >> Smalltalk? My answer was from a social/market/adoption >> perspective - you seem to have taken it from a technical roadmap >> perspective. > > To be blunt, I have imagined you giving a talk at O'Reilly and > being asked by the audience "So what is the future of Squeak and > Smalltalk?". And I was cringing reading that response in the face > of twenty years of blatant stagnation of Smalltalk compared to > almost daily visible progress in other (both mainstream and not) > languages. > > Cheers, > - Andreas > |
Re: election details *PLEASE READ*
|
|
In reply to this post by Adrian Lienhard
Adrian Lienhard wrote:
> Of course the tools are not perfect. Instead of helping to improve the > situation people tend to complain. Unfortunately this will not bring us > forward. But hey, its not that important, is it? Isn't it more like: To use traits you need tools, to write tools you need to understand traits, and to understand traits you need to use them? I've been poking around in the traits implementation myself (fairly well documented in [1], and [2]) and although I have a very good understanding about the metaclass relationships in Squeak < 3.9 I found the traits implementation basically impenetrable. If I look at who implements a method and get ten implementors thrown at me where there used to be one or two, it's just not helpful. I stopped digging into it for that reason - the traits class kernel has become completely inaccessible to me. I'm starting to think that implementing traits using traits may have been a mistake for that very reason. Maybe this should have done as a second step or so. But the way the situation is I think there may only be half a dozen people in the world who have any idea of how that traits kernel works. The rest is doomed to use tools that are simply not up to the job and have basically no chance to really get into it. Cheers, - Andreas [1]http://lists.squeakfoundation.org/pipermail/squeak-dev/2005-August/094009.html [2]http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-October/110494.html |
Re: election details *PLEASE READ*
|
|
Hi Andreas,
on Thu, 22 Feb 2007 08:36:49 +0100, you wrote: > Adrian Lienhard wrote: >> Of course the tools are not perfect. Instead of helping to improve the >> situation people tend to complain. Unfortunately this will not bring us >> forward. But hey, its not that important, is it? > > Isn't it more like: To use traits you need tools, to write tools you > need to understand traits, and to understand traits you need to use them? > > I've been poking around in the traits implementation myself (fairly well > documented in [1], and [2]) and although I have a very good > understanding about the metaclass relationships in Squeak < 3.9 I found > the traits implementation basically impenetrable. If I look at who > implements a method and get ten implementors thrown at me where there > used to be one or two, it's just not helpful. I stopped digging into it > for that reason - the traits class kernel has become completely > inaccessible to me. > > I'm starting to think that implementing traits using traits may have > been a mistake for that very reason. Maybe this should have done as a > second step or so. But the way the situation is I think there may only > be half a dozen people in the world who have any idea of how that traits > kernel works. C'mon :) Isn't this the same with a) Interpreter, b) Seaside, c) Compiler & NewCompiler, d) Monticello, e) Morphics, f) <put your's here> I understand and share parts of your critique, in fact Traits seems to be more at the heart of "it" and lacks efficient tool support but, try to make a substantial change to a) - f) or ask more than the respective dozen of people to describe, in understandable terms, how these a) - f) effectly work: absolutely no difference, nil, zero, zippo. No offense intended, Andreas. But Traits is no exception the way it can be interpreted from your postings. /Klaus > The rest is doomed to use tools that are simply not up to the job and > have basically no chance to really get into it. > > Cheers, > - Andreas > > [1]http://lists.squeakfoundation.org/pipermail/squeak-dev/2005-August/094009.html > [2]http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-October/110494.html > > |
Re: election details *PLEASE READ*
|
|
Klaus D. Witzel wrote:
> C'mon :) Isn't this the same with a) Interpreter, b) Seaside, c) > Compiler & NewCompiler, d) Monticello, e) Morphics, f) <put your's here> Not sure which part you are referring to here. Whether you mean the number of people really understanding those systems, or whether you mean that the self-implementing part, or whether you mean that the usefulness of any of the above is intrinsically tied to an tool dependency. > I understand and share parts of your critique, in fact Traits seems to > be more at the heart of "it" and lacks efficient tool support but, try > to make a substantial change to a) - f) or ask more than the respective > dozen of people to describe, in understandable terms, how these a) - f) > effectly work: absolutely no difference, nil, zero, zippo. > > No offense intended, Andreas. But Traits is no exception the way it can > be interpreted from your postings. You are of course right. If you interpret it that way, it's not correct. My criticism is elsewhere: I am very upset about how much harder it is to understand traits than any of the things you mention above. I went through the NewCompiler in an afternoon, Seaside took me weekend, I actively hacked on Monticello. In all of these cases I was able to navigate and learn a large and completely unknown (and sometimes not too pretty) code base in a very reasonable amount of time. In the traits implementation I failed miserably, and I am not quite sure why. That is my criticism of traits. And it is quite possible that this is related to insufficient tools, but I'm sorry, if I can't understand how things ought to work then I won't be able to help building tools for it. Cheers, - Andreas |
Re: election details *PLEASE READ*
|
|
Hi Andreas,
on Thu, 22 Feb 2007 09:17:21 +0100, you wrote: > Klaus D. Witzel wrote: >> C'mon :) Isn't this the same with a) Interpreter, b) Seaside, c) >> Compiler & NewCompiler, d) Monticello, e) Morphics, f) <put your's here> > > Not sure which part you are referring to here. Whether you mean the > number of people really understanding those systems, or whether you mean > that the self-implementing part, or whether you mean that the usefulness > of any of the above is intrinsically tied to an tool dependency. Let's say: yes. >> I understand and share parts of your critique, in fact Traits seems to >> be more at the heart of "it" and lacks efficient tool support but, try >> to make a substantial change to a) - f) or ask more than the respective >> dozen of people to describe, in understandable terms, how these a) - f) >> effectly work: absolutely no difference, nil, zero, zippo. >> No offense intended, Andreas. But Traits is no exception the way it >> can be interpreted from your postings. > > You are of course right. If you interpret it that way, it's not correct. > My criticism is elsewhere: I am very upset about how much harder it is > to understand traits than any of the things you mention above. I went > through the NewCompiler in an afternoon, Seaside took me weekend, I > actively hacked on Monticello. In all of these cases I was able to > navigate and learn a large and completely unknown (and sometimes not too > pretty) code base in a very reasonable amount of time. > > In the traits implementation I failed miserably, and I am not quite sure > why. That is my criticism of traits. And it is quite possible that this > is related to insufficient tools, but I'm sorry, if I can't understand > how things ought to work then I won't be able to help building tools for > it. I agree [with the implication as well as its anaphor :-] Smalltalk (Squeak) was built and is maintained by an elitarian group of people (a), also the packages. And "it" is being used, debugged and extended by an even more so elitarian group of people (b), which on SqP are called users (!). "it" being libraries, classes, methods, or whatsoever code (even isolated lines). The (b)'s are even more skilled (resp. a second kind of skill) because they clean-up the junkyard[1] produced by (a) raisedTo: time. For the time being, the application of Traits to itself seems to transcendent some of the (b)'s :) But Traits must become usable for the (b)'s, no question. /Klaus [1] as an example, with Java you can't expect that your changes to core classes (example: java.lang.Class) will ever make it into the mainstream; this is an example of the kind code that I think is on the developer's junkyard. > Cheers, > - Andreas > > |
Re: election details *PLEASE READ*
|
|
In reply to this post by Andreas.Raab
On Feb 22, 2007, at 08:36 , Andreas Raab wrote:
> Adrian Lienhard wrote: >> Of course the tools are not perfect. Instead of helping to improve >> the situation people tend to complain. Unfortunately this will not >> bring us forward. But hey, its not that important, is it? > > Isn't it more like: To use traits you need tools, to write tools > you need to understand traits, and to understand traits you need to > use them? I don't think you need to understand its internal details to be able to build tools. You do not need to enhance kernel but use the interface that is there already. E.g., Trait>>#users will return you all classes and traits that use a trait. Its just that this kind of information is lacking in the UI. > I've been poking around in the traits implementation myself (fairly > well documented in [1], and [2]) and although I have a very good > understanding about the metaclass relationships in Squeak < 3.9 I > found the traits implementation basically impenetrable. If I look > at who implements a method and get ten implementors thrown at me > where there used to be one or two, it's just not helpful. I stopped > digging into it for that reason - the traits class kernel has > become completely inaccessible to me. Just to make that clear. This contradicts to your mail [3]. Since [2] the traits structure of the kernel was simplified. You even looked at this and you said in [3] that it indeed helps you to understand how this all works. I do not want to start a new endless discussion. > I'm starting to think that implementing traits using traits may > have been a mistake for that very reason. Maybe this should have > done as a second step or so. We first implemented it without traits. But since we wanted to keep the old metaclass hierarchy largely unchanged the resulting code duplication just made it unmaintainable. Traits seemed like an obvious solution to that. [...] > [1]http://lists.squeakfoundation.org/pipermail/squeak-dev/2005- > August/094009.html > [2]http://lists.squeakfoundation.org/pipermail/squeak-dev/2006- > October/110494.html [3] http://lists.squeakfoundation.org/pipermail/squeak-dev/2006- October/110526.html Cheers, Adrian |
Re: election details (was "Squeak Foundation Board 2007 Candidates")
|
|
In reply to this post by Daniel Vainsencher-3
Il giorno mer, 21/02/2007 alle 02.06 +0200, Daniel Vainsencher ha
scritto: > Note that the wiki page exists [1], it has links to election pages for > each of the candidates. > > Todd, Cees, Brad, Craig and Tim have used those to put up some > information and links about themselves and their intentions. There are > two questions there pending answers for Stef and Tansel. > >[1] > http://wiki.squeak.org/squeak/Squeak%20Foundation%20Board%202007%20Election Keith and I put up some info in our pages, too. They are reachable from the url above. Giovanni |
Re: election details (was "Squeak Foundation Board 2007 Candidates")
|
|
Thank you Giovanni,
so now we can see that some of the candidates' pages are still blank... /Klaus On Thu, 22 Feb 2007 20:09:02 +0100, Giovanni Corriga wrote: > Il giorno mer, 21/02/2007 alle 02.06 +0200, Daniel Vainsencher ha > scritto: >> Note that the wiki page exists [1], it has links to election pages for >> each of the candidates. >> >> Todd, Cees, Brad, Craig and Tim have used those to put up some >> information and links about themselves and their intentions. There are >> two questions there pending answers for Stef and Tansel. >> >> [1] >> http://wiki.squeak.org/squeak/Squeak%20Foundation%20Board%202007%20Election > > Keith and I put up some info in our pages, too. They are reachable from > the url above. > > Giovanni > > > |
|
|
In reply to this post by tblanchard
+1. Python was mentioned before, but I use a little python every day at
work (and a lot on some days). It's not a bad language as script languages go, but what does it have that is special really? A flexible module system. That is seriously the only thing I can think of. And I am with you on Erlang as well. I have been thinking about what it would take to make a Squeak package that does that. In fact, looking at Squeaksource I think I saw some that might already be close. :) I think making Commanche a viable web serving platform end-to-end would be a bin win. A lot of synergy is there to be had for such systems. And watching people get excited about Eclipse being able to run a little code and then change it "live" was a pretty vivid demo of what you are saying (I've been saying it a while myself) about languages trying to converge on smalltalk. >From: Todd Blanchard <[hidden email]> >Reply-To: The general-purpose Squeak developers >list<[hidden email]> >To: The general-purpose Squeak developers >list<[hidden email]> >Subject: Re: election details *PLEASE READ* >Date: Wed, 21 Feb 2007 00:24:33 -0800 > > >On Feb 20, 2007, at 11:57 PM, Alan Lovejoy wrote: > >>Your comment made me think of the difference in attitude between French >>speakers and English Speakers. > >I don't find this analogy particularly compelling. I don't think people >are really trying to keep Smalltalk 'pure'. I think they're trying to >find ways to improve it. Lots of things have been tried - multiple >inheritance, prototype based vs class based models, access control >wrappers, etc... The cool thing is you can make it what you want already. > The trick is getting your nifty thing adopted into the standard package. > >>Other programming languages have been stealing from Smalltalk for >>decades. >>It's time we returned the favor. > >I'm in favor of that - but honestly, there hasn't been a lot worth >stealing from the mainstream. > >I have been looking at erlang recently and find some of the parallel/ >process/queue constructs interesting and would love to try to bring some >of that over and try building a high performance web server based on those >patterns. > >And then, of course, there are interesting technologies that have nothing >to do with the language but would make a great addition to the platform. >Like Supple http://www.cs.washington.edu/ai/supple/ - a really nifty demo >I saw last year. > >So there is lots of great stuff to steal - but not much of it from the >mainstream languages - they mostly seem to ape the last generation and >then take a little lunge in the direction of Smalltalk. > >-Todd Blanchard > _________________________________________________________________ Want a degree but can't afford to quit? Top school degrees online - in as fast as 1 year http://forms.nextag.com/goto.jsp?url=/serv/main/buyer/education.jsp?doSearch=n&tm=y&search=education_text_links_88_h288c&s=4079&p=5116 |
|
|
In reply to this post by Andreas.Raab
Namespaces ok, but the way they have been done is not always that great.
Modules are pretty much the same thing, and interfaces? No. Traits are much better then interfaces imo. >From: Andreas Raab <[hidden email]> >Reply-To: The general-purpose Squeak developers >list<[hidden email]> >To: The general-purpose Squeak developers >list<[hidden email]> >Subject: Re: election details *PLEASE READ* >Date: Wed, 21 Feb 2007 00:40:18 -0800 > >Todd Blanchard wrote: >>I'm in favor of that - but honestly, there hasn't been a lot worth >>stealing from the mainstream. > >Really? Namespaces? Modules? Interfaces? Every even remotely mainstream >language I am aware about has at least two out of these three - you don't >find those worthwhile? > >>So there is lots of great stuff to steal - but not much of it from the >>mainstream languages - they mostly seem to ape the last generation and >>then take a little lunge in the direction of Smalltalk. > >I must admit I'm not particularly impressed with that overall assessment. > >Cheers, > - Andreas > > _________________________________________________________________ Find what you need at prices youll love. Compare products and save at MSN® Shopping. http://shopping.msn.com/default/shp/?ptnrid=37,ptnrdata=24102&tcode=T001MSN20A0701 |
|
|
In reply to this post by Göran Krampe
>From: Göran Krampe <[hidden email]>
>Reply-To: [hidden email], The general-purpose Squeak developers >list<[hidden email]> >To: "The general-purpose Squeak developers >list"<[hidden email]> >Subject: Re: election details *PLEASE READ* >Date: Wed, 21 Feb 2007 09:59:52 +0100 (CET) > >- Interfaces. Yes, might be neat to have. Traits touch on this a bit and >we also have SmallInterfaces (which I never have looked at). I really >don't know if it would hurt more than it would help. Touches on a bit? Java interfaces are nothing more then c++ base classes that have virtual methods that deriving classes must implement. Traits is already better then this by at least allowing you to specify what the default code implementation is. _________________________________________________________________ The average US Credit Score is 675. The cost to see yours: $0 by Experian. http://www.freecreditreport.com/pm/default.aspx?sc=660600&bcd=EMAILFOOTERAVERAGE |
|
|
In reply to this post by Cees De Groot
>From: "Cees de Groot" <[hidden email]>
>Reply-To: The general-purpose Squeak developers >list<[hidden email]> >To: "The general-purpose Squeak developers >list"<[hidden email]> >Subject: Re: election details *PLEASE READ* >Date: Wed, 21 Feb 2007 10:47:19 +0100 > >On 2/21/07, Andreas Raab <[hidden email]> wrote: >>Should we actively pursue changes? > >[I take it you won't mind getting answers from other candidates :-)] > >Yes. > >The biggest weakness in Smalltalk/Squeak atm is that it doesn't scale >well. At the very least, something in the area of namespacing is >needed - this is one thing that Java got right. And personally, I >think Goran's approach should be adopted ASAP because it is minimal >while getting a long way into the direction of solving the problem at >hand. I don't agree that Java got it right. Java just stuck something in there. We can do, and I believe have done, better. That is, I think there are better implementations of a namespace type system out there to be adopted. >From the mainstream world, python is pretty good as is Haskell. IMO a simple "stick colons in it" doesn't do anything but add two characters per class and make the code uglier. We can do better. _________________________________________________________________ With tax season right around the corner, make sure to follow these few simple tips. http://articles.moneycentral.msn.com/Taxes/PreparationTips/PreparationTips.aspx?icid=HMFebtagline |
|
|
In reply to this post by tblanchard
>From: Todd Blanchard <[hidden email]>
>Reply-To: The general-purpose Squeak developers >list<[hidden email]> >To: The general-purpose Squeak developers >list<[hidden email]> >Subject: Re: election details *PLEASE READ* >Date: Wed, 21 Feb 2007 02:14:38 -0800 > >The question was - What do you believe is the future of Smalltalk? My >answer was from a social/market/adoption perspective - you seem to have >taken it from a technical roadmap perspective. > >What I meant when I said other languages seem to be approaching Smalltalk >is that they adopt more ST features all the time and the prejudicial >barriers are dropping. It is a fine time to win converts and grow the >user base. Consider how many people no longer think garbage collection is >an intolerable drain on performance. IOW, I think the future of Smalltalk >is bright and that it can gain mind/ marketshare as a language. So I see a >future of growing user base and rising visibility. This is exactly how I took your statement. Though I can understand Andreas wanting to get it clarified. >>Do we need to protect the pureness of Smalltalk? > >No, but we do need to protect the stability. My platform - if you >bothered to go read it, is about making Squeak useful for making >commercial quality things. http://wiki.squeak.org/squeak/5922 Purity? For me personally, it depends on what is meant. If you mean sticking to the blue book 100%, then no of course not. But changes need to take us forward not backward. Smalltalk is IMO the most productive environment there is, and that needs to be preserved. So changes like, for example, trying to make the image file oriented instead of image oriented would be very negative in my mind. _________________________________________________________________ Mortgage rates as low as 4.625% - Refinance $150,000 loan for $579 a month. Intro*Terms http://www.NexTag.com |
|
|
In reply to this post by Roel Wuyts
>From: Roel Wuyts <[hidden email]>
>Reply-To: The general-purpose Squeak developers >list<[hidden email]> >To: The general-purpose Squeak developers >list<[hidden email]> >Subject: Re: election details *PLEASE READ* >Date: Wed, 21 Feb 2007 22:52:45 +0100 > >I drink do that. Cheers Andreas. > >It's fun that especially a very open and reflective language like >Smalltalk actually is not extended very much (or only within small >research projects not taken up by the community). Where are the macro >systems ? Variable length argument lists ? Nifty versioning and packaging >systems ? Monads ? Usable typing systems ? etc. etc. But before we decide a feature is missing from Squeak because someone else has it, we must first think *why* some other place has it. For an extreme example, C has pointers and Squeak doesn't. Does anyone think Squeak needs pointers? Likewise, Haskell has Monads. But that is because there is no other language supported way to represent state change. It is a very nice language, but for Monads to work right, I think you kind of need the whole thing (i.e. partial application, type checking, the things that make Haskell Haskell). So far, any time I would have reached for variable length argument lists in other languages, I used meta-programming in Smalltalk. And Macro systems? It can be put in easily, and I have code that generates code, but due to the nature of Smalltalk, we can add language constructs without having to resort to macros as Lisp does. Having said all that, I think Squeak could use more formal Lazy evaluation support, and I published some classes for it. And the package system is a known open issue. I personally believe change sets could be made more advanced to help out in a lot of areas (for one, to help with documenting that elusive "why"). I think we should try to take things from other languages that make sense for smalltalk, but I don't think there will be a time when one language (even smalltalk!) will be perfect for every task. We will still need at least Haskell. :) _________________________________________________________________ Refi Now: Rates near 39yr lows! $430,000 Mortgage for $1,399/mo - Calculate new payment http://www.lowermybills.com/lre/index.jsp?sourceid=lmb-9632-17727&moid=7581 |
|
|
In reply to this post by Roel Wuyts
>From: Roel Wuyts <[hidden email]>
>Reply-To: The general-purpose Squeak developers >list<[hidden email]> >To: The general-purpose Squeak developers >list<[hidden email]> >Subject: Re: election details *PLEASE READ* >Date: Wed, 21 Feb 2007 23:03:54 +0100 > >Broadening this a bit: these three language families (Logic programming, >functional programming and (pure) object-oriented programming are all >considered 5th generation languages. I often wonder why none of these >well-designed, clean languages were never really popular. I actually >believe that this is one of the deep, underlying reasons: people that >embrace this language and get it are so hooked that they are absorbed and >never get out again. This is what Andreas is pointing to. But don't just assume that because Java is popular and Squeak isn't as much, that Java is right and Smalltalk is wrong. Maybe we really *do* have the best system and it just hasn't been adopted. They say the worse something is, the more it will be advertised, and in my experience this has been true. _________________________________________________________________ The average US Credit Score is 675. The cost to see yours: $0 by Experian. http://www.freecreditreport.com/pm/default.aspx?sc=660600&bcd=EMAILFOOTERAVERAGE |
|
|
In reply to this post by J J-6
J J skrev:
>> From: Roel Wuyts <[hidden email]> >> Reply-To: The general-purpose Squeak developers >> list<[hidden email]> >> To: The general-purpose Squeak developers >> list<[hidden email]> >> Subject: Re: election details *PLEASE READ* >> Date: Wed, 21 Feb 2007 22:52:45 +0100 >> >> I drink do that. Cheers Andreas. >> >> It's fun that especially a very open and reflective language like >> Smalltalk actually is not extended very much (or only within small >> research projects not taken up by the community). Where are the >> macro systems ? Variable length argument lists ? Nifty versioning >> and packaging systems ? Monads ? Usable typing systems ? etc. etc. > > But before we decide a feature is missing from Squeak because someone > else has it, we must first think *why* some other place has it. For > an extreme example, C has pointers and Squeak doesn't. Does anyone > think Squeak needs pointers? > > Likewise, Haskell has Monads. But that is because there is no other > language supported way to represent state change. It is a very nice > language, but for Monads to work right, I think you kind of need the > whole thing (i.e. partial application, type checking, the things that > make Haskell Haskell). > > So far, any time I would have reached for variable length argument > lists in other languages, I used meta-programming in Smalltalk. And > Macro systems? It can be put in easily, and I have code that > generates code, but due to the nature of Smalltalk, we can add > language constructs without having to resort to macros as Lisp does. > > Having said all that, I think Squeak could use more formal Lazy > evaluation support, and I published some classes for it. And the > package system is a known open issue. I personally believe change > sets could be made more advanced to help out in a lot of areas (for > one, to help with documenting that elusive "why"). > > I think we should try to take things from other languages that make > sense for smalltalk, but I don't think there will be a time when one > language (even smalltalk!) will be perfect for every task. We will > still need at least Haskell. :) processors. What must be done with Squeak to utilize all the processors and what are the benefits and drawback of the different approaches ? What can the board do to help in this effort ? Karl |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |