Getting double semi as sequencer harvested.
Locked
1 ...
45678910
... 13
1 ...
45678910
... 13
 
|
On Wed, 05 Sep 2007 10:19:52 -0700, tim Rowledge <[hidden email]> wrote:
> Gronk? What is clunky about a uniform, consistent syntax that has us > a) name the recipient > b) name the message to send to it > c) name any parameters to include with the message > Having a special case that lets you leave out the recipient if it is > 'self' would be clunky, confusing and tasteless. What's the point of having a context if you don't use it? self position: (self position + newPos - self center) asIntegerPoint. versus: position: (position + newPos - center) asIntegerPoint Yes. I see how that's not only clunky and confusing BUT tasteless. Worse than combining plaid with stripes. :-P~~~~~ Here's another horrid example from the Wiki entry on the abomination known as "Self": valid: base bottom between: ligature bottom + height And: base top / scale factor. and here we see the oh-so-elegant improvements ST-80 makes: valid := self base bottom between: self ligature bottom + self height and: self base top / self scale factor. Mmmmmm. =Tasteful=! |
Re: Fear and loathing of the "perlification" of Smalltalk
|
|
On 05/09/07, Blake <[hidden email]> wrote:
> On Wed, 05 Sep 2007 10:19:52 -0700, tim Rowledge <[hidden email]> wrote: > > > Gronk? What is clunky about a uniform, consistent syntax that has us > > a) name the recipient > > b) name the message to send to it > > c) name any parameters to include with the message > > Having a special case that lets you leave out the recipient if it is > > 'self' would be clunky, confusing and tasteless. > > What's the point of having a context if you don't use it? > > self position: (self position + newPos - self center) asIntegerPoint. > > versus: > > position: (position + newPos - center) asIntegerPoint > > Yes. I see how that's not only clunky and confusing BUT tasteless. Worse > than combining plaid with stripes. > > :-P~~~~~ > > Here's another horrid example from the Wiki entry on the abomination known > as "Self": > > valid: base bottom between: ligature bottom + height And: base top / > scale factor. > > and here we see the oh-so-elegant improvements ST-80 makes: > > valid := self base bottom between: self ligature bottom + self height > and: self base top / self scale factor. > > Mmmmmm. =Tasteful=! > But IMHO smalltalk example easier to read, because you don't need to watch for case of first letter in message selector.. > > > -- Best regards, Igor Stasenko AKA sig. |
Re: Fear and loathing of the "perlification" of Smalltalk
|
|
In reply to this post by Jason Johnson-5
Jason Johnson a écrit :
> To be honest I think pragmas are starting to be overrated. I don't > even know where to look to see what happens when a pragma is seen. I > suppose it is theoretically as powerful in this particular case as > macros, but for me the macros feel much more consistent. > > I would see pragmas as useful for the kind of things that Lisp does > with declare, i.e. telling the compiler the type of the argument so it > can specialize the method, tell the compiler to generate for fast > code, not safety, and so on. In other words, a kind of annotation, > since that's what it looks like to me. > Yes, pragmas are mostly used like annotations: they give "properties" to the methods... It's a step toward what Alan said of methods becoming richer objects with reacher properties. It does it the declarative way, rather than through an IDE, which is IMO more explicit than syntax highlighting conventions, at the expense of verbosity (an IDE could hide it). It could of course be used to introduce some reflexivity on thisCompiler which is compiling thisCode, making it closer to what other languages call a pragma. This could be experimented to play with alternate syntaxes like Andreas suggested, playing at a higher level with gramar rules. I like the idea of the language being more contextual. Mathematical language concision come from such feature. Put in another context, a mathematical expression meaning can change. Another simple example, Tim, a #<private> could for example generate code checking thisContext sender hierarchy at runtime and generate an exception when due. A polymorphic inlining optimizer could of course know when to strip such un-necessary checks, hence the advantage of the pragma versus a simple self checkPrivateSend... Sure this pragma/annotation feature has not expressed all its power by now. |
Re: Fear and loathing of the "perlification" of Smalltalk
|
|
In reply to this post by pwl
On 9/5/07, Peter William Lount <[hidden email]> wrote:
I just thought up an alternative to curly braces that doesn't change the compiler. I chose an unused operator and implemented it so that: 'hello' ++ 'world' ++ 1 returns an OrderedCollection('hello' 'world' 1) "actual result from my 3.10 image" You could do the same with a list of Associations to make a Dictionary. If it is slow, then you could modify the Compiler to optimise for this operator, but it wouldn't need changes to the syntax of the language. However, the block version of continuously collecting For your specific example of concurrency, I'd much rather do something like this: ( [ s1 doSomething ] ++ [s2 doSomething] ++ [s3 doSomething] ) doConcurrently. (aka: implement OrderedCollection>>doConcurrently) This pattern might have implementation possibilities such as waiting until all processes have finished before continuing, or using a set of worker threads rather than making new threads. What I'd really like to see is a concurrent Collection of some sort, where methods such as do: have multi-threaded implementations. Other languages are catching up and surpassing Smalltalk - we need to Have you seen Java recently? I'd hardly call the latest language changes "progress". IMO what Smalltalk / Squeak really needs to be competitive in the future is the ability to make full use of the latest batch of multi-cored processors. This can be done using libraries and VM modifications rather than changing the language. Michael. |
|
|
In reply to this post by Igor Stasenko
On Wed, 05 Sep 2007 13:31:19 -0700, Igor Stasenko <[hidden email]>
wrote: > None of the above seem tasteful to me :) > But IMHO smalltalk example easier to read, because you don't need to > watch for case of first letter in message selector.. I'm not crazy about mixed case in any, uh, case. |
|
|
In reply to this post by Jason Johnson-5
On Wed, 05 Sep 2007 10:22:57 -0700, Jason Johnson
<[hidden email]> wrote: > I don't find it clunky because the methods are so small. I don't find > it inconsistent because variables are the only thing that are not > messages, so if you don't see it in the method declaration it's an > instance variable. I pretty much always use accessors. Except, uh, in the accessors themselves. Heh. But it strikes me as something that should be transparent. I don't see any reason why I should have to write accesors that do nothing but provide access. > But that's just me, this is all so much easier then C++ was. Well, yeah. Smalltalk is sort of like Democracy.... > No no no. I don't know PL/I but it's a joke to call what C has > macros. That is just search and replace prepossessing nonsense. A > lisp-style macro is the full power of the language at compile time. Yeah, PL/I had that. http://en.wikipedia.org/wiki/PL/I |
Re: Fear and loathing of the "perlification" of Smalltalk
|
|
In reply to this post by Blake-5
On 9/5/07, Blake <[hidden email]> wrote:
> On Wed, 05 Sep 2007 10:19:52 -0700, tim Rowledge <[hidden email]> wrote: > > What's the point of having a context if you don't use it? Context means having to keep extra things in your head and it makes the code more complex. Didn't the Perl experiment teach you anything? ;) > > self position: (self position + newPos - self center) asIntegerPoint. > > versus: > > position: (position + newPos - center) asIntegerPoint > > Yes. I see how that's not only clunky and confusing BUT tasteless. Worse > than combining plaid with stripes. Clunky and confusing? It's uniform and obvious for me. An object always receives a message in every case. No stupid special cases to remember. But if you don't like Smalltalk there are thousands of other languages out there to try, no need to torture yourself with this one you find so ugly. > Here's another horrid example from the Wiki entry on the abomination known > as "Self": > > valid: base bottom between: ligature bottom + height And: base top / > scale factor. > > and here we see the oh-so-elegant improvements ST-80 makes: > > valid := self base bottom between: self ligature bottom + self height > and: self base top / self scale factor. > > Mmmmmm. =Tasteful=! You also don't like Self, one of the most important languages for research of our time? Really, what is it you like about Smalltalk? The IDE? You can get most of that with Java these days, and nearly everything with Lisp. |
Re: Fear and loathing of the "perlification" of Smalltalk
|
|
In reply to this post by Blake-5
On 9/6/07, Blake <[hidden email]> wrote:
> On Wed, 05 Sep 2007 10:22:57 -0700, Jason Johnson > <[hidden email]> wrote: > > I pretty much always use accessors. Except, uh, in the accessors > themselves. Heh. But it strikes me as something that should be > transparent. I don't see any reason why I should have to write accesors > that do nothing but provide access. If it's this behavior you want it's odd that you hate self so much. > Well, yeah. Smalltalk is sort of like Democracy.... I hope that doesn't mean that gradually the bad ideas win out. :( |
Re: Fear and loathing of the "perlification" of Smalltalk
|
|
In reply to this post by Nicolas Cellier-3
On 9/5/07, nicolas cellier <[hidden email]> wrote:
> > I like the idea of the language being more contextual. Mathematical > language concision come from such feature. Put in another context, a > mathematical expression meaning can change. I think Smalltalk has already shown it chooses readability over math by being one of the few languages that doesn't make you memorize evaluation rules for math expressions. And I like this. Programming is essentially managing complexity, so the simpler you can make the language the easier it is to manage the complexity of the problem you're solving. And if you can find a way to make this simple language concise as well, then you have a winner. This is why a Linguists is exactly the person you *don't* want creating a language: they try to create a language that behaves as spoken language. But spoken language is about the most complicated thing you will ever learn. It's so complicated that you can still learn new "keywords" decades after having "mastered" it. If you learn a new language you will find the language you spoke your entire life begins to fail you at times. And spoken language is one of the few things that you can use for 20+ years, move to another land and speak a new language and after some time completely lose your previous language. This is absolutely not something you want to be basing a tool for managing complexity on. And context is one of the things makes spoken language so incredibly complex and un-masterable (the other is the fact that it's a moving target, but context exaggerates this and even drives it to some extent). Think about how many misunderstandings you personally see happen every day. These come either from context or from disagreement on what a word or concept means (this case is also a context). Context is opinion. I have something in my head and instead of expressing it I say "it". Unfortunately the person/people I'm talking to either has no idea what I mean by "it", or worse they assume I mean something else and go forward based on this assumption. People who speak the most clear and cause the least misunderstandings avoid as much implicit context as they can (interestingly enough, we call this "speaking clearly"). I think programming languages should too, since it's so imperative that we avoid misunderstandings. If you have ever worked on a big C++ project, then you know the pain of trying to figure out how functions are going to get called. Overloading happens based on type. And often the values you are working with fit none of the types defined for the operation. So you have to remember what these values will implicitly turn into to know what functions will be called. Context. And despite being "typeless" Perl is even worse in this regard. The language is full of implicit contexts and behaviors based on them. I wish I could find the article where one of the Perl gurus (Conway I believe) was surprised by a Perl context regarding the for keyword after having several books out and considered a master of the language. I personally wouldn't want to see Smalltalk get things like the implicit self, splitting us further from other Smalltalks and even ourselves as we split into the "implicit self" versus "explicit self" groups as C++ did, only to decide explicit self was best practices after years of fighting about it. |
Where the implicit self is in St80 [was: Fear and loathing of the "perlification" of Smalltalk]
|
|
Hi Jason,
on Thu, 06 Sep 2007 06:08:06 +0200, you wrote: > On 9/5/07, nicolas cellier wrote: >> >> I like the idea of the language being more contextual. Mathematical >> language concision come from such feature. Put in another context, a >> mathematical expression meaning can change. > > I think Smalltalk has already shown it chooses readability over math > by being one of the few languages that doesn't make you memorize > evaluation rules for math expressions. And I like this. > > Programming is essentially managing complexity, so the simpler you can > make the language the easier it is to manage the complexity of the > problem you're solving. And if you can find a way to make this simple > language concise as well, then you have a winner. > > This is why a Linguists is exactly the person you *don't* want > creating a language: they try to create a language that behaves as > spoken language. But spoken language is about the most complicated > thing you will ever learn. It's so complicated that you can still > learn new "keywords" decades after having "mastered" it. If you learn > a new language you will find the language you spoke your entire life > begins to fail you at times. And spoken language is one of the few > things that you can use for 20+ years, move to another land and speak > a new language and after some time completely lose your previous > language. > > This is absolutely not something you want to be basing a tool for > managing complexity on. And context is one of the things makes spoken > language so incredibly complex and un-masterable (the other is the > fact that it's a moving target, but context exaggerates this and even > drives it to some extent). Think about how many misunderstandings you > personally see happen every day. These come either from context or > from disagreement on what a word or concept means (this case is also a > context). > > Context is opinion. I have something in my head and instead of > expressing it I say "it". Unfortunately the person/people I'm talking > to either has no idea what I mean by "it", or worse they assume I mean > something else and go forward based on this assumption. People who > speak the most clear and cause the least misunderstandings avoid as > much implicit context as they can (interestingly enough, we call this > "speaking clearly"). > > I think programming languages should too, since it's so imperative > that we avoid misunderstandings. If you have ever worked on a big C++ > project, then you know the pain of trying to figure out how functions > are going to get called. Overloading happens based on type. And > often the values you are working with fit none of the types defined > for the operation. So you have to remember what these values will > implicitly turn into to know what functions will be called. Context. > > And despite being "typeless" Perl is even worse in this regard. The > language is full of implicit contexts and behaviors based on them. I > wish I could find the article where one of the Perl gurus (Conway I > believe) was surprised by a Perl context regarding the for keyword > after having several books out and considered a master of the > language. > > I personally wouldn't want to see Smalltalk get things like the > implicit self, splitting us further from other Smalltalks and even > ourselves as we split into the "implicit self" versus "explicit self" > groups as C++ did, only to decide explicit self was best practices > after years of fighting about it. But it has! :) Smalltalk has implicit self, to some extent. Consider that Smalltalk and Self are at the same language level. Then, whenever you use nil, true, false, a temp/arg, an iVar or a class/pool/global var, you send that implicitly to self, in both languages :) In Smalltalk it's the compiler who knows what the receiver(s) of these implicit self messages are, it [the compiler :) ] quickly calculates the intended binding and emits a corresponding bytecode, optimizing away the costly message send. Can you see it? :) In Self the initial non-optimizing compiler doesn't know that quick binding. But the Self runtime optimizing compiler comes to the very same result (binding) as Smalltalk's compiler. It's a matter of view on things :) It'd be easy in Smalltalk to always send (self nil), (self true), (self iVar), etc :) FWIW always using explicit self (in a general sense, not only for the items mentioned above) is not possible in Self, since (implicit self) ~= (explicit self) holds in many/most cases except at the root of the parent "hierarchy". /Klaus |
Re: Where the implicit self is in St80 [was: Fear and loathing of the "perlification" of Smalltalk]
|
|
On 9/6/07, Klaus D. Witzel <[hidden email]> wrote:
> Hi Jason, > > But it has! :) Smalltalk has implicit self, to some extent. Consider that > Smalltalk and Self are at the same language level. Then, whenever you use > nil, true, false, a temp/arg, an iVar or a class/pool/global var, you send > that implicitly to self, in both languages :) To self? If you mean self as in the receiver of the message (which is what I mean), then I disagree. In Smalltalk, when the compiler sees a use or an assignment of an iVar then he generates a push opcode that accesses the current receiver, but that's not a message send, that's a low level memory access. temp/arg variables are located in the context object, not the receiver. And nil, true and false are singleton objects. I don't see what you mean with this at all. > In Smalltalk it's the compiler who knows what the receiver(s) of these > implicit self messages are, it [the compiler :) ] quickly calculates the > intended binding and emits a corresponding bytecode, optimizing away the > costly message send. > > Can you see it? :) > > In Self the initial non-optimizing compiler doesn't know that quick > binding. But the Self runtime optimizing compiler comes to the very same > result (binding) as Smalltalk's compiler. > > It's a matter of view on things :) It'd be easy in Smalltalk to always > send (self nil), (self true), (self iVar), etc :) Sorry, I don't understand this at all. This may be a way of looking at it, but I don't see it in the language, nor the blue book specifications. |
Re: Where the implicit self is in St80 [was: Fear and loathing of the "perlification" of Smalltalk]
|
|
Hi Jason,
on Thu, 06 Sep 2007 17:44:54 +0200, you wrote: > On 9/6/07, Klaus D. Witzel wrote: >> Hi Jason, >> >> But it has! :) Smalltalk has implicit self, to some extent. Consider >> that >> Smalltalk and Self are at the same language level. Then, whenever you >> use >> nil, true, false, a temp/arg, an iVar or a class/pool/global var, you >> send >> that implicitly to self, in both languages :) > > To self? If you mean self as in the receiver of the message (which is > what I mean), then I disagree. Right, didn't mean that. > In Smalltalk, when the compiler sees a > use or an assignment of an iVar then he generates a push opcode that > accesses the current receiver, Sure, that was mentioned in my previous mail. > but that's not a message send, that's a > low level memory access. right, after the compiler has done its work. > temp/arg variables are located in the > context object, not the receiver. right, the implicit self starts with the context object. > And nil, true and false are > singleton objects. sure. nobody claimed they are not singleton, no? > I don't see what you mean with this at all. Sorry for disturbing you (no offense). I offer to take this offline, if you like. >> In Smalltalk it's the compiler who knows what the receiver(s) of these >> implicit self messages are, it [the compiler :) ] quickly calculates the >> intended binding and emits a corresponding bytecode, optimizing away the >> costly message send. >> >> Can you see it? :) >> >> In Self the initial non-optimizing compiler doesn't know that quick >> binding. But the Self runtime optimizing compiler comes to the very same >> result (binding) as Smalltalk's compiler. >> >> It's a matter of view on things :) It'd be easy in Smalltalk to always >> send (self nil), (self true), (self iVar), etc :) > > Sorry, I don't understand this at all. This may be a way of looking > at it, but I don't see it in the language, nor the blue book > specifications. > NP. it's as I said, a matter of view. /Klaus |
Re: Where the implicit self is in St80 [was: Fear and loathing of the "perlification" of Smalltalk]
|
|
I'm not disturbed nor offending. I often find your messages
enlightening. But perhaps it's my lack of sleep, or something, but for the life of me I don't see this one. :) On 9/6/07, Klaus D. Witzel <[hidden email]> wrote: > Hi Jason, > > on Thu, 06 Sep 2007 17:44:54 +0200, you wrote: > > > On 9/6/07, Klaus D. Witzel wrote: > >> Hi Jason, > >> > >> But it has! :) Smalltalk has implicit self, to some extent. Consider > >> that > >> Smalltalk and Self are at the same language level. Then, whenever you > >> use > >> nil, true, false, a temp/arg, an iVar or a class/pool/global var, you > >> send > >> that implicitly to self, in both languages :) > > > > To self? If you mean self as in the receiver of the message (which is > > what I mean), then I disagree. > > Right, didn't mean that. > > > In Smalltalk, when the compiler sees a > > use or an assignment of an iVar then he generates a push opcode that > > accesses the current receiver, > > Sure, that was mentioned in my previous mail. > > > but that's not a message send, that's a > > low level memory access. > > right, after the compiler has done its work. > > > temp/arg variables are located in the > > context object, not the receiver. > > right, the implicit self starts with the context object. > > > And nil, true and false are > > singleton objects. > > sure. nobody claimed they are not singleton, no? > > > I don't see what you mean with this at all. > > Sorry for disturbing you (no offense). I offer to take this offline, if > you like. > > >> In Smalltalk it's the compiler who knows what the receiver(s) of these > >> implicit self messages are, it [the compiler :) ] quickly calculates the > >> intended binding and emits a corresponding bytecode, optimizing away the > >> costly message send. > >> > >> Can you see it? :) > >> > >> In Self the initial non-optimizing compiler doesn't know that quick > >> binding. But the Self runtime optimizing compiler comes to the very same > >> result (binding) as Smalltalk's compiler. > >> > >> It's a matter of view on things :) It'd be easy in Smalltalk to always > >> send (self nil), (self true), (self iVar), etc :) > > > > Sorry, I don't understand this at all. This may be a way of looking > > at it, but I don't see it in the language, nor the blue book > > specifications. > > > > NP. it's as I said, a matter of view. > > /Klaus > > > |
Re: Fear and loathing of the "perlification" of Smalltalk
|
|
In reply to this post by Jason Johnson-5
Jason Johnson a écrit :
> On 9/5/07, nicolas cellier <[hidden email]> wrote: >> I like the idea of the language being more contextual. Mathematical >> language concision come from such feature. Put in another context, a >> mathematical expression meaning can change. > > I think Smalltalk has already shown it chooses readability over math > by being one of the few languages that doesn't make you memorize > evaluation rules for math expressions. And I like this. > > Programming is essentially managing complexity, so the simpler you can > make the language the easier it is to manage the complexity of the > problem you're solving. And if you can find a way to make this simple > language concise as well, then you have a winner. > Yeah, on the other hand, try to do math in spoken language and see how far and fast you go in demonstrations. Mathematical notations is a huge progress to express complex ideas in synthetic form. I'm sure the language changes our way of thinking. Math language is a winner to do math. Could math language really achieve this goal without being contextual? I doubt it. |
Re: Fear and loathing of the "perlification" of Smalltalk
|
|
In reply to this post by Jason Johnson-5
Jason Johnson a écrit :
> On 9/5/07, nicolas cellier <[hidden email]> wrote: >> I like the idea of the language being more contextual. Mathematical >> language concision come from such feature. Put in another context, a >> mathematical expression meaning can change. > > I think Smalltalk has already shown it chooses readability over math > by being one of the few languages that doesn't make you memorize > evaluation rules for math expressions. And I like this. > > Programming is essentially managing complexity, so the simpler you can > make the language the easier it is to manage the complexity of the > problem you're solving. And if you can find a way to make this simple > language concise as well, then you have a winner. > > This is why a Linguists is exactly the person you *don't* want > creating a language: they try to create a language that behaves as > spoken language. But spoken language is about the most complicated > thing you will ever learn. It's so complicated that you can still > learn new "keywords" decades after having "mastered" it. If you learn > a new language you will find the language you spoke your entire life > begins to fail you at times. And spoken language is one of the few > things that you can use for 20+ years, move to another land and speak > a new language and after some time completely lose your previous > language. > > This is absolutely not something you want to be basing a tool for > managing complexity on. And context is one of the things makes spoken > language so incredibly complex and un-masterable (the other is the > fact that it's a moving target, but context exaggerates this and even > drives it to some extent). Think about how many misunderstandings you > personally see happen every day. These come either from context or > from disagreement on what a word or concept means (this case is also a > context). > > Context is opinion. I have something in my head and instead of > expressing it I say "it". Unfortunately the person/people I'm talking > to either has no idea what I mean by "it", or worse they assume I mean > something else and go forward based on this assumption. People who > speak the most clear and cause the least misunderstandings avoid as > much implicit context as they can (interestingly enough, we call this > "speaking clearly"). > However, polymorphism is a mean to achieve some of contextual features of our spoken languages. Verbs (messages) can be understood differently according to the context (the class of the message receiver). And, yes, this is exactly the Context object of Smalltalk. It carries method arguments, self inst vars and their class, and the way your nice Smalltalk sentences will be interpreted... If you think of it, Smalltalk is maybe the programming language closer to our mother one. There is no ambiguity in the VM of course, but as i noted several times in this thread, there are in our distorted minds and in the way we mis-interpret the intent of original programmer... Have you ever used the Debugger to disambiguate some code sometimes? Nicolas |
Re: Fear and loathing of the "perlification" of Smalltalk
|
|
In reply to this post by Nicolas Cellier-3
On 9/6/07, nicolas cellier <[hidden email]> wrote:
> > Yeah, on the other hand, try to do math in spoken language and see how > far and fast you go in demonstrations. > > Mathematical notations is a huge progress to express complex ideas in > synthetic form. I'm sure the language changes our way of thinking. Math > language is a winner to do math. > > Could math language really achieve this goal without being contextual? > I doubt it. Yes, math language is very good at what it does. As you have probably noticed in this list, I very much like Haskell, which is very good for mathematical things and the most concise language there is today (that is, concise, not terse. You can read short Haskell code). But we already had a language that is taking those ideas of math and seeing how far they can go with it. I see no reason to try and cram it into Smalltalk too. Smalltalk went on the other side: make it as simple as possible and see how far we get. I am not against Smalltalk changing. But changes should take us forward (from the perspective of the language), not backward. |
Re: Fear and loathing of the "perlification" of Smalltalk
|
|
In reply to this post by Nicolas Cellier-3
On 9/6/07, nicolas cellier <[hidden email]> wrote:
> > However, polymorphism is a mean to achieve some of contextual features > of our spoken languages. Verbs (messages) can be understood differently > according to the context (the class of the message receiver). Yes, I thought about sending this in a follow up, but since you bring it up: We don't use context in spoken language because we wish to be misunderstood, but rather because it takes too long to make everything explicit over and over. And, yes, this applies to programming languages as well. But how do we manage context in programming? In Haskell the focus is on "purity" and therefor the code that has "side effects" is very loudly and clearly demarcated from the code that doesn't. Likewise, OO very clearly separates contextual concerns. In Smalltalk the language is regular in every case. You manage context by supplying the object that has the context you need at this time. The person reading your method sees you take a collection and add elements to it. Knowing what the type of the collection (i.e. the context) is is not important to know what the method does. Contrast this with languages that make heavy use of context; when you read a statement you can't be sure what it does because the semantics of the language may change depending on what got passed in, what the receiver of the result expects (!!) and even settings in effect when the method was called. Couple this with the OO way of handing context as well and the complexity starts to be untenable. > If you think of it, Smalltalk is maybe the programming language closer > to our mother one. No, because in Smalltalk this incredibly complex thing called context is demarcated away from the very simple rest of the language. Spoken language is vastly more complicated. You have indirect pronouns, contractions, unpredictable verb tenses and the grammar rules may change based on the presence of certain words. > Have you ever used the Debugger to disambiguate some code sometimes? In Smalltalk? No, honestly I don't believe I have since I learned the syntax. It's so simple I can't think of anything that's ambiguous. If the formatting is pour I might have to reformat, but that's it. |
|
|
In reply to this post by Jason Johnson-5
Jason,
Of course, the problem with e-mail lists is that sometimes (often? always?) one's sarcasm is completely and utterly missed. Which, of course, encourages one NOT to employ it. But as hypocrisy is the tribute vice pays to virtue, and let's just say a very large tribute was paid here. >> What's the point of having a context if you don't use it? > > Context means having to keep extra things in your head and it makes > the code more complex. Didn't the Perl experiment teach you anything? > ;) This I was serious about. Why should an object's code need to reference its own context? If it's too hard for YOU to keep track of your object's context, how do you expect CLIENTS to do so? >> self position: (self position + newPos - self center) >> asIntegerPoint. >> versus: >> position: (position + newPos - center) asIntegerPoint >> >> Yes. I see how that's not only clunky and confusing BUT tasteless. Worse >> than combining plaid with stripes. > > Clunky and confusing? It's uniform and obvious for me. An object > always receives a message in every case. No stupid special cases to > remember. But if you don't like Smalltalk there are thousands of > other languages out there to try, no need to torture yourself with > this one you find so ugly. Tim is the one who used the word "tasteless" to describe a situation where one doesn't constantly need to explicitly reference the current context. I found that amusing and ran with it. I think it's clear that the Smalltalk version, with its constant "self"s is very obviously clunkier than the one with the implicit self. (However, I concede that there are other issues, i.e., that it's not as simple as just making the self implicit.) >> Here's another horrid example from the Wiki entry on the abomination >> known as "Self": >> valid: base bottom between: ligature bottom + height And: base >> top / scale factor. >> and here we see the oh-so-elegant improvements ST-80 makes: >> valid := self base bottom between: self ligature bottom + self >> height and: self base top / self scale factor. >> >> Mmmmmm. =Tasteful=! > > You also don't like Self, one of the most important languages for > research of our time? Well, no, I was advocating for a more Self-like approach precisely =because= it is well-respected and more-or-less exactly what I'm talking about. (See, if context is so horrible, Self is an abomination.) I'm sorry; I thought I was sufficiently broad so as not to have my intentions be missed, but there really is no such thing. ===Blake=== |
|
|
In reply to this post by Jason Johnson-5
On Wed, 05 Sep 2007 20:18:02 -0700, Jason Johnson
<[hidden email]> wrote: >> I pretty much always use accessors. Except, uh, in the accessors >> themselves. Heh. But it strikes me as something that should be >> transparent. I don't see any reason why I should have to write accesors >> that do nothing but provide access. > > If it's this behavior you want it's odd that you hate self so much. Let's just nip that idea in the bud. I don't hate myself at all. Well, a necessarily healthy, small amount. >> Well, yeah. Smalltalk is sort of like Democracy.... > > I hope that doesn't mean that gradually the bad ideas win out. :( Ha. Indeed. No, the reference I was drawing was more along the lines of "Smalltalk is the worst language except for all the others that have been tried." |
Re: Fear and loathing of the "perlification" of Smalltalk
|
|
In reply to this post by Blake-5
On 9/7/07, Blake <[hidden email]> wrote:
> > Of course, the problem with e-mail lists is that sometimes (often? > always?) one's sarcasm is completely and utterly missed. Which, of course, > encourages one NOT to employ it. But as hypocrisy is the tribute vice pays > to virtue, and let's just say a very large tribute was paid here. Aha. In text it can be really hard to detect unless you're suggesting something insane like eating children. :) Perhaps you thought you were doing just that here, but with the crazy suggestions lately I don't know what to expect. > This I was serious about. Why should an object's code need to reference > its own context? If it's too hard for YOU to keep track of your object's > context, how do you expect CLIENTS to do so? I'm sorry, I don't understand what you mean by this. Why should an object's code need to reference it's own context? Do you mean "why should it need to explicitly state 'self'"? And by "If it's too hard for YOU too keep track of your object's context" do you mean I should remember if what methods my object/class has? > Tim is the one who used the word "tasteless" to describe a situation > where one doesn't constantly need to explicitly reference the current > context. Hrm, you mean he doesn't like it unless you constantly reference the current context? Is that in this thread somewhere? > I found that amusing and ran with it. I think it's clear that the > Smalltalk version, with its constant "self"s is very obviously clunkier > than the one with the implicit self. Clear to you. To me it's uniform and consistent. Traits I value highly in this world of mediocre to down-right appalling language designs. > Well, no, I was advocating for a more Self-like approach precisely > =because= it is well-respected and more-or-less exactly what I'm talking > about. (See, if context is so horrible, Self is an abomination.) But in self it's uniform, no? In self it's all just slots so accessing a method looks the same as accessing a local variable. In that language I wouldn't expect to use self to call local methods. But Smalltalk is different. So do you prefer the self language? Instead of trying to turn Smalltalk into Self, it might be more rewarding to get a group trying to bring Self back on track. |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |