[Enh][VM] primitiveApplyToFromTo for the heart of the enumeration of collections?
Locked
12345
12345
 
|
"Ramon Leon" <[hidden email]> wrote:
> Types aren't blocking wider adoption, ignorance is. The wider community > is generally ignorant of the benefits of Smalltalk, dynamic typing, > image based development, language aware source control, etc., etc, etc. > Smalltalk doesn't need to come to them, they need to come to > Smalltalk, and they are, slowly but surely, every major language has > been moving closer and closer to Smalltalk for years. > > VM's, refactoring, Object Orientation, IDE's, garbage collection, and > extreme programming are all now common, a sure sign of the direction of > the mainstream. A few more years, and they might catch up to Smalltalk > 72. ;) You know, replace "Smalltalk" with "Lisp" and you'll sound just like Paul Graham :) http://www.paulgraham.com/icad.html Sample quote: If you look at these languages in order, Java, Perl, Python, you notice an interesting pattern. At least, you notice this pattern if you are a Lisp hacker. Each one is progressively more like Lisp. Python copies even features that many Lisp hackers consider to be mistakes. You could translate simple Lisp programs into Python line for line. It's 2002, and programming languages have almost caught up with 1958. frank |
|
|
> You know, replace "Smalltalk" with "Lisp" and you'll sound > just like Paul Graham :) :), no surprise, Lisp was one of Smalltalk inspirations. The two languages are very similar in many respects, I have much respect for Lisp, but I prefer Smalltalk. |
|
|
On Sep 19, 2006, at 5:19 PM, Ramon Leon wrote: > >> You know, replace "Smalltalk" with "Lisp" and you'll sound >> just like Paul Graham :) > > :), no surprise, Lisp was one of Smalltalk inspirations. The two > languages > are very similar in many respects, I have much respect for Lisp, but I > prefer Smalltalk. > > Smalltalk is a more consistent environment whereas Lisp is a more consistent language: Experiments like evolutionary programming done by Hillis crossing over lisp trees with a restricted vocabulary would be quite hard to do in Smalltalk. Yet I prefer my tweakable browsers over a tweakable emacs... Btw., Paul's example for the conciseness of Lisp vs other languages (including Smalltalk) is a but spoiled: ========== As an illustration of what I mean about the relative power of programming languages, consider the following problem. We want to write a function that generates accumulators-- a function that takes a number n, and returns a function that takes another number i and returns n incremented by i. (That's incremented by, not plus. An accumulator has to accumulate.) In Common Lisp this would be (defun foo (n) (lambda (i) (incf n i))) (...) foo: n |s| s := n. ^[:i| s := s+i. ] because although in general lexical variables work, you can't do an assignment to a parameter, so you have to create a new variable s. ========= What we _can_ do, is to define foo within the context of Number: Number >> foo ^[:i | self + i] Shorter, isn't it? ;-) Cheers, Markus |
|
|
> Smalltalk is a more consistent environment whereas Lisp is a more
> consistent language: > Experiments like evolutionary programming done by Hillis crossing > over lisp trees with a restricted vocabulary would be quite hard to > do in Smalltalk. > Yet I prefer my tweakable browsers over a tweakable emacs... Same here, Lisp pays for it's power by not being able to have the tools Smalltalk has. > Btw., Paul's example for the conciseness of Lisp vs other languages > (including Smalltalk) is a but spoiled: > ========== > As an illustration of what I mean about the relative power of > programming languages, consider the following problem. We want to > write a function that generates accumulators-- a function that takes > a number n, and returns a function that takes another number i and > returns n incremented by i. > > (That's incremented by, not plus. An accumulator has to accumulate.) > > In Common Lisp this would be > (defun foo (n) > (lambda (i) (incf n i))) > > (...) > > foo: n > |s| > s := n. > ^[:i| s := s+i. ] > because although in general lexical variables work, you can't do an > assignment to a parameter, so you have to create a new variable s. Or cheat.. foo: n n in: [:it | ^[:i | it := it + i]] |
Re: Strongtalk VM for Squeak
|
|
Ramon Leon wrote:
> Same here, Lisp pays for it's power by not being able to have the tools > Smalltalk has. Not strictly true; I mean, even *java* can have IDEs written for it! For instance, did the Lisp Machines not approach Smalltalky levels of toolness? Tony |
|
|
In reply to this post by Markus Gälli-3
> What we _can_ do, is to define foo within the context of Number: > > Number >> foo > ^[:i | self + i] > > Shorter, isn't it? ;-) > > Cheers, > > Markus But I do like this better. |
|
|
In reply to this post by Tony Garnock-Jones-2
> Ramon Leon wrote:
> > Same here, Lisp pays for it's power by not being able to have the > > tools Smalltalk has. > > Not strictly true; I mean, even *java* can have IDEs written > for it! For instance, did the Lisp Machines not approach > Smalltalky levels of toolness? > > Tony As far as I know, no, it didn't. I recently watched a video of a Lisper showing off the power of Slime, http://common-lisp.net/movies/slime.mov, to see how the other side lives, and frankly, in comparison to Smalltalk, I wasn't impressed. You really have to love working on text files to enjoy Lisp. Lisp seems a very command line oriented language, you just have to remember a bunch of stuff, or refer to the spec. One of Smalltalk's goals is that it's understandable by a single developer. Lisp relishes in the fact that it can't be, have you ever looked at the Common Lisp Hyperspec, Jesus. Java btw, has something for the IDE to navigate, an object model, as does Smalltalk, the environment is based around the fact that a model is forced upon you. Lisp doesn't, it just has expressions, the tools are all based around expressions. There's not much for the tools to do, you can't tell from the code, how something really works, you have to memorize it. You have to know that "if" has delayed evaluation, and is a macro, in Smalltalk, you can simply see it, from the blocks. Smalltalk i.e. less powerful, no macro's, however, is much more suited to tinkering, it has objects, that have behavior, you can play with an object and see what it does, you know where to look for it's behavior, in the object. Lisp allows delayed evaluation to be hidden via macro's, which adds a burden to the programmer, he needs to memorize those forms that delay evaluation, it's not obvious from the code alone. Smalltalk has less of a mental burden, you don't need to memorize these things, they're obvious from the code, and the browsers allow you to poke around in ways that Lisp doesn't. Lisp could have browsers, built on top of CLOS, I think, but CLOS isn't Lisp, it's a DSL on Lisp. CLOS, despite claims to the contrary, is not OO. It has most of the benefits of OO, as well as some that OO doesn't have like multiple dispatch, but a CLOS function doesn't actually belong to the object, there's no receiver. CLOS is really the ultimate procedural mechanism, based around generic functions. You still spend all your time passing around data structures to procedures, not very OO. OO is more than just polymorphism, encapsulation, and inheritance, it's a point of view, and CLOS doesn't share that point of view, it still separates data and procedures. Yes, I'm using my own personal definition of OO, doesn't everyone... ;) Of course, this is all just my point of view, it could all be totally wrong! |
Re: self send inliner (was: [Enh][VM] primitiveApplyToFromTo for the heart of theenumeration of collections?)
|
|
In reply to this post by Avi Bryant
2006/9/18, Jecel Assumpcao Jr <[hidden email]>:
> Avi Bryant wrote: > Has anyone ever played with a simple self-sends inliner? No de- > inlining when debugging, no post-inlining optimization, no attempt to > deal with polymorphism, just inlining monomorphic self-sends... Well, I'm toying around with something even simpler: - Does not uninline when methods are added. So you need to load all your code first and then recompile it. - Can only implement methods that contain no return or the return is the last statement. Do you have a case study? Philippe |
|
|
In reply to this post by Ramon Leon-5
But, this one does not create an accumulator, just an adder.
> -----Original Message----- > From: [hidden email] [mailto:squeak-dev- > [hidden email]] On Behalf Of Ramon Leon > Sent: Tuesday, September 19, 2006 9:47 AM > To: 'The general-purpose Squeak developers list' > Subject: RE: Strongtalk VM for Squeak > > > > What we _can_ do, is to define foo within the context of Number: > > > > Number >> foo > > ^[:i | self + i] > > > > Shorter, isn't it? ;-) > > > > Cheers, > > > > Markus > > But I do like this better. |
Re: Strongtalk VM for Squeak
|
|
In reply to this post by Ramon Leon-5
Ramon Leon wrote:
> As far as I know, no, it didn't. I recently watched a video of a Lisper > showing off the power of Slime, [...] Yes, fair enough. I was referring more to the Lisp Machines, a la Symbolics. It's still command-oriented, in a way, a bit like emacs (which, incidentally, I believe is a good thing, and that Squeak should steal a number of features from emacs), but makes good use of reflection in its programming environment and user interface for quite a rich IDE/UI. http://en.wikipedia.org/wiki/Lisp_machine http://en.wikipedia.org/wiki/Image:Debugger.gif You can see a screencast of the machine in action, too: http://www.lemonodor.com/archives/000103.html The movie itself: http://www.lemonodor.com/archives/misc-gems/lispm.mov.gz Cheers, Tony -- [][][] Tony Garnock-Jones | Mob: +44 (0)7905 974 211 [][] LShift Ltd | Tel: +44 (0)20 7729 7060 [] [] http://www.lshift.net/ | Email: [hidden email] |
|
|
> Yes, fair enough. I was referring more to the Lisp Machines,
> a la Symbolics. It's still command-oriented, in a way, a bit > like emacs (which, incidentally, I believe is a good thing, > and that Squeak should steal a number of features from > emacs), but makes good use of reflection in its programming I don't like the command oriented nature, not being an emacs user, I'm curious what things you think Squeak should steal? > environment and user interface for quite a rich IDE/UI. > > http://en.wikipedia.org/wiki/Lisp_machine > http://en.wikipedia.org/wiki/Image:Debugger.gif > > You can see a screencast of the machine in action, too: > > http://www.lemonodor.com/archives/000103.html > > The movie itself: > > http://www.lemonodor.com/archives/misc-gems/lispm.mov.gz > > Cheers, > Tony Interesting, in some way's that looks more advanced than Slime, doesn't say much for Slime. I like the context menu's, but I don't like the REPL, I'll take a workspace over a REPL any day of the week. |
Re: Strongtalk VM for Squeak
|
|
Ramon Leon wrote:
> I don't like the command oriented nature, not being an emacs user, I'm > curious what things you think Squeak should steal? Basically the decoupling between keybindings (and other UI actions) and commands, and the way commands are normal functions with a little pragma inside them to mark them as to be *made available* through the various UI options: M-x, the menus, mouse clicks, as keybindings, etc etc. > Interesting, in some way's that looks more advanced than Slime, doesn't say > much for Slime. I like the context menu's, but I don't like the REPL, I'll > take a workspace over a REPL any day of the week. I agree. Cheers, Tony |
|
|
> Basically the decoupling between keybindings (and other UI
> actions) and commands, and the way commands are normal > functions with a little pragma inside them to mark them as to > be *made available* through the various UI options: M-x, the > menus, mouse clicks, as keybindings, etc etc. > > Cheers, > Tony I've gotten used to keybinder, but yea, that would be nice. |
Re: Strongtalk VM for Squeak
|
|
In reply to this post by Ramon Leon-4
Ramon Leon wrote:
> The addition of manifest types, to a dynamic languages, is a MASSIVE > change, not a marketing issue. True. > StrongTalk is an interesting experiment, mostly for the VM > optimizations, but that's all it is, an experiment, it's not some > production ready proven dialect that's ready for prime time. True, but you're ignoring some information that we do have. People who "get" Smalltalk have considered the type system worth their while to make, even though they knew (and this was novel at the time) that it was not there for performance reasons. So some set of Smalltalkers have considered this an improvement to Smalltalk. I would treat this as a hint that Strongtalk types are not like Java (et al) types, and therefore require separate evaluation based on facts. > Adding types to Smalltalk, is a mistake, and isn't in the spirit of > the language, and frankly, imho, would ruin the language. It's not > something you can just add and move on. You do know the types are optional, right? considering that they are, do you know exactly how they affect programming in it, that you can say they'd ruin the language? > Types aren't blocking wider adoption, ignorance is. The wider > community is generally ignorant of the benefits of Smalltalk, dynamic > typing, image based development, language aware source control, etc., > etc, etc. Smalltalk doesn't need to come to them, they need to come > to Smalltalk, and they are, slowly but surely, every major language > has been moving closer and closer to Smalltalk for years. In the context of the previous discussion, by every "major" language, I presume you mean every popular language. This is generally true, but not strictly so. Another direction in which they are being pulled is the ML kind of typing - mandatory, strong, static, but not (very) verbose. Verbosity is replaced by type inference. We all know that static verbose types are bad because they cost too much in malleability for what they give in reasoning over programs. Are you sure that *optional*, static, non-verbose types would still not be worth it? (btw, I'm not claiming the Strongtalk type system is such - I have no idea whether it is verbose). > VM's, refactoring, Object Orientation, IDE's, garbage collection, and > extreme programming are all now common, a sure sign of the direction > of the mainstream. A few more years, and they might catch up to > Smalltalk 72. ;) Hmm... > > Another point about typing: would the typing information > > be useful for improving the developer tools (e.g. refactoring > > could be more precise)? > > Yes, and the cost would be much bloated and hard to maintain code, a > net negative result. Do you (or anyone else listening) know the Strongtalk typing system well enough to attest to this or refute it? > I'm sure there's some interesting things to be gleaned from the > StrongTalk VM, I for one hope that the different open advanced VM efforts (Coke, Exupery, Strongtalk) can cross fertilize. > but Squeak, needs to remain Squeak, That was never Squeak's purpose. Squeak needs to replace Squeak with something better. That will never happen if our assumption is that Squeak (or Smalltalk) is any kind of global optimum. > StrongTalk is the wrong direction. Stated, yes. Demonstrated, no. Daniel |
Etoys!? (was: Lisp s. Smalltalk) was: Re: Strongtalk VM for Squeak
|
|
In reply to this post by Michael Latta
On Sep 19, 2006, at 7:15 PM, Michael Latta wrote: > But, this one does not create an accumulator, just an adder. ? Quote of the specification: "As an illustration of what I mean about the relative power of programming languages, consider the following problem. We want to write a function that generates accumulators-- a function that takes a number n, and returns a function that takes another number i and returns n incremented by i. (That's incremented by, not plus. An accumulator has to accumulate.)" Isn't Number>>foo a function taking one argument possibly called n? (And isn't better stored in number, so I could find later on?) And doesn't it return a function which expects one argument i and returns n incremented by i? >>> >>> Number >> foo >>> ^[:i | self + i] >>> Maybe I don't get the difference between incrementing and plus. Do you have an example of a use case which might have been intended by Paul though not explicitly specified - at least not for me? But why discussing the power of Smalltalk, it is Etoys whose expressiveness I find amazing - though they are not (yet?) build with themselves. I think Etoys takes us a long way from REPL to what I call SEDL, the "Select, Evaluate, Display - Loop" --- why should we take the perspective of machines? And though I do like commands, I hate commands out of context. Escape Meta Alt Control Shift is not focusing on humans but on uber-geeks who are proud to have learned lots of commands by heart. Also look at the evolution of interfaces of operating systems - inspired by Smalltalk of course. People (including me) want to recognize and act accordingly - and not to learn things by heart. With classes and class extensions we have a very good way to store commands into their contexts - in Smalltalk, but the question is how we could pass the Deutsch-Limit (named after Peter Deutsch) in Etoys or similar approaches: http://en.wikipedia.org/wiki/Deutsch_Limit The project below has 34 lines of code, including the method headers - and it's starting to get hard to read...could we come up with a visual debugger for Etoys? Alternative categorization schemes to the viewer? And - when will / can Etoyers start to write Etoy-scripts to improve Etoys? <shameless self plug> See an example of an incrementor for numbers with a base from 2 to 10, a cross-summer, an according fractal music generator, and a xylophone all fitting on one page with 34 lines of etoys http://www.squeakland.org/project.jsp?http://www.emergent.de/pub/ smalltalk/squeak/projects/musinum.pr (Press the MIDIPort openMidi button after start) (had to add three lines of Smalltalk to get the internal midi running) <\shameless self plug> Cheers, Markus |
|
|
In reply to this post by Daniel Vainsencher-2
> True, but you're ignoring some information that we do have.
> People who "get" Smalltalk have considered the type system > worth their while to make, even though they knew (and this > was novel at the time) that it was not there for performance > reasons. So some set of Smalltalkers have considered this an > improvement to Smalltalk. I would treat this as a hint that > Strongtalk types are not like Java (et al) types, and > therefore require separate evaluation based on facts. An experiment that hasn't proven itself in the wild yet. As for why add types, Dave Griswold says "One of the biggest among these in my mind was the lack of any kind of type system, which although it makes the language extremely flexible, also means that organizing and understanding large-scale software systems is a lot harder." Maybe this is true, but I don't think so, I haven't found manifest types helpful in this arena, maybe others do. In fact, I'd think unit tests are far more helpful in types, for building large systems. Manifest types force one to write lot's of duplicate code that differs only in the type declarations, of course, them being optional does change that. > You do know the types are optional, right? considering that > they are, do you know exactly how they affect programming in > it, that you can say they'd ruin the language? Yes, I know they're optional, but if they aren't use for optimization, and the dynamically typed code is just as fast... What's the point? They make the code ugly, and less maintainable imho. I don't want to think like the computer, I want the computer to think like me. > In the context of the previous discussion, by every "major" > language, I presume you mean every popular language. This is Yes, I meant popular languages. > generally true, but not strictly so. Another direction in > which they are being pulled is the ML kind of typing - > mandatory, strong, static, but not (very) verbose. > Verbosity is replaced by type inference. We all know that > static verbose types are bad because they cost too much in > malleability for what they give in reasoning over programs. Type inference is cool, I was only dissing manifest types. > Are you sure that *optional*, static, non-verbose types would > still not be worth it? (btw, I'm not claiming the Strongtalk > type system is such - I have no idea whether it is verbose). No, I was only saying manifest types aren't worth it, type inference rocks. > > > Another point about typing: would the typing information > be useful > > > for improving the developer tools (e.g. refactoring could be more > > > precise)? Yes, but type inferencing can do this without making the code ugly and forcing the programmer to help the compiler. > Do you (or anyone else listening) know the Strongtalk typing > system well enough to attest to this or refute it? I don't claim too, but I've look at samples, and don't like it. > I for one hope that the different open advanced VM efforts > (Coke, Exupery, Strongtalk) can cross fertilize. > > but Squeak, needs to remain Squeak, > That was never Squeak's purpose. Squeak needs to replace > Squeak with something better. That will never happen if our > assumption is that Squeak (or Smalltalk) is any kind of > global optimum. One of Squeak's coolest things, is that it's open in a way that a C++ VM wouldn't be, it allows experimentation with the language, look at Croquet, Tweak, Seaside (added continuation), things that "probably" couldn't have been done so easily if squeak had a C++ VM. Seaside still hasn't been ported to all the other dialects of Smalltalk because their VM's don't allow continuations to be easily added, something that was only a few lines of code in Squeak. I'd certainly like to see Squeak take things from this VM, but not just adopt it as a better VM, because it isn't. It might be faster, but faster isn't better. > > StrongTalk is the wrong direction. > Stated, yes. Demonstrated, no. > > Daniel Only my opinion, obviously. |
Re: self send inliner (was: [Enh][VM] primitiveApplyToFromTo for the heart of theenumeration of collections?)
|
|
In reply to this post by Philippe Marschall
On Sep 19, 2006, at 10:14 AM, Philippe Marschall wrote: > 2006/9/18, Jecel Assumpcao Jr <[hidden email]>: >> Avi Bryant wrote: >> Has anyone ever played with a simple self-sends inliner? No de- >> inlining when debugging, no post-inlining optimization, no attempt to >> deal with polymorphism, just inlining monomorphic self-sends... > > Well, I'm toying around with something even simpler: > > - Does not uninline when methods are added. So you need to load all > your code first and then recompile it. > - Can only implement methods that contain no return or the return is > the last statement. > > Do you have a case study? I think the Collection hierarchy would be the right place to start. I was always impressed by how Strongtalk could do things like implement #at: in terms of #at:ifAbsent:. Avi |
Re: Strongtalk VM for Squeak
|
|
In reply to this post by Ramon Leon-5
BTW, I got curious, here's some good stuff:
1. A rough description of the Strongtalk type system: http://www.bracha.org/nwst.html 2. A summary of Gilad Bracha's 2004 position on optional type systems. Very clear. The most interesting statement (the only one I'm not sure I agree with) is roughly: the semantics of the program should not depend on the type system, and the type system should not depend on the type inference system. IOW - one should be free to adopt even lower declaration levels than Hindley-Milner inference requires, if an appropriate inference engine exists. It is at: http://pico.vub.ac.be/~wdmeuter/RDL04/papers/Bracha.pdf#search=%22strongtalk%20type%20%22 Daniel Ramon Leon wrote: >> True, but you're ignoring some information that we do have. >> People who "get" Smalltalk have considered the type system >> worth their while to make, even though they knew (and this >> was novel at the time) that it was not there for performance >> reasons. So some set of Smalltalkers have considered this an >> improvement to Smalltalk. I would treat this as a hint that >> Strongtalk types are not like Java (et al) types, and >> therefore require separate evaluation based on facts. >> > > An experiment that hasn't proven itself in the wild yet. As for why add > types, Dave Griswold says "One of the biggest among these in my mind was the > lack of any kind of type system, which although it makes the language > extremely flexible, also means that organizing and understanding large-scale > software systems is a lot harder." Maybe this is true, but I don't think > so, I haven't found manifest types helpful in this arena, maybe others do. > In fact, I'd think unit tests are far more helpful in types, for building > large systems. Manifest types force one to write lot's of duplicate code > that differs only in the type declarations, of course, them being optional > does change that. > > >> You do know the types are optional, right? considering that >> they are, do you know exactly how they affect programming in >> it, that you can say they'd ruin the language? >> > > Yes, I know they're optional, but if they aren't use for optimization, and > the dynamically typed code is just as fast... What's the point? They make > the code ugly, and less maintainable imho. I don't want to think like the > computer, I want the computer to think like me. > > >> In the context of the previous discussion, by every "major" >> language, I presume you mean every popular language. This is >> > > Yes, I meant popular languages. > > >> generally true, but not strictly so. Another direction in >> which they are being pulled is the ML kind of typing - >> mandatory, strong, static, but not (very) verbose. >> Verbosity is replaced by type inference. We all know that >> static verbose types are bad because they cost too much in >> malleability for what they give in reasoning over programs. >> > > Type inference is cool, I was only dissing manifest types. > > >> Are you sure that *optional*, static, non-verbose types would >> still not be worth it? (btw, I'm not claiming the Strongtalk >> type system is such - I have no idea whether it is verbose). >> > > No, I was only saying manifest types aren't worth it, type inference rocks. > > >>>> Another point about typing: would the typing information >>>> >> be useful >> >>>> for improving the developer tools (e.g. refactoring could be more >>>> precise)? >>>> > > Yes, but type inferencing can do this without making the code ugly and > forcing the programmer to help the compiler. > > >> Do you (or anyone else listening) know the Strongtalk typing >> system well enough to attest to this or refute it? >> > > I don't claim too, but I've look at samples, and don't like it. > > >> I for one hope that the different open advanced VM efforts >> (Coke, Exupery, Strongtalk) can cross fertilize. >> >>> but Squeak, needs to remain Squeak, >>> >> That was never Squeak's purpose. Squeak needs to replace >> Squeak with something better. That will never happen if our >> assumption is that Squeak (or Smalltalk) is any kind of >> global optimum. >> > > One of Squeak's coolest things, is that it's open in a way that a C++ VM > wouldn't be, it allows experimentation with the language, look at Croquet, > Tweak, Seaside (added continuation), things that "probably" couldn't have > been done so easily if squeak had a C++ VM. Seaside still hasn't been > ported to all the other dialects of Smalltalk because their VM's don't allow > continuations to be easily added, something that was only a few lines of > code in Squeak. I'd certainly like to see Squeak take things from this VM, > but not just adopt it as a better VM, because it isn't. It might be faster, > but faster isn't better. > > >>> StrongTalk is the wrong direction. >>> >> Stated, yes. Demonstrated, no. >> >> Daniel >> > > Only my opinion, obviously. > > > |
RE: Etoys!? (was: Lisp s. Smalltalk) was: Re: Strongtalk VM for Squeak
|
|
In reply to this post by Markus Gälli-3
The difference (probably not clearly stated in the text, but understood in
the history of the problem) is that the function in Lisp that is returned will accumulate the values passed in as arguments. So the first call is N+I, the second call is N+i+i2, the third is N+i+i2+i3, and so on where i,i2,i3 are sequential arguments to the same function instance (rather than new functions obtained by new calls to foo). The original thread may have been about eToys. I came in a bit later when it had devolved to Lisp vs. Smalltalk vs. others. I would say however that many Smalltalk programmers use the select, eval, display type operation. I have gone so far as to build a system and code methods in the debugger as they are encountered and DoesNotUnderstand is thrown. It is sort of a stream of conciousness coding practice. I presume there is a method to do anything I want and I decompose that into other fantasy methods until they are so simple as to be clearly coded. But, rather than coding them all up front I code them in context of a real call in the debugger. I do not do al my work this way, but I have done it. Definitely a workflow you can not do in any other language. Michael > -----Original Message----- > From: [hidden email] [mailto:squeak-dev- > [hidden email]] On Behalf Of Markus Gaelli > Sent: Tuesday, September 19, 2006 11:46 AM > To: The general-purpose Squeak developers list > Subject: Etoys!? (was: Lisp s. Smalltalk) was: Re: Strongtalk VM for > Squeak > > > On Sep 19, 2006, at 7:15 PM, Michael Latta wrote: > > > But, this one does not create an accumulator, just an adder. > ? > > Quote of the specification: > > "As an illustration of what I mean about the relative power of > programming languages, consider the following problem. We want to > write a function that generates accumulators-- a function that takes > a number n, and returns a function that takes another number i and > returns n incremented by i. > (That's incremented by, not plus. An accumulator has to accumulate.)" > > Isn't Number>>foo a function taking one argument possibly called n? > (And isn't better stored in number, so I could find later on?) > And doesn't it return a function which expects one argument i and > returns n incremented by i? > > >>> > >>> Number >> foo > >>> ^[:i | self + i] > >>> > > Maybe I don't get the difference between incrementing and plus. Do > you have an example of a use case which might have been intended by > Paul though not explicitly specified - at least not for me? > > But why discussing the power of Smalltalk, it is Etoys whose > expressiveness I find amazing - though they are not (yet?) build with > themselves. > I think Etoys takes us a long way from REPL to what I call SEDL, the > "Select, Evaluate, Display - Loop" --- why should we take the > perspective of machines? > And though I do like commands, I hate commands out of context. Escape > Meta Alt Control Shift is not focusing on humans but on uber-geeks > who are proud to have learned lots of commands by heart. Also look at > the evolution of interfaces of operating systems - inspired by > Smalltalk of course. People (including me) want to recognize and act > accordingly - and not to learn things by heart. > > With classes and class extensions we have a very good way to store > commands into their contexts - in Smalltalk, but the question is how > we could pass the Deutsch-Limit (named after Peter Deutsch) in Etoys > or similar approaches: > http://en.wikipedia.org/wiki/Deutsch_Limit > The project below has 34 lines of code, including the method headers > - and it's starting to get hard to read...could we come up with a > visual debugger for Etoys? Alternative categorization schemes to the > viewer? And - when will / can Etoyers start to write Etoy-scripts to > improve Etoys? > > <shameless self plug> > See an example of an incrementor for numbers with a base from 2 to 10, > a cross-summer, an according fractal music generator, and a xylophone > all fitting on one page with 34 lines of etoys > http://www.squeakland.org/project.jsp?http://www.emergent.de/pub/ > smalltalk/squeak/projects/musinum.pr > (Press the MIDIPort openMidi button after start) > (had to add three lines of Smalltalk to get the internal midi running) > <\shameless self plug> > > Cheers, > > Markus |
|
|
In reply to this post by Avi Bryant
Some quick and dirty real time data points on self sends, obtained during
a session with "typical" 3.8.1a developer activities. Datapoints where taken for (self == thisContext client) sends. Figures reflect the number of methods, *not* the frequency of calls! self callers: 2463 self callees: 2302 either of them: 3413 With a bit more hacking data which reports the class hierarchy distance *) could be obtained. *) between subclass and superclass; example: Array has distance 3 with Collection; self sends within the same class have distance 0. This would reflect self sends which go down or up the hierarchy. Of course the report can tell which methods that are. If you want a report ask me with details. /Klaus On Tue, 19 Sep 2006 21:59:32 +0200, Avi Bryant wrote: > On Sep 19, 2006, at 10:14 AM, Philippe Marschall wrote: >> 2006/9/18, Jecel Assumpcao Jr <[hidden email]>: >>> Avi Bryant wrote: >>> Has anyone ever played with a simple self-sends inliner? No de- >>> inlining when debugging, no post-inlining optimization, no attempt to >>> deal with polymorphism, just inlining monomorphic self-sends... >> >> Well, I'm toying around with something even simpler: >> >> - Does not uninline when methods are added. So you need to load all >> your code first and then recompile it. >> - Can only implement methods that contain no return or the return is >> the last statement. >> >> Do you have a case study? > > I think the Collection hierarchy would be the right place to start. I > was always impressed by how Strongtalk could do things like implement > #at: in terms of #at:ifAbsent:. > > Avi > > |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |