Prof Stef questions
hi, I'm starting out w/ pharo (as my first smalltalk-ish language). am on Windows 7 professional; downloaded 64-bit, pharo 8 64-bit development; then downgraded to pharo 7, 32-bit stable. I went through Prof Stef, and find 1 place of unexpected behavior: Prof Stef/Conditionals: "no surprises, prints 100" 1 < 2 ifTrue: [100] ifFalse: [42]. "i added a, as below, and get an error -- i would've expected a to refer to the block, and to be evaluable later, similar to the just prior example in ProfStef/Block assignation" |a| a := 1 < 2 ifTrue: [:x|x+1] ifFalse: [42]. a value: 20. What am I missing, pls? -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
Hi, I haven't run your code, but I guess that the validation of the number of arguments of the block is failing. The block [ 42 ] is a block with zero arguments, but when you do a value: 20, you are calling it with one argument. So it fails. Happy Coding! Santiago Dandois El dom., 5 ene. 2020 a las 13:08, xap (<xap@router.33mail.com>) escribió:
hi, I'm starting out w/ pharo (as my first smalltalk-ish language). am on Windows 7 professional; downloaded 64-bit, pharo 8 64-bit development; then downgraded to pharo 7, 32-bit stable. I went through Prof Stef, and find 1 place of unexpected behavior:
Prof Stef/Conditionals:
"no surprises, prints 100" 1 < 2 ifTrue: [100] ifFalse: [42].
"i added a, as below, and get an error -- i would've expected a to refer to the block, and to be evaluable later, similar to the just prior example in ProfStef/Block assignation"
|a| a := 1 < 2 ifTrue: [:x|x+1] ifFalse: [42]. a value: 20.
What am I missing, pls?
-- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
On Sun, Jan 5, 2020 at 8:08 AM xap <xap@router.33mail.com> wrote:
hi, I'm starting out w/ pharo (as my first smalltalk-ish language). am on Windows 7 professional; downloaded 64-bit, pharo 8 64-bit development; then downgraded to pharo 7, 32-bit stable. I went through Prof Stef, and find 1 place of unexpected behavior:
Prof Stef/Conditionals:
"no surprises, prints 100" 1 < 2 ifTrue: [100] ifFalse: [42].
"i added a, as below, and get an error -- i would've expected a to refer to the block, and to be evaluable later, similar to the just prior example in ProfStef/Block assignation"
|a| a := 1 < 2 ifTrue: [:x|x+1] ifFalse: [42]. a value: 20.
What am I missing, pls?
It is always a good idea to describe in detail what behaviour you did observe. "get an error" is the same as "it didn't work". It turns out that you are NOT assigning a Block to the temporary variable a. You are *evaluating* one of the two blocks in the #ifTrue:ifFalse: expression. Remember that the arguments to #ifTrue: and #ifFalse: are blocks that will be evaluated if the receiver is the correct Boolean. In this case, before there is a value to assign to a, the #ifTrue: block gets evaluated (since 1 is < 2). But, it is a one argument block and there is no value available for that argument. You should have been given the opportunity to open the debugger when the error occurred, and you would have been able to see the stack and recognize that the error occurred in the execution of the #ifTrue:ifFalse: method. I won't give you the answer at this point, as you should be able to figure it out now. Just remember that the expression essentially looks like aBoolean ifTrue: [anExpression] ifFalse: [anotherExpression]
-- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
It is always a good idea to describe in detail what behaviour you did observe. "get an error" is the same as "it didn't work".
you're correct, and I should know better!
You are *evaluating* one of the two blocks in the #ifTrue:ifFalse: expression
this is clutch; thx for the insight! -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
Your problem has to do with understanding how the 'ifTrue:ifFalse:' message is evaluated. This expression 1 < 2 ifTrue: [100] ifFalse: [42]. evaluates to '100'; it does not evaluate to "a block that will return 100 when evaluated". The blocks that make up the arguments to 'ifTrue:ifFalse:' will be selectively evaluated at run-time, by the receiver of the message, when the receiver makes the determination of which block to evaluate. In your modification, you mistakenly assume that one of the two block arguments will selected and returned verbatim (to be evaluated later in another context), but this is not how it works. When you write 'ifTrue: [:x|x+1]', and the receiver of the message is 'True', then 'True' will attempt to evaluate your block argument. But your block argument requires an argument itself, which is missing -- Hence the error that results. What you want is an "ifTrue:' argument block that will itself evaluate to another block that you can assign to 'a'. The fix is simple: Just enclose it in another set of '[ ]' like so: |a| a := 1 < 2 ifTrue: [ [:x|x+1] ] ifFalse: [42]. a value: 20. And the result will be '21', as intended. -Ted -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
many thx, tbrunz! i (and anybody who follows) much appreciate the thoughtful elucidation -- i did indeed assume that ifTrue: would return its argument as-is. Now that i go spellunking through source I see: ifTrue: alternativeBlock "If the receiver is false (i.e., the condition is false), then the value is the false alternative, which is nil. Otherwise answer the result of evaluating the argument, alternativeBlock. Create an error notification if the receiver is nonBoolean. Execution does not actually reach here because the expression is compiled in-line." -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
You're welcome, xap! One of the "thought exercises" that Stef likes to have Pharo students engage in is to come up with your own design for implementing something like 'or:' in Pharo code. And then, afterwards, to examine how the Boolean class and its two subclasses, True and False, are implemented. Most people are surprised by what they find! Smalltalk is often extremely elegant in its implementation. Sven wrote a nice Medium essay on just this: https://medium.com/concerning-pharo/tiny-yet-so-beautiful-1ef5149c910e (And as the source code you read points out, these are not actually implemented in Pharo source; they're implemented in the virtual machine, at a low level, so they can be highly optimized for good performance.) -t -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
Hmm, just where are these prof stef Gedankenexperiments :-? I didn't see 'em in the syntax tutorial proper. Thx for the tiny-is-beautiful article. I didn't have any moment of satori, but am happy to have found a prolific author (in addition to Richard-evangelist) About not feeling extra-illuminated ... perhaps it comes from my stance that once one lays down the ground rules that everything is an object, and that objects inherit, and get work done by doing it themselves or by delegating it, then, say, much of Boolean's implementation shakes out of that, no? (that's rhetorical) For me the value in the pharo Boolean implementation is notsomuch who passes the buck and who ultimately does what, but the synergy among objects and methods that get all this done. (BTW I'll bet the fait accompli synergy we see in today's source didn't start out that way -- there were likely many prosaic versions along the way to getting there, if not on paper then in somebody's mind. Often I find that process MUCH more valuable than the spit-and-polish of a finished product.) Recursion often has me laugh because it seems "nobody does any work" -- dang near everything is delegated elsewhere, and it's just a few base cases that actually do any heavy lifting. I'm being facetious, of course. To me interconnected object systems are often like that, and multiplied many times over -- any bit of work is delegated here, there, everywhere ... and (for me) this federated work disperses logic and makes it less immediately comprehensible. There's definitely gee-whiz appeal to the synergy of a multitude of objects in a loosely-coupled system, and IMO that appeal is valuable (which echoes the ethos of the tiny/beautiful article), but ... anyway, yeah, part of my reason for this foray into smalltalk is to see how that side lives. TLDR: the above is just my thinking out loud, possibly for a future-me to find; i have no questions; pls ignore :-) -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
On Mon, Jan 6, 2020 at 12:26 PM xap <xap@router.33mail.com> wrote:
Hmm, just where are these prof stef Gedankenexperiments :-? I didn't see 'em in the syntax tutorial proper.
Thx for the tiny-is-beautiful article. I didn't have any moment of satori, but am happy to have found a prolific author (in addition to Richard-evangelist)
About not feeling extra-illuminated ... perhaps it comes from my stance that once one lays down the ground rules that everything is an object, and that objects inherit, and get work done by doing it themselves or by delegating it, then, say, much of Boolean's implementation shakes out of that, no? (that's rhetorical)
For me the value in the pharo Boolean implementation is notsomuch who passes the buck and who ultimately does what, but the synergy among objects and methods that get all this done.
(BTW I'll bet the fait accompli synergy we see in today's source didn't start out that way -- there were likely many prosaic versions along the way to getting there, if not on paper then in somebody's mind. Often I find that process MUCH more valuable than the spit-and-polish of a finished product.)
It is often informative to understand *how* a thing came to be, beyond the "Tada! Here it is."
Recursion often has me laugh because it seems "nobody does any work" -- dang near everything is delegated elsewhere, and it's just a few base cases that actually do any heavy lifting. I'm being facetious, of course.
To me interconnected object systems are often like that, and multiplied many times over -- any bit of work is delegated here, there, everywhere ... and (for me) this federated work disperses logic and makes it less immediately comprehensible.
This is absolutely true and correct. That's why it's crucial that a message send clearly identify the "what" and the method implementation clearly implement the "how". (And that too is recursive!) Many years ago, my wife worked for a life insurance company. No one could look at one department and understand the whole algorithm involved in even just the lifecycle of a new policy. We don't slavishly or dogmatically mimic nature when we design objects, but we do attempt to clearly and cleanly separate responsibilities much as nature does. There are many guidelines, heuristics, and practices we employ to achieve good robust designs. Using analogues to real-world things helps make them familiar and innately understandable.
There's definitely gee-whiz appeal to the synergy of a multitude of objects in a loosely-coupled system, and IMO that appeal is valuable (which echoes the ethos of the tiny/beautiful article), but ... anyway, yeah, part of my reason for this foray into smalltalk is to see how that side lives.
TLDR: the above is just my thinking out loud, possibly for a future-me to find; i have no questions; pls ignore :-)
-- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
I came across a Sanskrit term, "darshan", meaning sight/seeing, used in Hindu theology, that seeing a deity, *and being seen in return*, completes a human sense of self/being. I'm ad libbing here. So thx, Richard, for the nod (and do desist continuing to feed the animals) :-! "We don't slavishly or dogmatically mimic nature when we design objects, but we do attempt to clearly and cleanly separate responsibilities much as nature does. There are many guidelines, heuristics, and practices we employ to achieve good robust designs. Using analogues to real-world things helps make them familiar and innately understandable." ahhh, that reminded me -- in recent video-watching I learn Alan Kay started out (?) w/ a degree in molecular (?) biology. for me that made many things fall into place. (aside: turns out bruce lee was a bona fide philosophy major in college; had me put a lot of HIS quips in context, rather than, shame on me, eyeroll and snort) which is still not to say i hold nature's-way sacrosanct. while kay says in that clip above that one shouldn't subdivide a computer into "something less than a computer" (e.g. not separate data from action) i could make just as emphatic arguments to the contrary: that it's fabulously elegant to represent the world-as-data, who cares it's not "natural", and to have orthogonal actions mutate that into another state. kinda like the functional folk. except for the mutate part :-/ anyway, i'm here to educate myself. what draws me to learn as i can of smalltalk, aside from it being the flagship of the objects-all-the-way weltanschauung, is because I have a toy app that could benefit from a more expressive language. it reads/writes a client-server database, reads/writes sockets to manage open-vpn, reads/writes to external REST apis, edits images, munges text files, fetches/parses web pages, automates chrome to navigate to and interact w/ other sites and web pages, and prolly a few more mundane things i'm forgetting. i wrote it in Excel/VBA for that environment's "non-serious" and for me recreational aspect, no-(explicit)-compile dev cycle, capable-enough language and, mostly, forgiving and excellent ide. smalltalk/pharo is that times 10, plus reduced application code due language facilities, dynamic code generation and loading (possible in vba, but laborious), additional language expressiveness. all of which can be done in, say, javascript but i quail at the lack of typing for programming-in-the-large, I'm yet to find a debug-edit-continue experience a la vba (which is still leagues behind that of smalltalk), and i wouldn't be learning anything new currently that app is structured as a main-like entry point with, subsequently, a few "smart" objects pushing and pulling many other much dumber ones. i hope to be self-aware enough not simply to recast that in smalltalk but it remains to be seen how tractable i am to education :-/ -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
Smalltalk is that times 10,000... (I wrote an entire SMB accounting system, including tracking "perpetual inventory" in Excel/VBA. I was between tech jobs at the time..) So, yeah, it will be an excellent vehicle to recast your "toy app". Yes, Alan Kay did get his Bachelor's in molecular biology, and that informed a lot of his ideas of how software systems should be designed & constructed. For the Gedankenexperiments, they're not in ProfStef. ProfStef is just the "dipping the toes into the water" introduction to Pharo. At the end, it prods you to download & go through "Pharo By Example", which is booklet #1 in a 3-booklet series. (The other two being "Deep into Pharo" and "Enterprise Pharo".) That's very good advice... You'll find it here: http://books.pharo.org/ Note that PBE5 (written as v5 came out) is *not* obsolete at all, but PBE8 is out now in draft form. Look in Section 10.5 in PBE5 for the particular G/E I referred to. You'll also find it in the Pharo MOOC in Week 2, Lession 11, "The Essence of Dispatch". -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
-- http://books.pharo.org/: "Pharo By Example" (PBE), "Deep into Pharo", "Enterprise Pharo". -- PBE5/Section 10.5 for the particular G/E I referred to. You'll also find it in the Pharo MOOC in Week 2, Lession 11, "The Essence of Dispatch" got it, thx! -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
I should have recommended the MOOC as well... I did ProfStef, then PBE5 (in Pharo 6.1), then the MOOC. (I did the MOOC in 6.1 also, downloading and installing the components that come "pre-assembled" in the MOOC image template you can clone in Pharo-Launcher.) Oh, and for your comment about Sven: He's a excellent writer, too! An interesting challenge is to recreate his HP-35 calculator "example" -- mainly because he didn't intend it to be a tutorial, so there's a bit of "fill in the blanks" you'll be challenged with. But it will do a lot to show you how to create native GUI apps and a web app -- of the same thing, allowing you to compare, which is nice. https://medium.com/concerning-pharo/rediscovering-the-ux-of-the-legendary-hp... And it's yet another example of how good a writer Sven is, for the technical & not-tech sides of things. -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
yeesh, this just may take more than the few hours i'd initially penciled in the sven-article i read earlier was on medium, i think. as is this calculator one. both read like medium articles ... and suggest an overarching editorial tone, no? unless all medium authors belong to the strunk-and-white-relaxed-for-the-millennium school of writing or some such ;-) there's a quip attributed u.s. justice brandeis: there is no good writing; only good re-writing. applies as much to slate articles, and to code, as it does to supreme court opinions :-/ quips aside i'm always grateful for structured and graduated presentation, and clean/consistent/elegant writing, so many thx sven, and other authors! -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
participants (4)
-
Richard Sargent -
Santiago Dandois -
tbrunz -
xap