There's a pretty interesting blog post by Dave Roberts on why using ASN.1 for binary XML is a bad idea and what Fast Infoset does right and wrong. An amusing thing I learned from one of the user comments is that apparently one of the ASN.1 encoding schemes is XML. You can have lots of fun with that - binary XML encoded in ASN.1 encoded in XML transformed into binary...
Universal Binary Format has been around for a few years now, and it includes everything binary XML would have, but in a cleaner, more well-thought out form, in addition to having an extra higher-level protocol for inter-machine transport and security issues.
That article you linked to is terrible. Rummel's book (where the figures are taken from) should in no way be treated as an authoritative source - if you'd actually read it you'd know that his 62 million was just a guess! If you look at the current population of Russia, at 143 million people by far the largest of the former Soviet states, which has been declining since the mid 80s (the native population has been experiencing a negative growth rate since the early 60s, but from the 50s to the 80s the country's population grew due to immigration from other Soviet states), and the rest of the Soviet Union, which I believe put together will be somewhere between half and three quarters of Russia's, the figure could not possibly be true. The Soviet Union experienced it's greatest population growth spurt in the post-WWII period, when Rummel claims the highest casualty rates! Chalking up deaths from the civil war as genocide further undermines his work - the Whites and the Bolsheviks both knew what they were getting into, and are equally implicated in murder (and let's not forget that a lot of deaths resulted from marauder 3rd party bandit opportunists like the Basmachi). I don't know why the article singles out Don cossacks - most cossacks fought for the Whites during the war and paid for it. As a Latvian, I do think that too many innocent people were killed during and after WWII in the Baltic states, but I also think the Nazi governments and their sympathizers got what they deserved - Latvia was probably second only to Poland in number of concentration camps. It really makes me angry that the leftovers started crawling out of the woodwork now - surprisingly many SS men have managed to hide for the past 60 years, and just a year or two ago some dipshit in Estonia decided to put up a statue honoring the SS.
The most ridiculous statistic is the number of deaths in concentration camps. According to that source, around 20% of people sentenced to Soviet concentration camps perished, with the number given as over 39 million. But that means that almost 200 million people (more than the population of Russia and the next 3 biggest Soviet states combined) would have had to go through concentration camps! And all this in the 30 year span between the mid 30s and the mid 60s!
What the hell is wrong with that. I make some hardware, I put linux on it. I say here's my code, feel free to read it, to tell me what you think might need updating, and feel free to make your own, but my hardware will only run my version of the sofware.
Would you be happy if Microsoft let you read the Windows source code but then strong-armed PC manufacturers into only letting you run the latest version of Windows? Do you think Stallman's idea was to let you look at pretty code all day? Software doesn't do much unless you can run it on a computer, and the FSF seems to be the only organization that actually works to protect this freedom. I certainly hope that GPL version 3 will ban these dirty tricks, make DRM and "trusted computing" unworkable, and kills software patents. If you don't like this, go use BSD.
If by "will be with us forever," you mean that in a decade.NET will leave millions of lines of bug-ridden, festering and unsupportable C# and Visual Basic.Net code, then yes, I agree with you. COBOL has touched every one of us in ways we shouldn't have been touched in, and everyone still remembers PL/1. Visual Basics 5 and less are pretty much in the graveyard already (and I know of some geniuses who decided to use it because they thought it would be the way of the future - so much so for trusting Microsoft to build a lasting product). Java may seem popular and widely used, but this is largely Sun spin; if it happened to just disappear spontaneously, I wouldn't notice a thing, and chances are neither would you. I think you can pretty much put it in the "living dead" category right now. Now C, there's a widely used language with a thriving and active programmer community. C++ even more so. You can't predict what will happen to a programming language in 10 years (much less "forever" - remember that computers as we know them today are barely 60 years old!), although it's tempting to try.
All that thread points out is that you can't get direct access to the video card under X11 without DGA extensions, and then (obviously) only in full-screen mode. SDL isn't going to do magic for you - if whatever it's running on top of doesn't support direct access to the hardware, then SDL won't give you hardware acceleration.
For a dead-simple graphics API, check out TinyPTC, which is unfortunately Windows-only. But the design is absolutely beautiful.
Are you referring to the GPU shader-accelerated version of TinyPTC? The webpage itself states that the current version uses software blitting (and runs on a bunch of platforms) with optional MMX optimizations, which would make TinyPTC as fast as worst-case blitting in SDL. If you want to do hardware accelerated blitting with masking/alpha, I really can't see a better interface than what SDL provides - if you care about performance, call SDL_GetVideoInfo and use whatever mode the video card has acceleration for, and if not just use whatever you want and SDL will handle it in software with MMX optimizations like TinyPTC does in all cases. Sure, there are a few functions in SDL that I never use, but I wouldn't exactly call that poor design. I really am wondering why you think that graphics in SDL are so bad. If you said that about sound, I'd be inclined to agree with you, but when it comes to graphics I think SDL is really well designed, especially considering the alternatives.
Well, thanks to an anonymous poster (see my other post in this thread) it turns out "Jay Patel's" real name is Sanjay Amin. And guess what a little google search turned up:
Turns out that before Sanjay Amin founded abika.com ("an online e-book retailer" according to Wired), he was busy defrauding investors with a perpetual energy source scam! Looks like Sanjay is all done with Entropy Systems (the name of company hawking said scam, founded by him in Youngstown, Ohio in 1994), but he himself is far from done defrauding the general public.
I wrote 110 lines of Common Lisp code that interprets strings like "cat/etc/passwd | sort > foo" and captures any results that sh would normally print to stdout.
Care to share? Or is this an exercise left for the readers?:) (I think something like this that runs on a bunch of Unix Lisp implementations would be pretty useful, and your code could be a good starting point).
On Abika's webpage there's a little link down at the left-bottom that lets you file a complaint against anyone, for any reason. Let everyone know how you feel about Jay Patel (not that it really matters, if you look on Google there's about 500 different Jay Patels out there).
Write some articles for OSopinion.com or other sites that post in article format (same idea as a long message board post, but now it's an actual article you can show as a writing sample). If you're in school, definitely write for the school newspaper (if your school has a CS club with it's own newspaper, even better!). The easiest way to break into a commercial contract is to write a freebie for an on-line publication (print magazines are much harder to get into), and ask them to run it. If they like it, negotiate a contract. That's how I did it, but this was when the the dot com bomb had just exploded and not many people had felt the shock wave yet, so things may have changed a bit now. You won't get paid very much, but you usually have a reasonable choice on what you want to write on. I stopped because I didn't like to do technical writing on a deadline (strange, but when it comes to anything else, that's the only way I can write). Once you're professionaly published and have a good portfolio of works, you can try to break into larger technical writing contracts for documentation, books, etc., but there's a lot of competition there (I've never tried it, so it may not actually be that tough). Always, always remember though, that you have no business writing on subjects you don't know - it's called technical writing for a reason. Some people (and most journalists, and a surprisingly large number of computer book writers - Sams seems to publish any garbage they come across) manage to hack it, but if you really want to do this seriously, always know exactly what you're writing about.
Does anyone have a list or can at least rattle off any other gave development sdks there are for other interpteted languages (besides java). For example does ruby have any? how about lisp?
Before I provide you with useful links, I'm obligated to be a pedantic pain in the ass and point out that:
1. Languages aren't "interpreted." Their implementations may be.
2. There aren't any interpreters for Java - the politically correct term is virtual machines.
3. The information I am about to provide is really off-topic for the original thread (something that greatly annoys me about Slashdot because it happens so often), so please treat it accordingly.
That being said, I know of two such projects in nicely working state for Common Lisp. CL-SDL provides a set of raw wrappings around SDL (and OpenGL from there), a bunch of handy utility functions on top of that, and many examples and demos. I've used it, and it is basically like using SDL in C (so you get the best of both worlds). There is also Kenny Tilton's Cello, which uses his very, very slick constraint engine to drive OpenGL, Imagemagick, and he says he has OpenAL working too (I'm not sure how relevant it is anymore, though - cross-platform audio is definitely a problem compared to video). I haven't used it yet, and it's not specifically targeted at games.
There is Isis, a new dialect of Lisp developed by the pointy-headed researchers at the MIT Media Lab for multimedia. In addition to OpenGL, GLUT, SDL, and X11 bindings, it has audio through ALSA, and comes with video capture utilities, and video and image processing tools, networking stuff, etc. That makes it Linux only though. I've installed it but haven't had time to play around too much, but it seems that it has pretty much anything you'd want!
It [Ocaml] doesn't force the "functional programming way" on you, like Lisp does
I don't know how you can claim that, considering that Ocaml doesn't even have goto.
Re:Languages die for a reason
on
Delphi Renaissance
·
· Score: 2, Insightful
Throughout the years, we've seen many [programming] languages die out. It's a natural progression of technology.
This statement demonstrates not only a supreme ignorance of technological change, but of Darwin's ideas as well. Don't take it personally, though - this attitude is ingrained in most Slashdotters. If you didn't know, "survival of the fittest" and all the associated bullshit was actually an invention of Herbert Spencer, noted opportunist and pseudo-scientist, building on Darwin's idea of evolution (who correctly identified environmental fitness as the only criterion for evolutionary change). Read Stephen Jay Gould's The Lying Stones of Marrakech for an interesting take on the matter.
As far as technology goes, it's been shown time and again that there is no such thing as a deterministic progression of technology. Most technological change is motivated primarily by environmental factors (much like evolution, actually), and most environmental factors are motivated by political and sociological conditions. Several good books on the subject are Albert H. Teich's (ed.) Technology and the Future, and David F. Noble's Forces of Production. Noble makes a convincing argument in favor of re-visiting previously developed and alternative branches of technology, focusing on point-to-point and continuous numerically controlled automatic metalworking machinery as examples. Despite being developed several years later, being more technically complicated and backed by millions of US military dollars, after a decade of modest growth continuous-path N/C machines were still inferior to point-to-point machines in efficiency, and were quickly outsold by point-to-point machines when they were re-introduced to the market in 1960.
Lucky for (good) programmers, judging whether software technology is crap or not comes quite naturally, and such expensive trial-and-error market experiments shouldn't be necessary. As many people have pointed out, by many metrics Delphi is worthwhile technologically, and enables certain productivity advantages. The environmental factor is key here - witness yourself parroting the unfounded assumption that Delphi is somehow an ancient, inferior technology. I don't think you thought this up all by yourself, but rather this seems a more widespread notion in the IT industry. The question to ask is why is this so? I don't have a good answer.
Re:Delphi has always been under-rated
on
Delphi Renaissance
·
· Score: 1
IBM's VisualAge comes in a Smalltalk environment, and it was also popular around the same time as Delphi. It continues to befuddle me to this day what kind of industry-wide marketing dysfunction caused products like Delphi and VisualAge to go from prominent market positions to nowhere in the span of a few years.
Trolls tend to stick together, so it is quite natural that when one of them shows it's head, the rest come crawling out of the woodwork. Take the parent post for example. If you weren't a troll, you'd just ignore it and wait for someone to come along and mod it off-topic, like I was about to do until I saw some of the replies (to be fair, a few ones were actually quite interesting, so all is not lost).
I find the credibility of your posting severely lacking. You claim to have "worked with large Smalltalk and Lisp applications," (care to name any?) yet you say you abandoned Lisp after you "took comparitive programming languages." Assuming a typical US college cirriculum, this would be in your third year of univeristy. The details of your knowledge (or lack thereof) of Lisp also cast serious doubt on your assertions. Besides, if you think that Lisp is so self-evidently inferior, why bother writing page-long articles pointing out how much it sucks? Are you trying to justify this to people who read Slashdot, or (like many trolls) to yourself?
I was some one who spent 2 years learning Lisp, getting really good at it
Last time I checked, the ballpark figure for becoming an expert at doing something was 5 years of full-time occupation. You may not claim to be one (neither can I yet, actually) but you sure flaunt it around like you are.
then discovering that I was 2x to 5x more productive in Perl & C and 20x more productive in PROLOG
Now you're pulling my leg.
which the Lisp zealots sniffed at as an "inferior" by-product of Lisp
So you mean that Lisp trolls cited a domain-specific, search-oriented, Horn-clause logical language whose development was in almost no way influenced by Lisp as a by-product of Lisp, and now you're parroting the fact around? What did I say about trolls sticking together?
The paper you site[sic] is laughable.
Ok, now it's your turn. Give me an example of a programming language study that meets your rigorous standards of scientific objectivity.
The reason I am so anti-Lisp is because I was a Lisp zealot until I took comparitive programming languages.
Isn't this a coincidence: I took a comparative programming language class too! Guess what conclusion I came away with: Lisp is a really well designed language with significant productivity advantages. Guess what languages the class covered: Java, Haskell, and Prolog!
I am probably one of the few Lisp detractors who have written Lisp programs that can verify the correctness of Lisp programs!
Oh, so you must be one of these guys. Except I didn't know any of them were Lisp detractors, or Slashdot trolls for that matter. But if you're not, you must be some kind of hacker genius. After all, if your claim is true, what it took them (a bunch of Ivy-league-schooled PhDs that they are) 15 years to do for an applicative subset of Common Lisp, you did in less than two years for all of Lisp while going to college and working with "large Smalltalk and Lisp applications" at the same time! Dude, post your resume! I know of a few firms looking for some gullible braggards, err, naive geniuses to work long hours for little pay.
I have written "self-modifying" Lisp code.
If you knew Lisp, you'd also know that Lisp functions are immutable.
Dude, I know Lisp better than some of its adherents.
Lisp is not a religious, ideological or other movement, and it has nothing to do with glues either. I think the word you are looking for is "proponents." Personally, anybody who knows less about Lisp tha
To say nothing of commercial software, where none of the languages you mention can even boast a fraction of the number of large, successful systems delivered in Lisp.
I just noticed you mentioned Java. Scratch that comment - it only applies to all but one of the languages you mention. Java has outpaced COBOL in terms of lines of code produced a few years ago (which makes it the most widely used language currently, according to LOC metric anyway). Credit where credit is due.
I recently gave a very well-received talk to a group of software engineers (I may post the slides online if I receive permission from all involved parties) that talked about industry standards and software. The basic premise was that industry standards are just the lowest common denominator, and current industry standards do not work (to which not one person in the room disagreed). The truth is, the standardisation and interoperation you are talking about could have been done more efficiently using the then-existing methods you dismiss. The real reason that companies are trying to center in on "industry standard" technology is the same reason that companies have always adopted technology - to concentrate management control. I've recently read through David F. Noble's Forces of Production, and the parallels between the machine shop labor struggle and current programmer dilemmas have frightened me (the book became a big influence on the content of the aforementioned presentation).
The real reasons management adopted all the cool toys in the 90s is because of the promise of office automation. Today, production and manufacturing is almost invisible in the United States, having been almost fully automated or shipped overseas and out of sight. Management would now like for the same thing to happen to offices. The reason that Microsoft and Visual Basic and other broken technologies were adopted en-masse was because of the promise of reducing office worker salaries and employment, which has been largely realized. Despite the large capital investment and the inferior quality of the products produced with these methods, their mission in opening up the path to programmer deskilling and production offshoring was quite successful. Like the automation of the machine shops in the middle of the 20th century compared to the industrial revolution of the 19th, the office automation of the 90s took place at an extremely accelerated rate. The introduction of the tools actually outpaced current use of more traditional computing technologies, so much so that the lower-skilled and less-educated programmers were paid better and not worse wages for a few years! But now the real objective of this transition is clear: the demands for labor have opened up real excuses for US corporations to import foreign indentured servants and export work off-shore (it's interesting to note that machine shops in the 1950s also complained about a worker shortages despite mass layoffs).
The reasoning you use to dismiss more worker-friendly technologies is actually circular, because the poor interoperability of current software was caused by exactly those standards and methods you cite as being the solution (not unlike the machine shops citing the lack of skilled machinists as a reason to introduce even more automated, labor de-skilling machinery into the factory).
The good news is that this isn't all so bad. Eventually, the institutional momentum of the processes and technology reaches a threshold where these methods work quite well (as can be witnessed by all the cheap goodies we get from China). The same will eventually be true for software, and will actually occur quite soon due to the accelerated rate of change.
Lisp is "elegant"? It has all the elegence of porridge with toenail clippings.
You know, most trolls attribute goatse.cx to the appropriate URL, because they know plagiarism is bad. Give credit where credit is due.
Just because you're not productive in another language isn't out fault. And I've yet to see anyone provide an objective comparison of productivity in LISP vs. other languages.
What is it with all these "out of ignorance" arguments and Slashdot? Does this site purposefully attract people that don't know something and then make them express that fact? Just because you don't know any free Lisp code (obviously you haven't bothered looking, because you're convinced that Lisp sucks because it doesn't have any free code) doesn't actually mean there's no free code. Pull your head out of the sand and have a look at these collections:
This doesn't even touch SourceForge (which hosts another two dozen or so Lisp projects I'm aware of). When you consider how small the Lisp community is compared to the number of Perl hackers (easily in the range of 1000:1), and the number and quality of the code on just those repositories to CPAN, the productivity advantage of Lisp really does seem closer to 50x. According to your argument, all those Perl hackers should not have had any trouble in coming up with an efficient implementation by now. Yet, with less that a dozen regular hackers between them, the CMUCL and SBCL projects have produced compilers that outperform g++. At the very least, the Perl folks should not have had any trouble producing an efficient regular expression library, but here again, Lisp has them beat.
Of course, the above links point to software written in only one dialect of Lisp, Common Lisp. When you consider the software produced in other dialects, like Scheme, NewLisp, LUSH, XLISP, and Isis, the difference becomes even more apparent. To say nothing of commercial software, where none of the languages you mention can even boast a fraction of the number of large, successful systems delivered in Lisp.
Some hate it due to its (((())))-Syntax others like the syntax since it allows quite powerfull macros. I so far havn't seen anybody who likes the syntax for readablility, which just shows that powerfull macros + non-(()) syntax could make everybody happy.
Then you really haven't been looking. I think Lisp syntax is the best you can do with a context-free grammar, period. Delimiters are perfectly clear and not overly verbose. Since everything is wrapped in parentheses, indentation flows naturally (Emacs does it right automatically, 100% of the time - try that with Haskell!) and it's very easy to see what goes where. The fact that you don't have to worry about infix operators means you-can-write-names withoutStupidStudlyCaps or dumb_ass_shift_underscores or |better yet just use delimiters and write anything you want!|. Many people rave about how they're going to do meta-programming with ML or Haskell (because C is not fashionable enough, you know), but mostly it ends up being two-layered (that AST doesn't look too much like what you started with, does it?) overly verbose junk. On top of that, more recent (I don't want to say modern, because that carries a lot of baggage about determinism and progress) languages like Haskell end up being a step backwards from C in terms of syntax (well, all your types have to start with a capital letter, none of your function names can, but your modules have to start with a capital letter, but you'll never confuse them with your types...), and then there's Python and whitespace matters. Add in multiple namespaces, and Common Lisp easily has the most convenient syntax you can find.
Yes, I think it's safe to discount Darcs because it's written in Haskell, because god forbid not every other C or Perl monkey who can't be bothered to read a language specification for a day won't be able to make their random changes on the system while I'm trying to use it. By your logic, CVS should absolutely be the cat's ass because of all the meaningful contributions coming from the large, trained and expert community of C developers. Or not.
NO. IT IS THE LAME ASS COPYRIGHT STEALING IDIOTS THAT CAUSED THIS PROBLEM TO BEGIN WITH.
Yes, because we all know that if everyone stopped pirating media, tomorrow publishers would start charging reasonable prices and compensate the authors with what they deserve, and everything would be all right in the land of capitalism.
Stop deluding yourself. Copyright infringement may not fix anything, but this is because issues like these have nothing to do with copyright infringement and everything to do with publisher control. Media company management has this idea that just because the customer has a record button, he has stopped being right. Since they view media (not without cause) as a living necessity, they use this justification to exert further, blatantly unnecessary and abusive control over it's distribution. It's amusing that you call copyright infringers "COPYRIGHT STEALING IDIOTS," because the only copyright thieves here are the publishing companies.
In 1998-2001, the JPL successfuly flew the Deep Space 1 spacecraft. One of the systems on board was the Remote Agent, a fully autonomous spacecraft control and guidance system. The software was written entirely in Common Lisp, and parts were verified in SPIN (there is an interesting paper written on the verification process, along with an informal account by one of the designers), which yielded the detection of several unforeseen race conditions. The parts that were not verified were thought to be thread-safe, but unfortunately this proved mistaken as a race condition occured in-flight. With the help of the Read-Eval-Print Loop and other Lisp debugging facilities, the bug was tracked down and fixed in less than a day, and Remote Agent went on to win NASA's Software of the Year Award.
Perhaps not surprisingly for anyone who has heard about the management at NASA, C++ was selected for the successors to the Remote Agent on the grounds that it is supposed to be more reliable (this despite the fact that the Remote Agent was originally to be developed in C++, an effort that was abandoned after a year of failure). This caused more than a few people to be upset (including a very personal account by one of the aforementioned designers). Clearly the debugging facilities of Common Lisp are far superior to static systems like C++, something which is very useful in diagnosing unexpected error conditions in spacecraft software (read the first question on p. 3 of the interview to see what pains the JPL staff went through to adapt similar, ad-hoc methods to VxWorks). It's also clear from this interview (question: "How is application programming done for a spacecraft?" Answer:"Much the same as for anything elsesoftware requirements are written, with specifications and test plans, then the software is written and tested, problems are fixed, and eventually its sent off to do its job.") that NASA has in no way tried to adapt formal verification methods for it's software, prefering instead to rely on the "tried and true" (at failing, maybe) poke-and-test development "methods."
Clearly, formal verification methods to eliminate bugs before critical software is deployed, and deployment in a system with advanced debugging facilities is a clear win for spacecraft software, and should be adapted as the standard model of development. Unfortunately, like in many other software development enterprises, inertia keeps outdated, inadequate systems going despite a strong failure correlation rate.
Slashdot Mirror
There's a pretty interesting blog post by Dave Roberts on why using ASN.1 for binary XML is a bad idea and what Fast Infoset does right and wrong. An amusing thing I learned from one of the user comments is that apparently one of the ASN.1 encoding schemes is XML. You can have lots of fun with that - binary XML encoded in ASN.1 encoded in XML transformed into binary...
Universal Binary Format has been around for a few years now, and it includes everything binary XML would have, but in a cleaner, more well-thought out form, in addition to having an extra higher-level protocol for inter-machine transport and security issues.
The most ridiculous statistic is the number of deaths in concentration camps. According to that source, around 20% of people sentenced to Soviet concentration camps perished, with the number given as over 39 million. But that means that almost 200 million people (more than the population of Russia and the next 3 biggest Soviet states combined) would have had to go through concentration camps! And all this in the 30 year span between the mid 30s and the mid 60s!
If by "will be with us forever," you mean that in a decade .NET will leave millions of lines of bug-ridden, festering and unsupportable C# and Visual Basic .Net code, then yes, I agree with you. COBOL has touched every one of us in ways we shouldn't have been touched in, and everyone still remembers PL/1. Visual Basics 5 and less are pretty much in the graveyard already (and I know of some geniuses who decided to use it because they thought it would be the way of the future - so much so for trusting Microsoft to build a lasting product). Java may seem popular and widely used, but this is largely Sun spin; if it happened to just disappear spontaneously, I wouldn't notice a thing, and chances are neither would you. I think you can pretty much put it in the "living dead" category right now. Now C, there's a widely used language with a thriving and active programmer community. C++ even more so. You can't predict what will happen to a programming language in 10 years (much less "forever" - remember that computers as we know them today are barely 60 years old!), although it's tempting to try.
All that thread points out is that you can't get direct access to the video card under X11 without DGA extensions, and then (obviously) only in full-screen mode. SDL isn't going to do magic for you - if whatever it's running on top of doesn't support direct access to the hardware, then SDL won't give you hardware acceleration.
You can still buy Macsyma from Symbolics.
http://www.wired.com/news/print/0,1294,37963,00.ht ml
Turns out that before Sanjay Amin founded abika.com ("an online e-book retailer" according to Wired), he was busy defrauding investors with a perpetual energy source scam! Looks like Sanjay is all done with Entropy Systems (the name of company hawking said scam, founded by him in Youngstown, Ohio in 1994), but he himself is far from done defrauding the general public.
On Abika's webpage there's a little link down at the left-bottom that lets you file a complaint against anyone, for any reason. Let everyone know how you feel about Jay Patel (not that it really matters, if you look on Google there's about 500 different Jay Patels out there).
1. Languages aren't "interpreted." Their implementations may be.
2. There aren't any interpreters for Java - the politically correct term is virtual machines.
3. The information I am about to provide is really off-topic for the original thread (something that greatly annoys me about Slashdot because it happens so often), so please treat it accordingly.
That being said, I know of two such projects in nicely working state for Common Lisp. CL-SDL provides a set of raw wrappings around SDL (and OpenGL from there), a bunch of handy utility functions on top of that, and many examples and demos. I've used it, and it is basically like using SDL in C (so you get the best of both worlds). There is also Kenny Tilton's Cello, which uses his very, very slick constraint engine to drive OpenGL, Imagemagick, and he says he has OpenAL working too (I'm not sure how relevant it is anymore, though - cross-platform audio is definitely a problem compared to video). I haven't used it yet, and it's not specifically targeted at games.
There is Isis, a new dialect of Lisp developed by the pointy-headed researchers at the MIT Media Lab for multimedia. In addition to OpenGL, GLUT, SDL, and X11 bindings, it has audio through ALSA, and comes with video capture utilities, and video and image processing tools, networking stuff, etc. That makes it Linux only though. I've installed it but haven't had time to play around too much, but it seems that it has pretty much anything you'd want!
As far as technology goes, it's been shown time and again that there is no such thing as a deterministic progression of technology. Most technological change is motivated primarily by environmental factors (much like evolution, actually), and most environmental factors are motivated by political and sociological conditions. Several good books on the subject are Albert H. Teich's (ed.) Technology and the Future, and David F. Noble's Forces of Production. Noble makes a convincing argument in favor of re-visiting previously developed and alternative branches of technology, focusing on point-to-point and continuous numerically controlled automatic metalworking machinery as examples. Despite being developed several years later, being more technically complicated and backed by millions of US military dollars, after a decade of modest growth continuous-path N/C machines were still inferior to point-to-point machines in efficiency, and were quickly outsold by point-to-point machines when they were re-introduced to the market in 1960.
Lucky for (good) programmers, judging whether software technology is crap or not comes quite naturally, and such expensive trial-and-error market experiments shouldn't be necessary. As many people have pointed out, by many metrics Delphi is worthwhile technologically, and enables certain productivity advantages. The environmental factor is key here - witness yourself parroting the unfounded assumption that Delphi is somehow an ancient, inferior technology. I don't think you thought this up all by yourself, but rather this seems a more widespread notion in the IT industry. The question to ask is why is this so? I don't have a good answer.
IBM's VisualAge comes in a Smalltalk environment, and it was also popular around the same time as Delphi. It continues to befuddle me to this day what kind of industry-wide marketing dysfunction caused products like Delphi and VisualAge to go from prominent market positions to nowhere in the span of a few years.
Trolls tend to stick together, so it is quite natural that when one of them shows it's head, the rest come crawling out of the woodwork. Take the parent post for example. If you weren't a troll, you'd just ignore it and wait for someone to come along and mod it off-topic, like I was about to do until I saw some of the replies (to be fair, a few ones were actually quite interesting, so all is not lost).
I find the credibility of your posting severely lacking. You claim to have "worked with large Smalltalk and Lisp applications," (care to name any?) yet you say you abandoned Lisp after you "took comparitive programming languages." Assuming a typical US college cirriculum, this would be in your third year of univeristy. The details of your knowledge (or lack thereof) of Lisp also cast serious doubt on your assertions. Besides, if you think that Lisp is so self-evidently inferior, why bother writing page-long articles pointing out how much it sucks? Are you trying to justify this to people who read Slashdot, or (like many trolls) to yourself?
Last time I checked, the ballpark figure for becoming an expert at doing something was 5 years of full-time occupation. You may not claim to be one (neither can I yet, actually) but you sure flaunt it around like you are.
Now you're pulling my leg.
So you mean that Lisp trolls cited a domain-specific, search-oriented, Horn-clause logical language whose development was in almost no way influenced by Lisp as a by-product of Lisp, and now you're parroting the fact around? What did I say about trolls sticking together?
Ok, now it's your turn. Give me an example of a programming language study that meets your rigorous standards of scientific objectivity.
Isn't this a coincidence: I took a comparative programming language class too! Guess what conclusion I came away with: Lisp is a really well designed language with significant productivity advantages. Guess what languages the class covered: Java, Haskell, and Prolog!
Oh, so you must be one of these guys. Except I didn't know any of them were Lisp detractors, or Slashdot trolls for that matter. But if you're not, you must be some kind of hacker genius. After all, if your claim is true, what it took them (a bunch of Ivy-league-schooled PhDs that they are) 15 years to do for an applicative subset of Common Lisp, you did in less than two years for all of Lisp while going to college and working with "large Smalltalk and Lisp applications" at the same time! Dude, post your resume! I know of a few firms looking for some gullible braggards, err, naive geniuses to work long hours for little pay.
If you knew Lisp, you'd also know that Lisp functions are immutable.
Lisp is not a religious, ideological or other movement, and it has nothing to do with glues either. I think the word you are looking for is "proponents." Personally, anybody who knows less about Lisp tha
The real reasons management adopted all the cool toys in the 90s is because of the promise of office automation. Today, production and manufacturing is almost invisible in the United States, having been almost fully automated or shipped overseas and out of sight. Management would now like for the same thing to happen to offices. The reason that Microsoft and Visual Basic and other broken technologies were adopted en-masse was because of the promise of reducing office worker salaries and employment, which has been largely realized. Despite the large capital investment and the inferior quality of the products produced with these methods, their mission in opening up the path to programmer deskilling and production offshoring was quite successful. Like the automation of the machine shops in the middle of the 20th century compared to the industrial revolution of the 19th, the office automation of the 90s took place at an extremely accelerated rate. The introduction of the tools actually outpaced current use of more traditional computing technologies, so much so that the lower-skilled and less-educated programmers were paid better and not worse wages for a few years! But now the real objective of this transition is clear: the demands for labor have opened up real excuses for US corporations to import foreign indentured servants and export work off-shore (it's interesting to note that machine shops in the 1950s also complained about a worker shortages despite mass layoffs).
The reasoning you use to dismiss more worker-friendly technologies is actually circular, because the poor interoperability of current software was caused by exactly those standards and methods you cite as being the solution (not unlike the machine shops citing the lack of skilled machinists as a reason to introduce even more automated, labor de-skilling machinery into the factory).
The good news is that this isn't all so bad. Eventually, the institutional momentum of the processes and technology reaches a threshold where these methods work quite well (as can be witnessed by all the cheap goodies we get from China). The same will eventually be true for software, and will actually occur quite soon due to the accelerated rate of change.
Cliki, a wiki directory of "Links to and resources for free software implemented in Common Lisp and available on Unix-like systems."
CLOCC - the Common Lisp Open Code Collection"
common-lisp.net, providing hosting and remote repositories to dozens of Free Software Common Lisp applications.
This doesn't even touch SourceForge (which hosts another two dozen or so Lisp projects I'm aware of). When you consider how small the Lisp community is compared to the number of Perl hackers (easily in the range of 1000:1), and the number and quality of the code on just those repositories to CPAN, the productivity advantage of Lisp really does seem closer to 50x. According to your argument, all those Perl hackers should not have had any trouble in coming up with an efficient implementation by now. Yet, with less that a dozen regular hackers between them, the CMUCL and SBCL projects have produced compilers that outperform g++. At the very least, the Perl folks should not have had any trouble producing an efficient regular expression library, but here again, Lisp has them beat.
Of course, the above links point to software written in only one dialect of Lisp, Common Lisp. When you consider the software produced in other dialects, like Scheme, NewLisp, LUSH, XLISP, and Isis, the difference becomes even more apparent. To say nothing of commercial software, where none of the languages you mention can even boast a fraction of the number of large, successful systems delivered in Lisp.
Yes, I think it's safe to discount Darcs because it's written in Haskell, because god forbid not every other C or Perl monkey who can't be bothered to read a language specification for a day won't be able to make their random changes on the system while I'm trying to use it. By your logic, CVS should absolutely be the cat's ass because of all the meaningful contributions coming from the large, trained and expert community of C developers. Or not.
Stop deluding yourself. Copyright infringement may not fix anything, but this is because issues like these have nothing to do with copyright infringement and everything to do with publisher control. Media company management has this idea that just because the customer has a record button, he has stopped being right. Since they view media (not without cause) as a living necessity, they use this justification to exert further, blatantly unnecessary and abusive control over it's distribution. It's amusing that you call copyright infringers "COPYRIGHT STEALING IDIOTS," because the only copyright thieves here are the publishing companies.
Perhaps not surprisingly for anyone who has heard about the management at NASA, C++ was selected for the successors to the Remote Agent on the grounds that it is supposed to be more reliable (this despite the fact that the Remote Agent was originally to be developed in C++, an effort that was abandoned after a year of failure). This caused more than a few people to be upset (including a very personal account by one of the aforementioned designers). Clearly the debugging facilities of Common Lisp are far superior to static systems like C++, something which is very useful in diagnosing unexpected error conditions in spacecraft software (read the first question on p. 3 of the interview to see what pains the JPL staff went through to adapt similar, ad-hoc methods to VxWorks). It's also clear from this interview (question: "How is application programming done for a spacecraft?" Answer:"Much the same as for anything elsesoftware requirements are written, with specifications and test plans, then the software is written and tested, problems are fixed, and eventually its sent off to do its job.") that NASA has in no way tried to adapt formal verification methods for it's software, prefering instead to rely on the "tried and true" (at failing, maybe) poke-and-test development "methods."
Clearly, formal verification methods to eliminate bugs before critical software is deployed, and deployment in a system with advanced debugging facilities is a clear win for spacecraft software, and should be adapted as the standard model of development. Unfortunately, like in many other software development enterprises, inertia keeps outdated, inadequate systems going despite a strong failure correlation rate.