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

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

>> 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

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

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-35-scientific-pocket-calculator-d1d497ece999

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