Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!cs.utexas.edu!qt.cs.utexas.edu!yale.edu!cmcl2!kramden.acf.nyu.edu!brnstnd From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein) Newsgroups: comp.lang.perl Subject: Re: Ruminations on the future of Perl Message-ID: <17835.Jun2804.27.1491@kramden.acf.nyu.edu> Date: 28 Jun 91 04:27:14 GMT References: Organization: IR Lines: 23 In article worley@compass.com (Dale Worley) writes: [ on what to do in Son Of Perl ] > In my opinion, Perl's biggest weaknesses are (1) its syntax is > fantastically complex (consider the multiple meanings of / and $), and > (2) it is a collection of features more than a coherent language for > expressing algorithms. Wait a minute. What's wrong with a complicated syntax, and what's wrong with having a grab-bag of features? The first thing I'd do in a rewrite is have the parser produce strictly threaded intermediate code. Then setjmp() and longjmp() would disappear, we could turn the optimizer back on, the intermediate code could easily be compiled into C, and the Perl semantics (though never its syntax :-)) would be much easier to handle. The second thing I'd do is give the program a strong sense of its internal state, so that it could properly (and portably!) checkpoint and restart, pass state to another Perl process even running on a different machine, and allow independent debuggers. Third, I'd add non-preemptive threads. Finally, I'd try to educate Perl's users into understanding when the established tools are more appropriate for the job. ---Dan