There's an interesting post and discussion here:
http://weblog.raganwald.com/2007/10/too-much-of-good-thing-not-all.html |
On 28-Oct-07, at 2:32 AM, Michael Davies wrote: > There's an interesting post and discussion here: > http://weblog.raganwald.com/2007/10/too-much-of-good-thing-not- > all.html Actually I think it is 95% bullshit. It reads like it is trying to make excuses for the poor quality of java. And that apparent quoting of Alan is not one I am familiar with - and I'm fairly sure I was there when he made the comment about C++ not being what he had in mind. I certainly can't find any net source for this 'full' quote. I did come acros some astonishing rubbish while searching for it though, including what looks like a Ruby hagiography where some dimwit appears to be claiming "Why do I have to put the thing even Smalltalk abandoned (leaving illusion though) in Ruby? They are ugly too, I think. -- matz on Smalltalk often control structure being object is mere illusion in most Smalltalk implementation " Which is such a piece of crapulent cockamamie confabulabulatory contrariness I'm amazed the net didn't reach out through the writer's browser and strangle him/her to save the rest of us frim his/her wisdumb. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Law of Logical Argument: Anything is possible if you don't know what you are talking about. |
tim Rowledge wrote:
> > > I did come acros some astonishing rubbish while searching for it > though, including what looks like a Ruby hagiography where some dimwit > appears to be claiming > "Why do I have to put the thing even Smalltalk abandoned (leaving > illusion though) in Ruby? They are ugly too, I think. -- matz > on Smalltalk often control structure being object is mere illusion in > most > Smalltalk implementation " criticize something that makes as much sense as "Colorless green ideas sleep furiously" or "Hypotenuses reciprocate against thunderous abstractions." --Alan |
In reply to this post by timrowledge
Well, it is a long winded way of saying "yes, multimethod dispatch is
nice". But as he points out, the same thing can be done with double-dispatch (visitor pattern etc.), which is what multimethod has to do anyway, at runtime. But having multimethod is less typing and more concise, which is worth something. I personally can't think of any concise way to add it to Smalltalk. But a good question comes out of this: Do we have this duplication, and can traits (i.e. the "not connected to the specific classes" he mentioned) help out with this? On 10/28/07, tim Rowledge <[hidden email]> wrote: > > On 28-Oct-07, at 2:32 AM, Michael Davies wrote: > > > There's an interesting post and discussion here: > > http://weblog.raganwald.com/2007/10/too-much-of-good-thing-not- > > all.html > > Actually I think it is 95% bullshit. It reads like it is trying to > make excuses for the poor quality of java. > > And that apparent quoting of Alan is not one I am familiar with - and > I'm fairly sure I was there when he made the comment about C++ not > being what he had in mind. I certainly can't find any net source for > this 'full' quote. > > I did come acros some astonishing rubbish while searching for it > though, including what looks like a Ruby hagiography where some dimwit > appears to be claiming > "Why do I have to put the thing even Smalltalk abandoned (leaving > illusion though) in Ruby? They are ugly too, I think. -- matz > on Smalltalk often control structure being object is mere illusion in > most > Smalltalk implementation " > > Which is such a piece of crapulent cockamamie confabulabulatory > contrariness I'm amazed the net didn't reach out through the writer's > browser and strangle him/her to save the rest of us frim his/her > wisdumb. > > > tim > -- > tim Rowledge; [hidden email]; http://www.rowledge.org/tim > Law of Logical Argument: Anything is possible if you don't know what > you are talking about. > > > > > |
> Well, it is a long winded way of saying "yes, multimethod dispatch is
> nice". But as he points out, the same thing can be done with > double-dispatch (visitor pattern etc.), which is what multimethod has > to do anyway, at runtime. But having multimethod is less typing and > more concise, which is worth something. I personally can't think of > any concise way to add it to Smalltalk. I did something like that a long time ago. I called it 'Functional Pattern Matching' as I just attended a course about Haskell at that time. In fact it is an implementation of multi-methods: http://renggli.freezope.org/programming/smalltalk/fpm The documentation is a bit misleading. All the matching presented can also be done on the arguments. The code itself probably doesn't work with recent images anymore. Try with Squeak 3.6 or 3.7. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch |
In reply to this post by timrowledge
On Oct 28, 2007, at 2007-10-28, 1:39 PM, tim Rowledge wrote: > And that apparent quoting of Alan is not one I am familiar with - > and I'm fairly sure I was there when he made the comment about C++ > not being what he had in mind. I certainly can't find any net source > for this 'full' quote. The quote is from Alan's keynote address at OOPSLA '97 <http://video.google.com/videoplay?docid=-2950949730059754521 >, The Computer Revolution Hasn't Happened Yet. It occurs at about 10:30 into the video. Rick smime.p7s (5K) Download Attachment |
On 28-Oct-07, at 12:52 PM, Rick Zaccone wrote: > > On Oct 28, 2007, at 2007-10-28, 1:39 PM, tim Rowledge wrote: > >> And that apparent quoting of Alan is not one I am familiar with - >> and I'm fairly sure I was there when he made the comment about C++ >> not being what he had in mind. I certainly can't find any net >> source for this 'full' quote. > > The quote is from Alan's keynote address at OOPSLA '97 <http://video.google.com/videoplay?docid=-2950949730059754521 > >, The Computer Revolution Hasn't Happened Yet. It occurs at about > 10:30 into the video. Ah, ok. I'm fairly sure that isn't the first time he pointed that out. I would guess more like the very early 90's back when C++ was 'hot' and I also don't think he said anything about Smalltalk on that occasion. I also claim that the conflating of the two phrases and quoting them as if intended as praise for Ruby is disingenuous at least and plain deceit at worst. But what can be expected from people that appear to understand almost nothing about OOP. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Logic: The art of being wrong with confidence... |
This is what I don't like about the script languages: their creators
focus their designs around not understanding things. E.g. Larry has made multiple statements that indicate he doesn't understand OO, Guido did likewise for functional programming, and well Matz.... you read his comments. :) On 10/28/07, tim Rowledge <[hidden email]> wrote: > > On 28-Oct-07, at 12:52 PM, Rick Zaccone wrote: > > > > > On Oct 28, 2007, at 2007-10-28, 1:39 PM, tim Rowledge wrote: > > > >> And that apparent quoting of Alan is not one I am familiar with - > >> and I'm fairly sure I was there when he made the comment about C++ > >> not being what he had in mind. I certainly can't find any net > >> source for this 'full' quote. > > > > The quote is from Alan's keynote address at OOPSLA '97 <http://video.google.com/videoplay?docid=-2950949730059754521 > > >, The Computer Revolution Hasn't Happened Yet. It occurs at about > > 10:30 into the video. > > Ah, ok. I'm fairly sure that isn't the first time he pointed that out. > I would guess more like the very early 90's back when C++ was 'hot' > and I also don't think he said anything about Smalltalk on that > occasion. > > I also claim that the conflating of the two phrases and quoting them > as if intended as praise for Ruby is disingenuous at least and plain > deceit at worst. But what can be expected from people that appear to > understand almost nothing about OOP. > > > tim > -- > tim Rowledge; [hidden email]; http://www.rowledge.org/tim > Logic: The art of being wrong with confidence... > > > > |
In reply to this post by Lukas Renggli
Ah, I've seen this. Interesting solution. Some kind of DSL
translation is the only way I can think of to handle this in Smalltalk. Thanks for the link. On 10/28/07, Lukas Renggli <[hidden email]> wrote: > > Well, it is a long winded way of saying "yes, multimethod dispatch is > > nice". But as he points out, the same thing can be done with > > double-dispatch (visitor pattern etc.), which is what multimethod has > > to do anyway, at runtime. But having multimethod is less typing and > > more concise, which is worth something. I personally can't think of > > any concise way to add it to Smalltalk. > > I did something like that a long time ago. I called it 'Functional > Pattern Matching' as I just attended a course about Haskell at that > time. In fact it is an implementation of multi-methods: > > http://renggli.freezope.org/programming/smalltalk/fpm > > The documentation is a bit misleading. All the matching presented can > also be done on the arguments. The code itself probably doesn't work > with recent images anymore. Try with Squeak 3.6 or 3.7. > > Cheers, > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > |
In reply to this post by Michael Davies-2
On Sun, 28 Oct 2007 01:32:34 -0800, Michael Davies
<[hidden email]> wrote: > There's an interesting post and discussion here: > http://weblog.raganwald.com/2007/10/too-much-of-good-thing-not-all.html I know we wrestle with symmetry from time-to-time but is it true that: 1 + 2.0 should yield the same result as 2.0 + 1 ? |
In reply to this post by Jason Johnson-5
On 10/28/07, Jason Johnson wrote:
> This is what I don't like about the script languages: their creators > focus their designs around not understanding things. I hope you will grant an exemption for scsh from that law. Is there a smalltalk scripting machine somewhere? |
Oh sorry, I just meant the big 3. There are lots of scripting
languages (e even claims to be a scripting language) that I don't know enough about to say either way. But I hope it's not the case. :) On 10/29/07, David Corking <[hidden email]> wrote: > On 10/28/07, Jason Johnson wrote: > > This is what I don't like about the script languages: their creators > > focus their designs around not understanding things. > > I hope you will grant an exemption for scsh from that law. > > Is there a smalltalk scripting machine somewhere? > > |
In reply to this post by Blake-5
Blake schrieb:
> On Sun, 28 Oct 2007 01:32:34 -0800, Michael Davies > <[hidden email]> wrote: > >> There's an interesting post and discussion here: >> http://weblog.raganwald.com/2007/10/too-much-of-good-thing-not-all.html > > I know we wrestle with symmetry from time-to-time but is it true that: > > 1 + 2.0 > > should yield the same result as > > 2.0 + 1 > > ? > > case the integer is converted to a float, and those two floats are added. Floating point addition is commutative). In general, a + b can be unequal to b + a, for example, if you implement the #+ method in class String to mean concatenation. Even in mathematical notations, there are operator symbols which are commutative when used with scalars and non-commutative when used with other mathematical objects. Cheers, Hans-Martin |
On Sun, 28 Oct 2007 22:53:28 -0800, Hans-Martin Mosner <[hidden email]> wrote:
> For the current arithmetic implementation in Smalltalk, yes (in either > case the integer is converted to a float, and those two floats are > added. Floating point addition is commutative). Yes, I know that it is. > In general, a + b can be unequal to b + a, for example, if you implement > the #+ method in class String to mean concatenation. > Even in mathematical notations, there are operator symbols which are > commutative when used with scalars and non-commutative when used with Well, and what I'm wondering aloud is whether if you send a plus message to an integer you'd want an integer back, and a plus message to a real should return a real. I'm not suggesting anything be changed in Smalltalk; I'm just questioning the premise that symmetry is necessary or even desirable. |
In reply to this post by dcorking
Il giorno lun, 29/10/2007 alle 01.42 +0000, David Corking ha scritto:
> On 10/28/07, Jason Johnson wrote: > > This is what I don't like about the script languages: their creators > > focus their designs around not understanding things. > > I hope you will grant an exemption for scsh from that law. > > Is there a smalltalk scripting machine somewhere? GNU Smalltalk and especially the new SYX (Smalltalk YX) are script-oriented. Giovanni |
On 10/29/07, Giovanni Corriga wrote:
> GNU Smalltalk and especially the new SYX (Smalltalk YX) are > script-oriented. Thanks! They sound very interesting. Are there unix job control primitives in those implementations? |
In reply to this post by Blake-5
Blake schrieb:
> > Well, and what I'm wondering aloud is whether if you send a plus > message to an integer you'd want an integer back, and a plus message > to a real should return a real. Well I for one would not want Smalltalk to behave like that... > > I'm not suggesting anything be changed in Smalltalk; I'm just > questioning the premise that symmetry is necessary or even desirable. > > Since there is quite some agreement in mathematics on the commutativity of the + operator when applied to scalars, it seems reasonable to implement it like that in programming languages :-) In general, designing things such that they don't break assumptions made by people using them is a good thing. There are cases where it should be done differently, but you have to have a very good reason to do that. Questioning the desirability of such "common ground assumptions" is a good way to start a brainstorming process which can lead to new insights, but for such a process the context should be made clear. In a huge mailing list it's much too easy to be mistaken for being a troll :-) Cheers, Hans-Martin |
There is a language which uses multiple-dispatch. See Slate. And it is
object-oriented. I don't see how given problem (lack of multiple dispatch) could be considered as a OO problem, or as an example against using OO principles. An OO principles is simple: associate some state with behavior. It's always a developer's decision, what to hide and what to make public in his model. -- Best regards, Igor Stasenko AKA sig. |
Igor Stasenko schrieb:
Yes, I know - Slate is a very interesting approach, and from a theoretical standpoint, I like it a lot. AFAIK there is no efficient implementation of the dispatch algorithm yet, and progress is stalled according to the web site:There is a language which uses multiple-dispatch. See Slate. And it is object-oriented.
I am all for multiple dispatch (in fact, the asymmetry of the receiver and argument roles in Smalltalk message sends is the one thing that I dislike a bit about Smalltalk.)I don't see how given problem (lack of multiple dispatch) could be considered as a OO problem, or as an example against using OO principles. A multiple dispatch based systems would need somewhat different development tools, but I think they could be as powerful as the Smalltalk browser/inspector/debugger. There also needs to be a notion about where a method is at home - in basic Smalltalk, this is always the receiver class, but in multiple dispatch systems you need some sort of "packages" in the basic system to organize things. But of course, all mature Smalltalk systems need such packages as well to support things like class extensions, so a development environment without some concept of packages would not be accepted in these days. Cheers, Hans-Martin |
On Oct 29, 2007, at 1:23 PM, Hans-Martin Mosner wrote: > Igor Stasenko schrieb: >> >> There is a language which uses multiple-dispatch. See Slate. And it >> is >> object-oriented. >> > Yes, I know - Slate is a very interesting approach, and from a > theoretical standpoint, I like it a lot. AFAIK there is no efficient > implementation of the dispatch algorithm yet, and progress is > stalled according to the web site: >> Early 2006 - The project is on hold after loss of interest from the >> lead implementor. Slate needs a significant qualitative speed boost >> for further updates. > This is a sad thing. Dispatch was NOT why Slate is slow - it's because we wrote the libraries with Strongtalk-style optimization in mind (assuming massive inlining lets you write heavily abstracted libraries), without a clear step-wise roadpath to getting there ... and so eventually the compiler developer (co-creator) left, and we had no other experts to get us through the problems. The UI was written for example, but so slow that it is completely unusable, even slower than the Sun Lively Kernel (Morphic in Javascript). That said, there is a specific challenge to make PICs work with multi- methods, but it's nothing compared to the more difficult task of implementing the darned things in the first place for a new runtime. Even the Strongtalk effort is losing momentum... -- -Brian http://briantrice.com |
Free forum by Nabble | Edit this page |