Slashdot Mirror

I actually like this piece which makes the argument that it's not a bug, but a feature:

I would argue that the bash security concern is not a bug. It is clearly a feature. Admittedly, a misguided and misimplemented feature, but still a feature. The problem is that it was designed 25 years ago. ...The problem we have is not a bash bug, but is basically similar to the Ariane 5 bug: using a component from an earlier systems out of specifications.

50 Million Potentially Vulnerable to UPnP Flaws - January 2013 Articles and Downloads

###

Multi-Article Document:

Part 1 - Article: 50 Million Potentially Vulnerable to UPnP Flaws
Part 2 - Article: Security Flaws in Universal Plug and Play: Unplug, Don't Play
Part 3 - Router Scan: Universal Plug and Play - Router Security Check
Part 4 - Download: ScanNow for Universal Plug and Play (UPnP) | For Windows
Part 5 - PDF: Whitepaper: Security Flaws in Universal Plug and Play: Unplug, Don't Play.
Part 6 - Article: Millions of devices vulnerable via UPnP
Part 7 - Article and Discussion: 50 Million Potentially Vulnerable To UPnP Flaws

###

Translate this collection (does not include software download(s) and PDF(s): http://translate.google.com/

###

COPYRIGHT: The New Zealand Copyright Act 1994 specifies certain circumstances where all or a substantial part of a copyright work may be used
without the copyright owner's permission. A "fair dealing" with copyright material does not infringe copyright if it is for the following
purposes: research or private study; criticism or review; or reporting current events.

###

This Multi-Article Document Has Been Mirrored At The Following Sites (RAW = text):

http://hpaste.org/81561 (RAW: http://hpaste.org/raw/81561)
http://kpaste.net/66c9a3
http://oxynux.org/pastebin/n3rae9-1874
http://pastebin.com/XHkXHfuF (RAW: http://pastebin.com/raw.php?i=XHkXHfuF)
http://paste.blixt.org/9819498
http://paste.lisp.org/display/135035 (RAW: http://paste.lisp.org/display/135035/raw)
http://paste.yt/p2605.html (RAW: http://paste.yt/P2605.txt)
http://slexy.org/view/s2r3Si2W3C
https://paste.debian.net/230670/
http://www.inetpro.org/pastebin/11699 (RAW: http://www.inetpro.org/pastebin/11699/view/raw)

###

(Part 1): 50 Million Potentially Vulnerable to UPnP Flaws

by Brian Donohue | January 29, 2013, 1:15PM

https://threatpost.com/en_us/blogs/50-million-potentially-vulnerable-upnp-flaws-012913

"In a project that found more than 80 million unique IP addresses responding to Universal Plug and Play (UPnP) discovery requests, researchers at Rapid7 were shocked to find that somewhere between 40 and 50 million of those are vulnerable to at least one of three known attacks.

A Rapid7 white paper enumerated UPnP-exposed systems connected to the Internet and identified the number of vulnerabilities present in common configurations. Researchers found that more than 6,900 product models produced by 1,500 different vendors contained at least one known vulnerability, with 23 million systems housing the same remote code execution flaw.

Between June 1 and Nov. 17, 2012, Rapid7 conducted weekly scans that sent simple service discovery protocUPnPol (SSDP) requests to each routable IPv4 address. In all, 2.2 percent of all public IPv4 addresses responded to the standard UPnP discovery requests. So, 81 million unique IP addresses responded and, upon deeper probing, researchers determined some 17 million further systems exposed the UPnP simple object access protocol (SOAP). This level of exposure was far higher than researchers had expected, according to

50 Million Potentially Vulnerable to UPnP Flaws - January 2013 Articles and Downloads

###

Multi-Article Document:

Part 1 - Article: 50 Million Potentially Vulnerable to UPnP Flaws
Part 2 - Article: Security Flaws in Universal Plug and Play: Unplug, Don't Play
Part 3 - Router Scan: Universal Plug and Play - Router Security Check
Part 4 - Download: ScanNow for Universal Plug and Play (UPnP) | For Windows
Part 5 - PDF: Whitepaper: Security Flaws in Universal Plug and Play: Unplug, Don't Play.
Part 6 - Article: Millions of devices vulnerable via UPnP
Part 7 - Article and Discussion: 50 Million Potentially Vulnerable To UPnP Flaws

###

Translate this collection (does not include software download(s) and PDF(s): http://translate.google.com/

###

COPYRIGHT: The New Zealand Copyright Act 1994 specifies certain circumstances where all or a substantial part of a copyright work may be used
without the copyright owner's permission. A "fair dealing" with copyright material does not infringe copyright if it is for the following
purposes: research or private study; criticism or review; or reporting current events.

###

This Multi-Article Document Has Been Mirrored At The Following Sites (RAW = text):

http://hpaste.org/81561 (RAW: http://hpaste.org/raw/81561)
http://kpaste.net/66c9a3
http://oxynux.org/pastebin/n3rae9-1874
http://pastebin.com/XHkXHfuF (RAW: http://pastebin.com/raw.php?i=XHkXHfuF)
http://paste.blixt.org/9819498
http://paste.lisp.org/display/135035 (RAW: http://paste.lisp.org/display/135035/raw)
http://paste.yt/p2605.html (RAW: http://paste.yt/P2605.txt)
http://slexy.org/view/s2r3Si2W3C
https://paste.debian.net/230670/
http://www.inetpro.org/pastebin/11699 (RAW: http://www.inetpro.org/pastebin/11699/view/raw)

###

(Part 1): 50 Million Potentially Vulnerable to UPnP Flaws

by Brian Donohue | January 29, 2013, 1:15PM

https://threatpost.com/en_us/blogs/50-million-potentially-vulnerable-upnp-flaws-012913

"In a project that found more than 80 million unique IP addresses responding to Universal Plug and Play (UPnP) discovery requests, researchers at Rapid7 were shocked to find that somewhere between 40 and 50 million of those are vulnerable to at least one of three known attacks.

A Rapid7 white paper enumerated UPnP-exposed systems connected to the Internet and identified the number of vulnerabilities present in common configurations. Researchers found that more than 6,900 product models produced by 1,500 different vendors contained at least one known vulnerability, with 23 million systems housing the same remote code execution flaw.

Between June 1 and Nov. 17, 2012, Rapid7 conducted weekly scans that sent simple service discovery protocUPnPol (SSDP) requests to each routable IPv4 address. In all, 2.2 percent of all public IPv4 addresses responded to the standard UPnP discovery requests. So, 81 million unique IP addresses responded and, upon deeper probing, researchers determined some 17 million further systems exposed the UPnP simple object access protocol (SOAP). This level of exposure was far higher than researchers had expected, according to

Not to nit too much, but I am fairly certain (I may have secret inside information OR: planet lisp) that ITA moved to a mixture of SBCL and Clozure CL, with the main scheduling engine running on SBCL.

Of course, Google will probably just fire everyone, rewrite it in Java, and cause the entire airline industry scheduling infrastructure to collapse...

I must say that by far the biggest problem is the lack of standards, reasonable documentation, and software maintenance in combination with ad-hoc languages and implementations. If researchers stopped reinventing the wheel all the time, AI research would be in a much better state than it is now.

I've filed a bug report on this but at this point I'm not even sure its a bug... could be a hardware issue..

If anyone is running Adaptec SCSI 2940 controllers with more than one SCSI hard drive and it works then I'd like to know... if anyone is having problems I'd like to know.

The issue is that I have one 2940 fast narrow card and it won't boot... says there is no O/S. In the same machine... swap that card out to a 2940 fast wide and it boots just fine. Perhaps this is a firmware card issue. I have so far only tested these two cards... I plan to go get a handfull more.

Next issue. With the fast wide all seems 100%. Then I start an rsync from another machine and within seconds I get a kernel panic. There is a bug report here: http://paste.lisp.org/display/49908#1

Is OpenBSD bug report # 5616

I'm not at this point asking anyone to debug this. I want to know if others have a similar setup and it works.

This machine is a Pentium I, with two fast narrow SCSI disks and in this case an AHA 2940 FW card. There is nothing else on the bus.

O/S version was 4.1 and now I can try the new version. Since OpenBSD is such a great O/S I sure would like to get to the bottom of this without wasting people's time. If we have a problem we need to know about it and potentially fix it. If its an isolated issue then I need to know this so I can shelve the hardware if in fact it is flakey hardware.

Note: With that fast wide controller... dd if=/dev/sd1 of=/dev/sd1 bs=2048 will run 100% and never glitch at all. But try that rsync on the system.. kernel panics 100% of the time within seconds.

Lots of people are using Lisp to write programs under Linux/FreeBSD/Mac OS/etc. these days. CLiki is a collection of free/open-source Lisp implementations and programs. A lot of them are hosted at common-lisp.net . The Association of Lisp Users hosts conferences and serves as a center for language advocacy.

PrimeTrader is pretty neat. It's also one of the few Lisp commercial applications out there.

" Common LISP is a very old language

Common Lisp (!) was created by amalgamating several other variations of LISP into an ANSI standard that was ratified in 1994."

This thread is starting to tread into language-war territory, and I don't want to go there, but suffice to say that Common LISP (as described in the 1994 standard) is the descendent of several forms of LISP which stem from roughly the same time period as C and FORTRAN give-or-take 20 years. K&R C is not ANSI C, but we still describe the C language of today (C9X) as being "30 years old". So too, we describe Common LISP as being at least as old as the LISP dialects that were merged and extended to create it in the first place.

And excellent refernce can be found on lisp.org's history page.

"CL has also had [...features...] Throw in [...features...] and you now can now see why many people like it."

That's great. I like it quite a lot myself. If you thought this was some kind of anti-Common LISP rant of mine, you are sorely mistaken! I work for a company that uses Common LISP commercially, and it pays my bills. I was talking about appropriate choice of languages to introduce programmers to certain concepts. For that specific, narrow purpose, I was suggesting that CL was at least not the only choice (and IMHO, not the best choice).

footnote: I do not speak for my company. If my above comments made you think that I do, please disabuse yourself of such notions.

Lisp implements everything as a binary tree.

It does not distinguish between code and data, thus it is easy to write self-modifying code.

It's funnier when I remember to include the link to the second-oldest HLL still in use, which thought of this a long time ago.

Representing code in a structured data form so that languages can have user-extensible syntax and can easily host programs that manipulate other programs as data? Sure, it's not like we haven't had that for nearly FIFTY years now!

By the way, most people who talk about Lisp mean Common Lisp. A useful on-line spec is here.

Consider, for instance, the section on iteration.

By the way, most people who talk about Lisp mean Common Lisp. A useful on-line spec is here.

Consider, for instance, the section on iteration.

It [Ocaml] doesn't force the "functional programming way" on you, like Lisp does

When I get into my evil mindset (usually after a long and frustrating day), I'm tempted to learn (I have a book on Lisp around here somewhere...) one of those rarer languages (ie, lisp, Eiffel, o'caml) , and replace certain mission critical scripts with ones written in them.

Lindows^H^H^H^H^Hspire is an answer to Windows

Both Java and C# have full dynamic code generation... Lisp's dynamic code generation... [is] more limited.

Common Lisp doesn't specify reflection facilities for generated code because it doesn't specify anything about the implementation of the language. The reason C# and Java can offer generated code reflection as part of the language is that their code generation is tied to a single VM bytecode specification. It is also unfair to call it "compiled" code reflection, since the reflection capabilities are defined over VM bytecode. The downside to the Smalltalk approach (Smalltalk was the first language to integrate the language and implementation in such a way) is exactly the downside of the VMs. With parallel processing coming back in vogue, I suspect that pretty soon we'll be seeing the same idiocy of the 80s (trying to squeeze parallelism out of 'for' loops in C, trying to make a parallel Fortran) repeated in a mountain of research on parallelising stack-based virtual machines. Guy Steele added 3 primitive constructs to the specification of Common Lisp to make Connection Machine Lisp, and those ideas are still the best approach for implementing an efficient data-driven parallel language.

Both Java and C# have full dynamic code generation... Lisp's dynamic code generation... [is] more limited.

Common Lisp doesn't specify reflection facilities for generated code because it doesn't specify anything about the implementation of the language. The reason C# and Java can offer generated code reflection as part of the language is that their code generation is tied to a single VM bytecode specification. It is also unfair to call it "compiled" code reflection, since the reflection capabilities are defined over VM bytecode. The downside to the Smalltalk approach (Smalltalk was the first language to integrate the language and implementation in such a way) is exactly the downside of the VMs. With parallel processing coming back in vogue, I suspect that pretty soon we'll be seeing the same idiocy of the 80s (trying to squeeze parallelism out of 'for' loops in C, trying to make a parallel Fortran) repeated in a mountain of research on parallelising stack-based virtual machines. Guy Steele added 3 primitive constructs to the specification of Common Lisp to make Connection Machine Lisp, and those ideas are still the best approach for implementing an efficient data-driven parallel language.

Both Java and C# have full dynamic code generation... Lisp's dynamic code generation... [is] more limited.

Common Lisp doesn't specify reflection facilities for generated code because it doesn't specify anything about the implementation of the language. The reason C# and Java can offer generated code reflection as part of the language is that their code generation is tied to a single VM bytecode specification. It is also unfair to call it "compiled" code reflection, since the reflection capabilities are defined over VM bytecode. The downside to the Smalltalk approach (Smalltalk was the first language to integrate the language and implementation in such a way) is exactly the downside of the VMs. With parallel processing coming back in vogue, I suspect that pretty soon we'll be seeing the same idiocy of the 80s (trying to squeeze parallelism out of 'for' loops in C, trying to make a parallel Fortran) repeated in a mountain of research on parallelising stack-based virtual machines. Guy Steele added 3 primitive constructs to the specification of Common Lisp to make Connection Machine Lisp, and those ideas are still the best approach for implementing an efficient data-driven parallel language.

Both Java and C# have full dynamic code generation... Lisp's dynamic code generation... [is] more limited.

Common Lisp doesn't specify reflection facilities for generated code because it doesn't specify anything about the implementation of the language. The reason C# and Java can offer generated code reflection as part of the language is that their code generation is tied to a single VM bytecode specification. It is also unfair to call it "compiled" code reflection, since the reflection capabilities are defined over VM bytecode. The downside to the Smalltalk approach (Smalltalk was the first language to integrate the language and implementation in such a way) is exactly the downside of the VMs. With parallel processing coming back in vogue, I suspect that pretty soon we'll be seeing the same idiocy of the 80s (trying to squeeze parallelism out of 'for' loops in C, trying to make a parallel Fortran) repeated in a mountain of research on parallelising stack-based virtual machines. Guy Steele added 3 primitive constructs to the specification of Common Lisp to make Connection Machine Lisp, and those ideas are still the best approach for implementing an efficient data-driven parallel language.

As the inventor of LISP writes:

If customary notations are to be used externally, translation programs must be written.

Another reason for the initial acceptance of awkwardnesses in the internal form of LISP is that we still expected to switch to writing programs as M-expressions. The project of defining M-expressions precisely and compiling them or at least translating them into S-expressions was neither finalized nor explicitly abandoned. It just receded into the indefinite future, and a new generation of programmers appeared who preferred internal notation to any FORTRAN-like or ALGOL-like notation that could be devised.

So basically, LISP is the generic format you are talking about. LISP is just bunch of list structures in memory.

To allow humans to interact with it, the lists are often mapped to text. We can arbitrarily choose parenthesis as the list separators, resulting in the familiar lists enclosed by parenthesis.

The intention was to write the front ends you describe, but the authors of LISP found it was just as convenient to write in the generic form so didn't bother.

You don't need to steenkin' strings or any of that other fancy crap. You can make up your own strings (and numbers too!) from lists of lists.

... better alternatives exist such as ML and Haskell ... functional programming ... since Haskell is pure via Monads and has a more powerful type system.

... better alternatives exist such as ML and Haskell ... functional programming ... since Haskell is pure via Monads and has a more powerful type system.

I know Lisp is not the ideal language - its ugly, illegible, and slower than compiled languages

The vast majority of Common Lisp implementations have either a native code or through-C compiler, and at least two (Corman Lisp and SBCL) of them only come with a native code compiler.

Objectively, CMUCL can produce flotaing point code at least 5% faster than GCC on a non-trivial (the "Coyote Gulch" ephemeris calculator) benchmark. Of course, bechmarks are objective and misleading, and your assertion was subjective and misleading, and there's plenty of testimony (from real users writing non-trivial applications, not just some random bums paid off by the Scheme Underground) that Lisp is faster than C++.

Scheme seems like it has lost the intelligent simplicity of Python in favour of clumsy "special character" based syntax,

while Common Lisp has many detractors that don't complain much of details. Is your complaint about Common Lisp based on all Lisp variants? Or is CL especially bad?

Of course, your own assertion that Lisp is ugly and slow is stated authoritatively, even while you admit that you've "not coded a line yet," certainly could give someone the wrong impression.

Lisp is fast, when you add type annotations (optional) to variables and then compile, without it it is not that fast.

take a look at this language comparison, and of course the (flawed, but still not worthless) great shootout. or just google for "optimization" on comp.lang.lisp.

It would be great, if instead, I could hook into the compiler and tell it exactly how it should handle vectors.

Well of course that's what templates are. Yes, their syntax is horrendous but that's what comes of trying to wedge the concept into the existing crannies of C syntax (or when, as Stroustrup remarked to me once, "the ecological niche was already polluted").

If you hanker for a language in which metasyntactic extension is natural, you need Lisp macros (or here and here for a more complex example), Scheme "hygenic" macros or the CLOS MOP.

But if you really want to consider "hooking into the compiler" as you say then you should look at the reflective programming work, the ground work for which was laid down almost 25 years ago by Brian Cantwell Smith and was even implemented, by me and others, back then. Although a lot of work continued in this area that vein pretty much got mined: unless you can think up a completely new control structure there's not a huge amount more you can do with such a system than you could with a normal metasyntactic extension mechanism.

HTH
-d

Programmers will be able to extend he syntax of programming languages,

Again, nothing new.

And also here.

Well... You are technically correct. I am only wondering whether talking about "syntax" in the context of Lisp isn't a little exaggeration. The true power of Lisp seems to be the apparent lack of syntax as we usually understand it and writing parsed trees by hand, to make writing bad code impossible.

and programs will be stored as XML documents so that programmers can represent and process data and meta-data uniformly.

There is no way in hell that would ever happen. Ever.

I agree. What people forget is that you can not win against entropy. By redefining problem in a different way you are not necessarily solving it.

Very true. Let us not forget the Conservation of Cruft Principle.

Does anyone even remember now KISS principal?

I don't think we've met.

> >Programmers will be able to extend the syntax of programming languages,
>Again, nothing new.

And also here.

>>It's a very insightful and thought-provoking read. Is this going to be the next generation of extensible programming?
>No.

I agree. What people forget is that you can not win against entropy. By redefining problem in a different way you are not necessarily solving it. Does anyone even remember now KISS principal?

If I recall correctly,
Fourth-Generation languages was going to be the future of programming back in the early 80's?
(Machine code, Fortran/Basic-type languages and Pascal/C-type languages being the supposed first, second and third generations, IIRC)

Then in the early 90's.. OOP was going to save the world. Not that it hasn't had impact, but it certainly hasn't fundamentally changed things.

And now it's XML that's going to save the programmers, while the old-timers whine that we should all really be using Lisp.

Not that I'm a computer-language conservative myself, but it's worth pointing out that historically, there has been quite a big discrepancy between which languages the Comp-Sci researchers feel everyone should be using, and the ones which actually are used.

Rebooting the computer without knowing why you are rebooting it won't fix it. This is the best thing I've read in a while. Brilliant. :-)

Brilliant, but plagiarized from the AI Koans:

A novice was trying to fix a broken lisp machine by turning the power off and on. Knight, seeing what the student was doing spoke sternly- "You can not fix a machine by just power-cycling it with no understanding of what is going wrong."

Knight turned the machine off and on.

The machine worked.

You can recurse in C of course, but the language really isn't designed to facilitate it...

...where as with LISP everything is supposed to recurse.

Now, leaving aside the fact that recursive algorithms can often as not be extraordinarily inefficient...

...recursion is just plain HARD.

Its not a conventional way of thinking.

We like to make lists, connect the dots, whathaveyou.

I mean, look at how much trouble people have thinking about stacks these days, and thats really just reverse-sequential.

Humans don't like recursion, thats why nobody uses LISP or anything like it.

are not inherently fast or slow - implementations are fast or slow, not languages

can be both dynamic and have good performance

can be cross-platform without swallowing POSIX whole

can have multiple inheritance without damaging your brain

can be object-oriented without being object-obsessed

If you like, you can quit as soon as you understand how static scoping and closures work - at least that way you will avoid the primary mistake in pretty much every recent scripting language.

There is a small risk you will become a SmugLispWeenie by doing this, so be forwarned.

Don't forget the wonders of lexical closures, something offered by any self respecting interpreted language.

And also offered by any self respecting compiled language. Just because C doesn't have 'em doesn't mean nobody else does, you know.

Who do you think keeps Franz and Digitool in business? Hobbyists? I don't think so; they'd be using one of the free implementations. Your "no one in business computing considers using Lisp" comment shows you don't know what you're talking about.

I myself use Scheme in my employment, and it's helped a lot.

Lisp has one of the best object-oriented paradigm implementation, Meta-Object Protocol among languages with both scripting and bytecompiling capabilities.

Scheme has been proved as a good language for GUI and configuration: GIMP, Sawfish, TeXmacs.

OCaml has all the power as Lips, just in syntax conviniect for many Java/C-poisoned brains to read faster. No wonder there are many real-world applications on it.

Haskell... I just love how it demonstrates that OOP is not everything (and even not enough) :)

Sun works for telecom industry - why not consider Erlang?

And don't ignore Mozart - it's multi-paradigm pradigm might be just what we all will thing as the best in 3-5 years.

The list is not complete, of course. And it's inspired by Functional Programming.

My main point here is: each of above languages, would it be in hands of Sun marketed instead of Java (with all that money invested to), would have quality of implementation much better than Java.

In fact, I am impressed how such poorly designed language as Java succeed so far on the market. It wouldn't without so much money behind. And without so many classes written by Sun to compensate the poor design of the core language itself.

Would Sun invest so much efforts and money to FP language then the result would be much better. Because quality is why FP matters.

Then you probably want links like Franz success stories, or perhaps this from ALU. Or Digitool. And of course these are just Common Lisp references; you can surely dig up similar things for other languages as well.

Yeah, you mean meta-object protocol

No really, it's a tree language. If it was MARKUP - i.e. layers of "virtual highlighter pen", it would allow overlapping tags, and wouldn't shoehorn weakly structured data into rigid trees*. As it is, XML corresponds closely to Lisp sexps, but reimplemented badly with shitty redundant syntax.

XHTML is a particularly bad application of XML, because HTML text is intended to be authored by humans, not autogenerated by and for some bloated SAX parser/DOM tacked onto a bloated Java/CLR VM.

People liked HTML before XHTML because it was forgiving. One could forget a few close tags, one could <b>overlap <i>tag<b> runs <i> and the browser would muddle through.

There's no particularly good reason to burden people with maintaining rigid tree structure if it doesn't make sense. One of the major problems I have with people usng XML is is the weeks/months they spend agonising over their Schemas, on the correct way to shorehorn their transient data into pretty trees - for god's sake, people! If you're using tools so inflexible that you can't just change your mind halfway through, maybe it's time you stopped using the buzzword-laden marketware of XML/Java/C++/C# and moved to a more flexible platform, like Perl, let alone Lisp! 90% of the time, the stuff I see could just be a ASCII CSV dump of an array, or just a stream of bytes! At least Lisp sexps don't force you to bother with close tags that redundantly echo the open tags - and they have identical expressivity, since XML is a tree, not a markup, language.

Bring back real Markup languages! The XMLers have lost their way. They're busily reinventing lisp, badly (yet again) - they've just come from the other side (data-side) to all those scripting languages (code-side) that are slowly mutating into Lisp, where data is code and code is data.

* (And yes, I know that you can eventually make most everything look like a very broad tree-structure by placing a virtual root before an arbitrary collection - witness the UNIX filesystem! - but I hope the reader can see that that's not really my point)

If you can't figure out how to sperate your data-access, display, and logic layers in PHP, you are as much a "programmer" as you credit PHP with being a "lanuage". Meaning, not much of one at all.

There are tons of huge sites out there that use php. You can apply standard software engineering design and analysis skills to PHP, including but not limited to UI/Logic separation, profiling, OO, etc.

Web applications are and will never be the ASMs you cookie-cutter CS grads want it to be, so get over yourself and accept that procedural scripting languages can be suitable approaches for even large websites.

And Lisp? Even lisp.org seems to indicate that Lisp can be interpretive in the same manner PHP is, and states that the interpretive nature of Lisp is actually a strength, not a weakness as you contend it is with PHP. I guess you'll have to de-learn Lisp and stop "hacking" in it, huh?

Get your head out of your bum.

Can it really be true that the best tool we have for heavy duty computing is a 25 year old language, or have you found anything better - free or non-free?"

Actually, the the best tool we have for heavy duty computing is a forty-seven year old language which, among other things, handles arbitrary size and arbitrary precision numbers transparently, handles memory allocation automatically, handles recursive functions naturally as a key part of the language. As for efficiency, I can code factorial in three lines (70 bytes) of code, and compute the factorial of 10000 in 2.08 seconds:

Beat that in any language. Note: only core features of the language used, no special libraries, no special constructs. Note also: I didn't declare n as an integer, I didn't have to. I didn't declare n a bignum, I din't have to. The language handles all that sort of detail automatically, and if I wanted the imaginary part of the factorial of 1000 all I'd have to do is ask for (imagpart (fact 1000)). Not only are complex numbers supported in the core language, they're supported transparently too.

People get put off by the fact that LISP looks different and has a slightly different vocabulary from the ALGOL-derived languages they're used to. Once you're over the initial hurdles it's a very natural and extremely powerful language to use.

Before you get too enamoured of Python or Java, perhaps you should check out a really elegant language like Common Lisp, particularly the CLOS bits if you're an OO fan - CLOS is OO done right...

Makes Python look medicore, Java look silly, and C++ look like the spawn of satan (in a bad way).

The really strange thing though, is that CL might have the best object system in the world (CLOS), but it is arguably the language that needs OO least, thanks to lisp macro processing and functional constructs :-)

If you visit iMortalportal.com, you can create a web-based alicebot with your own customized personality. There's a more flexible, though less aesthetically-refined interface to the same content available on Pandorabots.com.

As an added bonus, these sites are powered by my favorite programming language - Lisp, specifically Allegro Common Lisp.

Look forward to the Oddcast powered bots in the near future (now available via Pandorabots' site)

Q: Why use reinvented tools for reinvented tasks?
A: To reinvent the solution!

Makes perfect sense to me. If you are wondering, XML is nothing more than flawed S-expressions and Java is a reinvention of a P-code interpreter. Combine the two and you have more reinvention. All paths lead back to the future...

I personally am a big fan of Lisp, especially Franz's Allegro Common Lisp. The Lisp kernel automatically does handy things like protect against buffer overflows, and allows for debugging and modifying a running program - all of which is optional if you want to get sheer speed out of it.

Pretty handy, shame that so many people think Lisp is too old, ACL is quite modern and highly optimized - Lisp has undergone a lot of maturation over the last 50 years. Take a look at the list of links in my journal and see some of the things people are using Lisp for nowadays (AMD, Sony, Nasa, even Microsoft).

By [at least one logical] definition, a high level language is one that uses constructs which do not map directly to those supported by the hardware on which it is running.

C is considered [by many] to be a low level language because it only uses constructs which are available on the majority of modern hardware platforms. However, C relies heavily on the construct of accessing the heap. On a purely stack-based machine which has no heap (some embedded systems, for example), you would have to emulate a heap in terms of stacks. C would therefore be a high level language on that platform, while Forth, a language based around the use of stacks, would be low level.

Sometimes the situation is reversed ... people design the hardware to match the constructs used by a particular language. This was so in the case of the old Lisp Machines, or Sun's picoJava chips.

Few languages these days are strictly interpreted, as in parsing each line of source code just before executing it. Many are compiled into an intermediate form, sometimes called bytecode. This bytecode, in turn, may or may not be a high level language for a particular machine, depending on how closely its constructs match the underlying hardware ones.

Even in a purely compiled language without an explicit "bytecode" stage, the further the language's constructs are from those of the hardware, the more instructions it will take to process each statement.

In short, there are plenty of high level languages which can compile to native code. But this does not mean they will run as fast as carefully crafted assembly!

Why not just use Common Lisp? It has a lot of users, and it has garbage collection, and macros (like templates done right). It's object oriented, too.

I'm not sure what you're arguing ... that C deserves a gold star? Sure. C deserves a gold star. (Though I'm not happy with C's happy-go-lucky attitude towards program safety.) That C is the most relevant important skill for programmers to have today? No. Definitely not.

Unlike buildings, we shouldn't start from scratch every time we write a new program; we ought to build up and only program the new stuff that's specific to our program and nothing else. C is terrible at that, which is why God gave us Lisp and the wisdom to use it. I have yet to hear anyone make a cogent argument as to why Lisp is inferior to C for general-purpose application coding (not systems-level stuff; e.g., why Excel, Word, Notepad, the calculator, Netscape, etc ought to be coded in C or C++ instead of CL or Scheme). And it's not like I haven't asked.

I can't tell whether you're being sarcastic or whether you really don't know about Common Lisp. Dynamic, strong typing, compilers and interpreters, great IDEs and debuggers, easy runtime modification and incremental compilation, flexible and powerful object system (including multiple-inheritance, multiple-dispatch, method combination... and the ability to modify its behavior), macros that have the full power of the language, etc...

Also see CLiki and The Common Lisp Hyper Spec