• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag
 

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Javascript for automation quastions
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Javascript for automation quastions


  • Subject: Re: Javascript for automation quastions
  • From: has <email@hidden>
  • Date: Wed, 17 Dec 2014 18:47:13 +0000

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. ;)

 _______________________________________________
Do not post admin requests to the list. They will be ignored.
AppleScript-Users mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
Archives: http://lists.apple.com/archives/applescript-users

This email sent to email@hidden

  • Prev by Date: Re: Javascript for automation quastions
  • Next by Date: Re: Javascript for automation quastions
  • Previous by thread: Re: Javascript for automation quastions
  • Next by thread: Re: Javascript for automation quastions
  • Index(es):
    • Date
    • Thread