• 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: A date IS a date
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: A date IS a date


  • Subject: Re: A date IS a date
  • From: has <email@hidden>
  • Date: Sun, 10 Feb 2008 21:03:43 +0000

On 10 Feb 2008, at 17:28, Jason Bruce wrote:

Given that the correct choice of attribute or whatever can't be made until runtime, it seems like the design flaw lies in allowing the same English word to compile to different things in different contexts. Seems like it'd be easier to just pass strings around at runtime.

It's probably too slow to pass around strings like that at run time.

There may have been some truth to this at the time AppleScript was created, back in the days of SE30s et-al. Retrieving and parsing application aetes would also have been somewhat relatively time- consuming, as would be figuring out what AppleScript's frequently ambiguous syntax actually means. I also doubt there was the time and/ or engineering resources available to the original AppleScript engineers to develop a sophisticated, optimising virtual machine, even if they'd wanted to. Oh, and don't forget planning for future dialect support either, for which using raw AE codes as a portable exchange format would seem an obvious choice.


I suspect the main factor, however, was none of the engineers at the time realised the problems that these premature compile-time optimisations would cause later on. Remember, these folks were starting out basically from scratch without lots of previous research or 20:20 hindsight to draw on for ideas and guidance, so design decisions such as shifting various resource intensive tasks to the compilation stage probably seemed like a good idea at the time. Designing a new programming language isn't really all that hard. Designing a new programming language without making at least some bad design decisions along the way is quite another matter, however. :p


If you look at Self, http://research.sun.com/self/, you'll see that it does a lot of stuff at compile time to speed up execution times. I'm assuming AppleScript does the same thing.


So do other languages such as ObjC, and don't forget modern VMs such as Java that do just-in-time compilation and the like.

None of these are really comparable to AppleScript, however, in that they generally perform these optimisations in such a way that they don't cause a whole bunch of new problems to crop up inadventently; i.e., they get it right. Mais c'est la vie.

has
--
http://appscript.sourceforge.net
http://rb-appscript.rubyforge.org

_______________________________________________
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
References: 
 >Re: A date IS a date (From: Jason Bruce <email@hidden>)

  • Prev by Date: Re: PHP and Applescript
  • Next by Date: Re: do shell script vs. do script with command
  • Previous by thread: Re: do shell script vs. do script with command
  • Next by thread: Re: AppleScript-Users Digest, Vol 5, Issue 93
  • Index(es):
    • Date
    • Thread