Emmanuel LEVY wrote:
> FWIW, personnaly I learnt _javascript_'s basics in a few hours at
http://www.w3schools.com.
I don't think w3schools is very well regarded by web developers for
detail or accuraccy, but if all one needs is an overview of language
features then it might well do. _javascript_ is hardly rocket science.
(Hardly computer science either.:p) Besides, web programmers main
concern is how JS ties into the swampy ever-shifting morass that is
DOM and CSS, which is completely irrelevant to us.
2551 wrote:
> Incidentally, perhaps as an example of the power of JS itself,
or however Amazon do it, they ended up sending me a recommendation
for a JS book that from the sample chapter and the reviews looks
like just what I need - a 'try it and play along' type book, not a
'listen to me while I preach the gospel' type. I've already spotted
some typos in the sample chapter, so they'll have to be watched out
for, but the content and methodology are what I'm looking for:
>
>
http://www.amazon.com/Modern-_javascript_-Develop-Larry-Ullman/dp/0321812522
I started looking at the TOC, but got no further than "Chapter 4:
Simple Variable [sic!] Types". Confusing "variable" and "value" is
an instant red flag. _javascript_ is a 'dynamic' language; that is,
its variables are untyped. Only run-time values contain any kind of
'type' information. Thus, such descriptions are nonsensical, and not
an encouraging start to clarifying anything as hairy and knotted as
today's mainstream Algol/C-descended languages.
One of the problems, of course, is a lot of programming books are
written by computer geeks whose obvious enthusiasm for
evangelization is not always matched by their actual technical grasp
of the subject, never mind any pedagogical skills. (Been there, done
that. See also: Dunning-Kruger.) An excellent tech reviewer can
often save them from themselves on the first count, and a tireless
editor on the second, but niche market book production often lacks
sufficient awareness and/or resources for that. Alan Kay, for
instance, has talked of the problems of "pop culture programming"
for years. It's a difficult problem to solve.
...
Incidentally, dynamic language variables are a huge pain to explain
correctly, not because they're a hard concept, but because there's
so much bad information already in circulation. (Like many widely
disseminated problems, most likely due to C idiots who think they
know it all. I think the Smalltalk folks may have explained this
stuff well, but as often the way [1] those lessons were ignored
elsewhere.) It's so problematic that I deliberately chose to fluff
it in the Apress book, simply because contradicting that much
wrongness would've almost certainly been far harder on users than
just playing along with it (with quiet caveats for those paying
attention).
What I'd have actually liked to say is something like:
Your program uses values to represent the data you're working
with, and you can attach names to those values so that you can
locate/identify those values again later on. We call these names
"identifiers", for reasons that should be obvious. (Identifiers are
also known as "variables", for reasons that are not.)
Obviously, the term "variable" comes from algebra, but while algebra
may have inspired early computer science it certainly wasn't alone.
And the term becomes completely meaningless in a pointer-less
language that stores all user data on the heap.[2] Incidentally, my
own kiwi language doesn't have "variables" and _never_ uses that
word: instead, it has tags (which retrieve data) and names (which
tell a tag which specific bit of data to retrieve). At a conceptual
level, I think non-programmers find explicit tag substitution easier
to grasp than implicit symbolic name substitution (i.e. variable):
attach a tag containing the name of the pack copy field you want,
generate the artwork, and the tag is replaced by that pack copy.[3]
Honestly, I am such a language/pedagogy nerd. But I love learning
this stuff, especially from users themselves. They never cease to
surprise, humble, and impress. :)
Regards,
has
[1] "It’s a curious thing about our industry: not only do we not
learn from our
mistakes, we also don’t learn from our successes.
" -- Keith Braithwaite
[2] Some interpreters, e.g. AppleScript's, make a special exception
for integers, but that's done purely as an internal optimization and
is totally invisible to users, for whom integers look and behave
just like any other object.
[3] In fact, they were often *too* good at it: they'd quickly intuit
the potential of attaching two or three tags to the same text box,
and were very disappointed when the system failed to insert the
combined content of all of those fields. I often had to redesign
parts of kiwi and kiwi's predecessor just to keep up with them. ;)
|