First post here ... few days on Squeak ... some questions ....
Locked
1 ...
4567
1 ...
4567
 
|
On Aug 30, 2007, at 2:55 AM, Blake wrote: > On Wed, 29 Aug 2007 02:41:01 -0700, Fabio Filasieno > <[hidden email]> wrote: > >> From a first look at the collection libraries, it seems to me that >> there is a LOT of bloat. Really really a LOT. >> I bet that Ocaml's collections can do the same things with an order >> of magnitude of less of code. > > Easy enough to demonstrate, at least for starters. Show us a > particularly bad example in Squeak and the same thing in OCaml. > Then how you would recommend Smalltalk change. Stephen and his pals > redesigned the whole collection system in traits to demonstrte > their theory. (BTW, anyone know how to turn traits visible in the > browser?) > add: newObject after: oldObject "Add the argument, newObject, as an element of the receiver. Put it in the sequence just succeeding oldObject. Answer newObject." | index | index _ self find: oldObject. self insert: newObject before: index + 1. ^newObject Why ? Why there is a NEED for this ? to save me 2 lines of code ? I would dump it. If the user needs to do that he could write: find then insert. is it ? This is an example of bloat ! We have the virtual address space, right ? Let's add methods at will. Is it ? Or we might add all the permutations of add/find/delete.. in sequences of 2 ... to n, if the previous method is ok. A functional programmer (LISP) don't even have the stack data structure. They use a list. As they are very very concerned of bloat. Maybe this is extreme. And it would't be a bad idea to keep a stack. But this is to render the idea. The general philosophy should be: essentiality. Find the core. And express just that. Which doesn't mean not having rich objects. It just mean more care on what we really need. In OrderedCollection I would dump: addLast: (make Add be addLast) add:after: add:afterIndex: add:before: add:beforeIndex addAll (make addAllLast be AddAll) ... sorry too long to write them all. I wanted to make a list of things to cut in OrderedCollection. But I had to stop to many. And you get the idea. The general idea is that if a method is 4 lines long. 1 line for variable declaration 1 line for return value 2 lines to send 2 messages to self .... on public methods ... Don't you think that this numbers shout at you `I'm bloat !` 50% overhead => the method is not doing anything (declaration and return) and inlining would remove this overhead . 50% just 2 calls to self... It's very very ugly ... In Ocaml there is simply no bloat. Just open their doc. count the methods. There are very few. LISP is even more terse. Then there is the following, which is a bit more subjective. I don't care of traits. I don't care of inheritance, the less the better. It confuses me. I want to pick objects that I need as easily as I pick pasta from the supermarket. Who cares that `tagliatelle` is a similar type of pasta to `fettuccine`. I know when I want `fettuccine`. And I know went I want `tagliatelle`. But this is subjective. Someone might think this quite differently. Fabio |
|
|
In reply to this post by Yoshiki Ohshima
On Aug 30, 2007, at 7:55 AM, Yoshiki Ohshima wrote:
This is absolutely false. Smalltalk-80 lacks the concept of EASY "pipes" (chained functional applications) as it is evident from the difference between (((obj method:param1) method:param2) method:param3) and obj method:param1 | method:param2 | method:param3. Smalltalk does't have EASY chained message sends . To the daily programmers life means: either you do - collect:thenSelect: -> This is a big source of bloat... or: - ((obj collect:...) send: ...) -> well... this is simply ugly and difficult write while prototyping no other way in Smalltalk. Smalltalk is inconsistent too. obj send1 send2 send3. A perfect pipe. Is it ? Too bad that you can do only it sometimes not when you want. You can do it only if the method has no parameters. This is a fact. No opinions. It's inconsistent and easy chained functional applications are missing, and this has dramatic effects on the rest of the language.
I've shown how it's not just a syntax change. It will have a domino effect. It will change dramatically the whole language.
BTW, to the real functional programmer, programming is about function selection and function application. It just happens that the `|` is traditionally used to separate pattern matching. But other characters could be used and have been proposed. To the eyes of a real functional what strikes most is the absence of an easy "function application" (not very precise thou, because smalltalk have objects and messaging)
Putting the pipe will dramatically change the language. It will become more functional, instead for more objective. Objects will have some reasons to stay dumb instead of smart. Long chains will start to appear and will replace the need for complex objects. Economically the users in the long term will search for a `common` protocol to maximize the `get free combined functionality` effect. Each point has examples, historical references and quantitative analysis. It's not just opinions of one guy. Is what all the others are doing (unix, lisp, erlang, haskell, ocaml). I like Smalltalk because the guys who did it got right that programming is for humans. The only a structure similar to a living organism can be able to deal with complexity. But at the same time they, in my humble opinion, they missed that humans - and this is important - think functionally. This is true today, was true in past, and will be true in the future. And smalltalk IS good for functional programming but it needs this fix, if it want's to do the job really well. But the community might say "we don't want that". Or might say "make smalltalk more attractive to functional programmers". Putting the pipe is a HUGE change. It's like saying "Smalltalk is a functional programming language. By the way it's also an object oriented one". On Aug 30, 2007, at 7:55 AM, Yoshiki Ohshima wrote:
I'm writing in a discussion group. I'm not writing to publish a paper. I'll put as many exclamation marks I want, as many question marks I want and USE ALL THE CAPITALIZED WORDS I WANT. Or I mIgHt EvEn WriTe Like ThIs. Joking :-). But I do apologize for my writing skills, and will do better. But my arguments are clear, logical, supported by history references and examples. I'm sure you can do the the hard work of ignoring the capitalized words and exclamation marks as many are doing, and focus a bit more on the message that I'm trying to convey. Fabio Filasieno |
|
|
In reply to this post by Marcel Weiher
But an image can be scaled in a farm of servers. A persistent Smalltalk can
have valuable objects transparently stored in a shareable support. I've implemented in Squeak a *proof of concept* of this idea in a system that can store in a relational database the objects without having to map classes to tables. It uses the same intention that the VM uses to store objects in RAM. It uses the RDBMS as if it where an analogy of the RAM. I based the design on the blue book. The idea is not original Sun has played with something like this for Java. Every instar value you change in an object is made ACIDly. Is slow because the support is slow. Write and read barriers can help a lot. Concurrency also should be managed. But you can make a really big image with this by scaling it as much as PostgreSQL can scale. Cheers, Sebastian Sastre > -----Mensaje original----- > De: [hidden email] > [mailto:[hidden email]] En > nombre de Marcel Weiher > Enviado el: Miércoles, 29 de Agosto de 2007 20:51 > Para: The general-purpose Squeak developers list > Asunto: Re: pipe > > > On Aug 26, 2007, at 3:10 AM, Fabio Filasieno wrote: > > >> Smalltalk is very different - you always can add behaviour > you need > >> to the other object and the application logic is > distributed across > >> the system. > > > > That's not the point, but you are right, Unix and Smalltalk are > > different. > > In regard to the black boxes thing. > > I think a lot of the differences are superficial, but one seems very > deep: Unix's unifying principle is extensional, Smalltalk > intensional. > > That is, Unix gets its power from the fact that everything is > just represented as bytes, and you can pipe those around. > Who cares what they mean? To the refined tastes of us > Smalltalkers that seems barbaric, but it is very powerful in > a very pragmatic sort of way, and gets you extremely loose > coupling and late binding (of things other than the fact that > it's all just bytes). Of course, you lose moving to higher > levels of abstraction, and no, XML doesn't really do it. > > Smalltalk, on the other hand, does really well with modelling > semantics, as objects sending messages, but has a hard time > extending its unifying principle outside the image. Which is > somewhat ironic considering the idea was connecting things > and late, late binding. > > Marcel > > |
|
|
In reply to this post by Blake-5
> versus a single method where optional parameters are noted in some fashion:
> > aMethod [with: aParm1] [and: aParm2] [plus: aParm3] > aParm1 unassigned: defaultParm1. > aParm2 unassigned: defaultParm2. > aParm3 unassigned: defaultParm3. > > Square brackets borrowed from grep to mean "optional parameter" with the > unassigned method of course meaning "if not nil then assign this > value". This line is more understandable. I saw Olabl and the Tk binding for it back in 2000 (Jacques had a Smalltalk-like browser, although it was only for viewing). Since then, the idea is always back in my head... -- Yoshiki |
|
|
In reply to this post by Sebastian Sastre-2
Sebastian, this is a neat idea could you give just a little bit more
detail on how the objects are mapped into the SQL database? I can only guess that you mean that they are somehow chunked into blobs and persisted. ]{evin > > Sebastian Sastre wrote: >> But an image can be scaled in a farm of servers. A persistent >> Smalltalk can >> have valuable objects transparently stored in a shareable support. >> I've implemented in Squeak a *proof of concept* of this idea in a system >> that can store in a relational database the objects without having to >> map >> classes to tables. It uses the same intention that the VM uses to store >> objects in RAM. It uses the RDBMS as if it where an analogy of the >> RAM. I >> based the design on the blue book. The idea is not original Sun has >> played >> with something like this for Java. >> >> Every instar value you change in an object is made ACIDly. Is slow >> because >> the support is slow. Write and read barriers can help a lot. Concurrency >> also should be managed. >> >> But you can make a really big image with this by scaling it as much as >> PostgreSQL can scale. >> >> Cheers, >> >> Sebastian Sastre >> >> >> >>> -----Mensaje original----- >>> De: [hidden email] >>> [mailto:[hidden email]] En nombre de >>> Marcel Weiher >>> Enviado el: Miércoles, 29 de Agosto de 2007 20:51 >>> Para: The general-purpose Squeak developers list >>> Asunto: Re: pipe >>> >>> >>> On Aug 26, 2007, at 3:10 AM, Fabio Filasieno wrote: >>> >>> >>>>> Smalltalk is very different - you always can add behaviour >>> you need >>>>> to the other object and the application logic is >>> distributed across >>>>> the system. >>>>> >>>> That's not the point, but you are right, Unix and Smalltalk are >>>> different. >>>> In regard to the black boxes thing. >>>> >>> I think a lot of the differences are superficial, but one seems very >>> deep: Unix's unifying principle is extensional, Smalltalk intensional. >>> >>> That is, Unix gets its power from the fact that everything is just >>> represented as bytes, and you can pipe those around. Who cares what >>> they mean? To the refined tastes of us Smalltalkers that seems >>> barbaric, but it is very powerful in a very pragmatic sort of way, >>> and gets you extremely loose coupling and late binding (of things >>> other than the fact that it's all just bytes). Of course, you lose >>> moving to higher levels of abstraction, and no, XML doesn't really >>> do it. >>> >>> Smalltalk, on the other hand, does really well with modelling >>> semantics, as objects sending messages, but has a hard time >>> extending its unifying principle outside the image. Which is >>> somewhat ironic considering the idea was connecting things and late, >>> late binding. >>> >>> Marcel >>> >>> >>> >> >> >> >> > > |
|
|
In reply to this post by Fabio Filasieno
Fabio,
> Smalltalk-80 lacks the concept of EASY "pipes" (chained functional applications) > as it is evident from the difference between > > (((obj method:param1) method:param2) method:param3) > and > obj method:param1 | method:param2 | method:param3. > > Smalltalk does't have EASY chained message sends . > > To the daily programmers life means: either you do > - collect:thenSelect: -> This is a big source of bloat... > or: > - ((obj collect:...) send: ...) -> well... this is simply ugly and difficult write while prototyping > > no other way in Smalltalk. > > Smalltalk is inconsistent too. > > obj send1 send2 send3. > > A perfect pipe. Is it ? Too bad that you can do only it sometimes not when you want. > You can do it only if the method has no parameters. > > This is a fact. No opinions. Well, "easy or not" is an opinion. Some have been in this saying discussion that it is not "not easy". And, almost any language with more than one operator precedence levels suffer from the same problem anyway. If that language says multiplication is stronger than addition, an expression like "3 + 4 * 5 + 6" will need parenthesis depending on how you like it to be parsed. Do you like stack languages? > I've shown how it's not just a syntax change. It will have a domino effect. It will change dramatically the whole > language. What people have been asking for you was to show some examples in Squeak where the programmer *avoided* using the collection protocol (select:, collect:, do:, etc.) altogether, just because they didn't want to put some extra parenthesis. So far, your only examples are collect:thenSelect: or fictional one like message1:message2:message1:message2:.... These collection protocol (with an Interval and collect: is almost like the list comprehension) is widely used. Some of the "whileTrue:" and "whileFalse:" calls may be better replaced with these, but I can't tell that today's code in Squeak lacks these functional style code. > BTW, to the real functional programmer, programming is about function selection and function application. > It just happens that the `|` is traditionally used to separate pattern matching. But other characters could be used and > have been proposed. > To the eyes of a real functional what strikes most is the absence of an easy "function application" (not very precise > thou, because smalltalk have objects and messaging) The syntax for a block (an anonymous function) in Smalltalk-80 is more lightweight than Lisp's insistence of requiring "lambda", BTW. > Putting the pipe is a HUGE change. It's like saying "Smalltalk is a functional programming language. By the way it's > also an object oriented one". You know, the claim "Smalltalk is a functional programming language" has been around long time. And, the quintessence of typical functional programming languages is not just chaining functions, I think. It is more about the higher level abstraction with (very) higher order functions. The Smalltalk library misses that aspect, but introducing "pipe" wouldn't solve it. And, again, the word "pipe" definitely sounds like something to do with multi processing. If that was the proposal, I'd be more interested. > But my arguments are clear, logical, supported by history references > and examples. Let us see how many readers agree with this... > I'm sure you can do the the hard work of ignoring the capitalized words and exclamation marks as many are doing, and > focus a bit more on the message that I'm trying to convey. I'm trying. -- Yoshiki |
Re: pipe and system building
|
|
In reply to this post by Fabio Filasieno
On Aug 30, 2007, at 2:57 , Fabio Filasieno wrote:
> On Aug 30, 2007, at 2:55 AM, Blake wrote: > >> On Wed, 29 Aug 2007 02:41:01 -0700, Fabio Filasieno >> <[hidden email]> wrote: >> >>> From a first look at the collection libraries, it seems to me that >>> there is a LOT of bloat. Really really a LOT. >>> I bet that Ocaml's collections can do the same things with an order >>> of magnitude of less of code. >> >> Easy enough to demonstrate, at least for starters. Show us a >> particularly bad example in Squeak and the same thing in OCaml. >> Then how you would recommend Smalltalk change. Stephen and his >> pals redesigned the whole collection system in traits to >> demonstrte their theory. (BTW, anyone know how to turn traits >> visible in the browser?) >> > I'll show the most evident thing > > add: newObject after: oldObject > "Add the argument, newObject, as an element of the receiver. Put > it in > the sequence just succeeding oldObject. Answer newObject." > > | index | > index _ self find: oldObject. > self insert: newObject before: index + 1. > ^newObject > > Why ? Why there is a NEED for this ? to save me 2 lines of code ? No, because when I read foo bar. myColl add: baz after: fump. ^zork I find it infinitely more comprehensible than if I had to figure out what that index arithmetic actually means. Also, it's an incarnation of the Once And Only Once principle. Besides being polymorphic with the LinkedList implementation which does something completely different for obvious reasons. I take Smalltalk's rich collection classes any day over the "lean and mean" collections elsewhere that make you implement all the boring index stuff over and over again. - Bert - PS: Btw, you don't earn too much respect here by insisting on arguing a topic to death. Actually contributing something useful is valued much higher. |
|
|
In reply to this post by Kevin Driedger-3
Yeah Kevin sure I can. I don't know if you're familiar to the way in which
the VM stores the objects in RAM. It does that in a sort of table. So I thought that maybe I can apply the same idea to another than the RAM. That medium can be a RDBMS. The key is to forget completely about mapping. To forget thinking in relationalish. And to be able to gain the industry proved value of RDBMS's without having to think in relationalish. The use of relational algebra and SQL is trivial, the system have (right now) 3 tables 1. object 2. root 3. symbol The object table is in fact that: the table that stores objects (one row per instance). The root and symbol tables are complementary. Symbol is a table that acts as dictionary to translate the object pointers of the classes to readable classes names. Root has 1 row and allows you to solve a kind of chicken-egg kind of problem. The rests is in the table object. It's fields are: 1. objectId. Longint. The object pointer instead of RAM in the DB 2. generation. Int. (not in use right now, needed by a generational GC) 3. marked. Boolean. (not in use right now, needed by a GC) 4. referenceCount. Bigint. Also for GC 5. isFinalizable. Boolean. To now if should send a message #finalize previus GC 6. isImmutable. Boolean. To make possible add security, etc. 7. classPointer. Bigint. The value of objectId that is the class of this instance. 8. classType. Text. The kind of class (normal, variable, bytes, etc) 9. slot. Bytearray. The blob that has serialized the instvars values os this instance That is the basic support. I've stored an image segment of ~180KB in ~6900 rows of this table. The rest is done by the system. I should have a look at it to remember better. The deserialization depends on the kind of class. I've used 1 tagged integers I think (I remember not to change squeak's design for that). Several tests where passing green. This has no one optimization, but I think that glorp is caching something behind the scenes. I've read that write an read barriers are used to optimize this kind of approaches. Also has no garbage collection yet which is not a short run kind of problem because you have the whole disk instead of RAM. I also thought about being possible to take advantage of RDBMS's triggers mechanism to make objects in the disk to send messages to any other object allowing to implement events in persisted objects (I think this is called active persistance). cheers, Sebastian Sastre PS: I can share the development if there is interest on this > -----Mensaje original----- > De: [hidden email] > [mailto:[hidden email]] En > nombre de Kevin Driedger > Enviado el: Jueves, 30 de Agosto de 2007 16:48 > Para: The general-purpose Squeak developers list > Asunto: Re: pipe (scaling image) > > Sebastian, this is a neat idea could you give just a little > bit more detail on how the objects are mapped into the SQL > database? I can only guess that you mean that they are > somehow chunked into blobs and persisted. > > ]{evin > > > > Sebastian Sastre wrote: > >> But an image can be scaled in a farm of servers. A persistent > >> Smalltalk can have valuable objects transparently stored in a > >> shareable support. > >> I've implemented in Squeak a *proof of concept* of this idea in a > >> system that can store in a relational database the objects without > >> having to map classes to tables. It uses the same > intention that the > >> VM uses to store objects in RAM. It uses the RDBMS as if > it where an > >> analogy of the RAM. I based the design on the blue book. > The idea is > >> not original Sun has played with something like this for Java. > >> > >> Every instar value you change in an object is made ACIDly. Is slow > >> because the support is slow. Write and read barriers can > help a lot. > >> Concurrency also should be managed. > >> > >> But you can make a really big image with this by scaling > it as much > >> as PostgreSQL can scale. > >> > >> Cheers, > >> > >> Sebastian Sastre > >> > >> > >> > >>> -----Mensaje original----- > >>> De: [hidden email] > >>> [mailto:[hidden email]] En > nombre de > >>> Marcel Weiher Enviado el: Miércoles, 29 de Agosto de 2007 20:51 > >>> Para: The general-purpose Squeak developers list > >>> Asunto: Re: pipe > >>> > >>> > >>> On Aug 26, 2007, at 3:10 AM, Fabio Filasieno wrote: > >>> > >>> > >>>>> Smalltalk is very different - you always can add > behaviour > >>> you need > >>>>> to the other object and the application logic is > >>> distributed across > >>>>> the system. > >>>>> > >>>> That's not the point, but you are right, Unix and Smalltalk are > >>>> different. > >>>> In regard to the black boxes thing. > >>>> > >>> I think a lot of the differences are superficial, but one > seems very > >>> deep: Unix's unifying principle is extensional, > Smalltalk intensional. > >>> > >>> That is, Unix gets its power from the fact that > everything is just > >>> represented as bytes, and you can pipe those around. Who > cares what > >>> they mean? To the refined tastes of us Smalltalkers that seems > >>> barbaric, but it is very powerful in a very pragmatic > sort of way, > >>> and gets you extremely loose coupling and late binding (of things > >>> other than the fact that it's all just bytes). Of > course, you lose > >>> moving to higher levels of abstraction, and no, XML > doesn't really > >>> do it. > >>> > >>> Smalltalk, on the other hand, does really well with modelling > >>> semantics, as objects sending messages, but has a hard time > >>> extending its unifying principle outside the image. Which is > >>> somewhat ironic considering the idea was connecting > things and late, > >>> late binding. > >>> > >>> Marcel > >>> > >>> > >>> > >> > >> > >> > >> > > > > > > |
|
|
In reply to this post by Fabio Filasieno
On 8/30/07, Fabio Filasieno <[hidden email]> wrote:
> > This is absolutely false. Everything he said was correct. And also, instead of calling it the very confusing "pipes" I think we should call it then "then" operator. That is, it clearly says "do this to completion, *then* do this". > Smalltalk-80 lacks the concept of EASY "pipes" (chained functional > applications) > as it is evident from the difference between > > (((obj method:param1) method:param2) method:param3) > and > obj method:param1 | method:param2 | method:param3. > > Smalltalk does't have EASY chained message sends . To be totally honest here, I have no problem with the first. And it certainly isn't a problem in prototyping because the Squeak browser has things to help you when you need to go back and add parenthesis. > Smalltalk is inconsistent too. > > obj send1 send2 send3. > > A perfect pipe. Is it ? Too bad that you can do only it sometimes not when > you want. > You can do it only if the method has no parameters. That is not remotely inconsistent. It is simplicity in syntax. You have to make choices in how to have your syntax and Smalltalk has the second simplest syntax I have ever seen. > This is a fact. No opinions. Come now! :) > It's inconsistent and easy chained functional applications are missing, and > this has dramatic effects on the rest of the language. Begging your pardon, but while it could certainly be convenient at times... dramatic? > I've shown how it's not just a syntax change. It will have a domino effect. > It will change dramatically the whole language. But you have not shown that. You suggested a new separator and then fantasize about what might happen if we used it. That isn't showing, that's dreaming/hoping. > BTW, to the real functional programmer, programming is about function > selection and function application. > It just happens that the `|` is traditionally used to separate pattern > matching. But other characters could be used and have been proposed. > To the eyes of a real functional what strikes most is the absence of an easy > "function application" (not very precise thou, because smalltalk have > objects and messaging) > > > > > If we think about the magnitude of changes from Smalltalk-72 to > > Smalltalk-76 to Smalltalk-80, I hope the change to the language has > > that kind of magnitude. > > Putting the pipe will dramatically change the language. > It will become more functional, instead for more objective. It already uses many functional constructs. Changing from having to use parenthesis to disambiguate to using a "then" operator for that isn't such a fundamental shift. > Objects will have some reasons to stay dumb instead of smart. > Long chains will start to appear and will replace the need for complex > objects. Well make an image that has your "then" operator and distribute it. Lets see if your predictions come true. Though some how I doubt the thing holding most people back from coming here has been the missing syntactic sugar for all this time. > I like Smalltalk because the guys who did it got right that programming is > for humans. The only a structure similar to a living organism can be able to > deal with complexity. But at the same time they, in my humble opinion, they > missed that humans - and this is important - think functionally. This is > true today, was true in past, and will be true in the future. This is also wrong. Functional programming is by far the minority. It's probably gaining more people then Java, etc., but that doesn't prove much. It's easy to go from 1% to 2% (doubling your size), but 95% to 96% is very hard and has little impact. > Putting the pipe is a HUGE change. It's like saying "Smalltalk is a > functional programming language. By the way it's also an object oriented > one". I just don't see that. But make a special image and prove me wrong. |
|
|
In reply to this post by Fabio Filasieno
Ok, this is getting worse then election year in the states. The sheer
volume of controversial, incorrect and downright nonsensical comments made in this thread is just out of control. On 8/28/07, Fabio Filasieno <[hidden email]> wrote: > > There is a high risk of developing > functions that you don't need. This is on of the main critics OOP. Oh? I did a quick google search and I did see a lot of complaints, though none of them were "developing functions that you don't need". How do you determine this is one of the main criticisms? A link please. > When I was a bit younger I often made this mistake: > > Lets a make a nice apple object. The nice apple must have the `eat` method > of course. An apple that cannot be eaten is rally a terrible apple, is it? > So let's invest some time in our apple `eat` method. But here is the mistake > ... > you are writing code to make pies. You will never eat the apple directly. > You have just spent brain and time budget on something useless: the `eat` > method on the apple object. I bet this is the main reason for code bloat in > OOP and Smalltalk too. Is no one else ever going to use your Apple class? The core classes in Smalltalk/Squeak are there to be general. Not for one application. > Now you can't tell me that : > data select: ... | map: ... | collect: ... > this NOT understandable.... it's only a bit verbose... but since it's > functional it's CLEAR Since it's functional style it's clear? Based on what? Because *you* know it? > Give it time. Functional programming has this amazing property that you can > easily reason about problems, especially when side-effect free. Given your statements on this list I suspect I am much more well versed in functional programming then you are. > I want that in Smalltalk. > I can't do it with parenthesis. It disturbs me. I have to break my thoughts. > I need the pipe. So add it. If anyone else has your problem they may use it too. > And I'm sure that any functional programmer (from ocaml, erlang , haskell, > ... ) would understand what I'm talking about. I use all those languages and I understand function composition. But the problem is you vastly overstate the "pipe" operator. If it's so important to functional programming why is it not even present in: Ocaml [1] (or any ML for that matter), Erlang, Lisp.... actually, come to think of it the only two places I know of that have such an operator is certain Unix shells and Haskell. The fact is it doesn't even play such a large role in Haskell. The function composition operator (the period) is much much more important. [1] http://caml.inria.fr/mantis/view.php?id=2415 |
|
|
In reply to this post by Fabio Filasieno
On 8/29/07, Fabio Filasieno <[hidden email]> wrote:
> > From a first look at the collection libraries, it seems to me that there is > a LOT of bloat. Really really a LOT. > I bet that Ocaml's collections can do the same things with an order of > magnitude of less of code. http://en.wikipedia.org/wiki/Order_of_magnitude That's quite a bold statement, though at least this time it was grounded with "I bet". > and by the way the counter arguments > were a bit mild or close to non-existent. .... So "I disagreed with/didn't understand" is the same as "a bit mild or close to non-existent"? |
|
|
In reply to this post by Fabio Filasieno
On 8/30/07, Fabio Filasieno <[hidden email]> wrote:
> > I'll show the most evident thing > > add: newObject after: oldObject > "Add the argument, newObject, as an element of the receiver. Put it in > the sequence just succeeding oldObject. Answer newObject." > > | index | > index _ self find: oldObject. > self insert: newObject before: index + 1. > ^newObject > > Why ? Why there is a NEED for this ? to save me 2 lines of code ? > > I would dump it. This is your most obvious example? And you're not worried about 2 lines of code but you are concerned about 1 character? This is a pretty handy and clear operator and allows Smalltalk to read more like English. > If the user needs to do that he could write: find then insert. is it ? And what would this code look like exactly? Not C++'s awful iterators I hope. > This is an example of bloat ! Opinion. > A functional programmer (LISP) don't even have the stack data > structure. They use a list. As they are very very concerned of bloat. ????? Surely you must mean Scheme here. Common Lisp is the most bloated unorganized pile of odd and inconsistently named functions I have ever seen. Powerful, but concerned of bloat? Obviously not. > In OrderedCollection I would dump: > addLast: (make Add be addLast) They are the same in the places it makes sense. But it doesn't always, hence the two separate methods. > Don't you think that this numbers shout at you `I'm bloat !` > 50% overhead => the method is not doing anything (declaration and > return) and inlining would remove this overhead . > 50% just 2 calls to self... Small methods *are* Smalltalk. What exactly of Smalltalk do you actually like? The environment? Are you sure you don't just want Haskell/Ocaml/whatever in a Smalltalk-like IDE? Perhaps you should check out the Lisp+Slime combination. > In Ocaml there is simply no bloat. Just open their doc. count the > methods. There are very few. Which means everytime I want to do certain things I have to write specialized methods for it. In Smalltalk most of these have been done in the image already. In most any language I know besides Smalltalk I always have a "utilities" library I build up from all these methods I would otherwise have to keep redefining. > LISP is even more terse. Not sure which Lisp you mean here but: http://www.ffconsultancy.com/languages/ray_tracer/verbosity.html The reason Lisps tend to be terse is because of Macros, but I'm kind of confused how this applies to your point that the libraries should have few methods. Common lisp probably has more methods for collections then Smalltalk, and with odd names. For example, filtering a collection: select:/reject: (Smalltalk), filter (Haskell, Ocaml, Python, etc.), remove-if-not (Common Lisp) > Then there is the following, which is a bit more subjective. > > I don't care of traits. > I don't care of inheritance, the less the better. It confuses me. I really don't see what it *is* that you like of Smalltalk besides perhaps the IDE and the debugger. |
|
|
In reply to this post by Jason Johnson-5
Jason Johnson schrieb:
> > And also, instead of calling it the very confusing "pipes" I think we > should call it then "then" operator. That is, it clearly says "do > this to completion, *then* do this". I agree. I would expect a "pipe" to work like a FIFO queue, like Unix-pipes do. But aCollection select: [...] ;; collect: [...] or ( aCollection select: [...] ) collect: [...] is not a queue; so "then"-Operator might be a better name . - Winfried |
|
|
In reply to this post by Jason Johnson-5
Jason Johnson wrote:
> Ok, this is getting worse then election year in the states. The sheer > volume of controversial, incorrect and downright nonsensical comments > made in this thread is just out of control. Indeed. So stop feeding the troll(s). Cheers, - Andreas |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |