From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,c406e0c4a6eb74ed X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news1.google.com!news.glorb.com!border1.nntp.dca.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!feed2.news.rcn.net!rcn!feed3.news.rcn.net!not-for-mail Sender: jsa@rigel.goldenthreadtech.com Newsgroups: comp.lang.ada Subject: Re: ADA Popularity Discussion Request References: <49dc98cf.0408110556.18ae7df@posting.google.com> <6F2Yc.848$8d1.621@newsread2.news.pas.earthlink.net> From: jayessay Organization: Tangible Date: 06 Sep 2004 12:36:32 -0400 Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: DXC=e7>Tf5Nb2?]4RO=>9gG=nU0R]m=BkYWIW:6bU3OT9S9ZoBImG[Uf_IXLjhDjIjS^>Q[g\aJk;3HK^ X-Complaints-To: abuse@rcn.com Xref: g2news1.google.com comp.lang.ada:3387 Date: 2004-09-06T12:36:32-04:00 List-Id: Ole-Hjalmar Kristensen writes: > >>>>> "j" == jayessay writes: > > j> In any application/system of any significance these two go hand in > j> hand. The second is achieved by crafting a constrained narrowly > j> focused domain specific language _within_ Lisp, which allows the > j> programmer to then work at the level of the domain, _both_ > j> syntactically as well as semantically. This is why Lisp macros > j> (please don't confuse with any other kind of macro you've come across > j> before) are such a big deal. > > j> Now, admittedly, creating these is not something your typical code > j> monkey is going to grok. This is one of the big reasons why Lisp will > j> never be as "popular" as something like Java. But then your typical > j> code monkey isn't going to be building your core internal application > j> api either. Once you've built this though, even a code monkey will be > j> a lot more productive and produce much more clean and robust code. > > I do not consider myself a Lisp programmer, but I have programmed > enough Lisp to conclude that you probably are correct that the ability > to create a constrained narrowly focused domain specific language > within Lisp could very well outweigh the advantages of static typing. If you've been there, you know this. Actually, the incremental bottom up development with _continual_ testing of almost every code snippet is a significant advance above static typing. In this sort of development you are typically _extensively testing even partial expressions or single clauses_ (well below the level of a function) and at each increment of accretion testing that until you have a function at which point it is tested. The upshot is you have a stunning level of code path coverage - not just for type checks, but logic checks as well. Since you are not saddled with the typical write-try-to-compile-rewrite-compile-try-to-link-rewrite-... finally try to test something cycle this can be done _extremely_ efficiently and timely. You will catch errors _much faster_ than compile time checking - you are checking the correctness of code paths through most every singl path possible. You don't wait to build tests at the higher levels with input cases which you "hope/believe" will exercise "most" of these paths. This is also why _logic_ errors are also far rarer. > But for the last years I have been mainly working with soft real time, > multi-threaded systems. I am aware of the existence of real-time > garbage collectors, but what about multi-threading? Common Lisp used > to be pretty weak in this respect, has this changed? Multi-threading has actually always been available. All the implementations provide an MP facility modeled on the Lisp Machine's - they are not 100% the same as this is a "industry standard" and not yet in the ANSI standard, but they are very very close. So moving code from one to another is actually very easy. I have used multi-threading in basically all my work for years now and don't even think much of it anymore. In many ways, multi-threading is far simpler and more robust in Common Lisp than most anything else for a variety of reasons. Two big ones: 1) you can build your own tasking model and _embed it within the language_ for the type of tasking you will be using. So your code will be succinct, clean and _natural_. 2) Dynamic variables are simply amazing for reducing the much of the programming complexity of multi-threaded applications to nearly that of single-threaded. As for real-time GC, it depends on what you mean by "soft real time". If this really just means something like "it should run fast" or "I can't have any pauses" or some such, then any good modern generational GC will be more than sufficient. I've only had to tune the GC in a couple of really _huge_ application cases. Generally, such modern GCs will never use up more than a fraction of a _one_ percent of the runtime and will typically out perform manual heap management by quite a bit. If you really mean guaranteed response and runtimes, you may well need to roll your own, use a form of manual management, or maybe this case just isn't a good fit for Common Lisp. There are some bare metal Schemes out there that might work. /Jon -- 'j' - a n t h o n y at romeo/charley/november com