There are many better alternatives to PHP
on
Hardened PHP
·
· Score: 2, Informative
A mini-language designed for one purpose will eventually become a general-purpose language (as PHP already has), and it doesn't mean it is well-designed in the first place (as my superficial familiarity with PHP tells me). That being said, there are many alternatives to PHP that work quite well.
The ones I'm most familiar with are extensions of Common Lisp. There are 3 CL web servers, each with dynamic HTML generation capability (AllegroServe, Araneida, CL-HTTP). Then there's Lisp Server Pages, Active Lisp Pages, etc., and another whole load of CGI solutions. I use (and highly recommend) AllegroServe. There is a whole big list over at Cliki (which runs on Araneida).
There are many CGI bindings for various Scheme implementations, and the PLT web server is kind of popular. I'm not very familiar with Scheme web solutions though, so I probably left something out.
There is a lot of activity with Smalltalk-based web apps. Seaside is a continuation-based framework that gets a lot of attention. There's also AIDA/Web, and an unfinished mod.Smalltalk. I am not very familiar with Smalltalk web solutions either, so I probably missed a few.
Python is a very popular option, and Zope seems to be a very popular framework. I don't know anything about web programming in Python aside from that.
Take pretty much any of the recent lightweight (in the conference meaning of the term) languages, and you're bound to find good options, almost all of them better in terms of security and speed than PHP; I can't think of a single one that has a more annoying syntax or more convoluted and limited semantics than PHP, though. Another thing that you should consider is the website we're posting on is pretty interactive, and kind of popular, and it's written in Perl.
I remember reading some announcement about how Lotus (owned at the time by IBM) was going to put out a web-based "utility" metered Java version of their office suite. This was back in about 1998. I don't recall anything after that. One has to wonder where this new announcement leaves Smartsuite, since it too is competing directly against MS Office (and if they haven't changed Word Pro too much in the last seven years, they have a pretty good go at it, too - Word Pro 97 is still my favorite word processor).
Whereas legacy systems such as Unix are finding it harder to support newer hardware features such as the NX codes in the latest AMD and Intel chips, the deep corporate partnerships that Microsoft has with these companies allows them to bring such technologies to the public at a faster rate than otherwise possible.
Yeah, like page protection support isn't present in Linux, FreeBSD, OpenBSD, and possibly even NetBSD. Nice try, troll. The other thing to note (besides the fact that page protection is a new technology only if you've been under a rock the past 30 years and consider C a "high-level" language) is that many recent Windows exploits have taken advantage of poorly thought out "features" in Outlook/IE/Windows messenger service that memory protection wouldn't save you from anyway.
Lisp and Smalltalk certainly had these capabilities in the 70s. Some of the Smalltalk stuff is described in a book I highly recommend, G. Kranser's (ed.) Smalltalk-80: Bits of History, Words of Advice. Interlisp had advanced stack-handling facilities for it's spaghetti-stack VM, and hooks into all the error handling facilities, dating back to the late 60s, when it was known as BBN-Lisp. Of course, development was also entirely structure-oriented, so instead of line numbers with your stack trace, you'd get the source code, right then and there (Smalltalk is the same way, but you get the text - in Interlisp, all the code was actual data structures).
One thing that shouldn't be missed is that object-oriented exception handling, as popularized by Java, was invented in MIT Lisp Machine Lisp. This simplified and regularized error handling tremendously, to the point where today hooks into the deepest aspects of a typical implementation of Common Lisps' debugger are reduced to about a page's worth of code to deal with stack handling. I did a little work on the CLISP backend for SLIME, and this really surprised me.
GC takes over memory management, but leaves the other scarce resources -- file descriptors, sockets, mutexes, database connections -- to be managed manually, as in C.
What? Do you mean to tell me that all this time my Lisp implementation has been lying to me about collecting file descriptors, sockets and processes? But how can that be? My web server would have run out months ago!
Oh yes, now I get it! You're an ignoramus troll who doesn't know what he is talking about.
Believe it or not, file descriptors, sockets, and pretty much any other objects, are, well, objects, and so they have to reside in memory, where the garbage collector eventually comes to take them away. When it does so, it can tell apart a file descriptor from a pile of dung (please sir, will you spare me a few tag bits?), and call the appropriate routine to free the resource! Yes, the miracles of modern computers, indeed. Now please go away, before you embarass yourself much further.
With the amount of responses this guy had, I am amazed that no one noticed this. Perhaps we're all a little too busy arguing about GCed languages instead of using them?
I think you mean "mark and sweep" collectors. "Stop and copy" collectors just trace the working set from whatever your heap root is. Add in the copy step, and you only touch twice the size of you working set. If your collector is well-written and the OS provides the hooks, it will ask for the new space to be allocated in core, and the old space to be discarded, wherever it is.
I'm just relaying the comment that both the C and C++ committee have delayed adoption of a GC standard for those two languages and that a serious issue is real- time performance. The C/C++ standards committees are not a bunch of idiots so I take the view that there must be something true in there.
I'm not familiar with the stance of the C and C++ committees on garbage collection, but "real-time" (however you choose to define it) considerations are the least of the problems of getting GC into C. hak1du already mentioned some of the faults of Boehm's collector. All these can be traced to the root of all evil: pointers and weak typing. The reason that Boehm's collector is called "conservative" is that it cannot reliably predict what is and isn't a pointer (it works on probabilities derived from heuristics), since in C on contemporary architectures there isn't a difference between one and an int. This means that some garbage may in fact go unclaimed, and even worse, there are some situations (but you really have to go out of your way to produce them) where legitimate data is wiped. In a "pure" garbage collected language, there is no concept of pointers or dereferencing - you always pass everything by reference (objects like integers are just made immutable). This is, IMO, the biggest benefit garbage collection has for the programmer (safety concerns are for the end users:)).
I'm going back to the comment regarding other resources than memory. If you need a GC for your language to be safe then you need some other automated mechanism to close down open resources for you as well.
Most GCed languages I've come across automatically close things like file descriptors and sockets. However, the good ones provide you with explicit commands to do so, since it's quite easy (on Unices, anyway) to use up all the file descriptors between GC runs.
I own an MSI TV-Anywhere capture board, which itself kicks a lot of ass (PAL and NTSC in one card, very good capture quality), but unfortunately they had the shitmonkeys at Intervideo do the software and driver side of things. If you thought that what Valenti said about Winstein's program was rude, well, rest assured my opinions of Intervideo are much ruder. Those shitheads are committed to Linux all right; that's why I can only use the damned card under Windows, only with their software, which only encodes in their proprietary MPEG-II based codecs. If Intervideo did release a licensed DVD player for Linux, I wouldn't even bother looking at it.
If you want hard real-time, you might as well handle multi-threading and garbage collection at the same time.
The thing that most of the GC naysayers in this thread are ignoring is that you only need to garbage collect when you allocate too much. It's trivial to write your own object pooling doohicky - pre-allocate all the objects that you think you will need, and stick them in a vector (optionally declare it static so if the GC ever runs it won't even look at them). Pop off an object when you need it, return it when you're done (or better yet, mark the entire resource unused at one point in your program), and in case you need more than you thought, just allocate another object as you normally would - the difference is that this object will be there the next time around. This is much more efficient that new/delete in C++ - you don't wait for memory to be fetched from the OS, you don't wait for that memory to be laid out, if you don't need it (and you really don't need it most of the time) you don't wait for object initialization, and you don't wait for deallocation (especially not if you return the whole thing at once!). Object allocation costs at best one function call and integer increment, and at worst that plus the cost of allocating the object; object de-allocation costs at worst one integer decrement (I suppose if you're worried about safety you'd do a range check too). Fancy, dynamically-sized data structures (arrays mostly) need a little search and pointer comparisons, but with hashing it's also pretty cheap. If you need to actually get rid of the thing, you just lose the reference, call the GC, and the whole thing gets reclaimed at once. Oh, and in case you didn't notice, this method has nothing to do with GC besides being safe and fast. I use it all the time with C++ and it works faster (and IMO the style helps prevent and debug memory leaks and other errors better) than manual memory allocation.
Not sure exactly what this is, but I imagine it makes D into a fully-functional language. Sounds great! It makes me even more interested.
It's an anonymous function that "captures" the bindings of whatever variables it needs in the lexical scope it is created in. Not really functional (closures are all about the state of those variables), but they're handy as a light-weight, high-performance alternative to objects. I don't know why he calls them "dynamic" closures, since D doesn't have dynamic scoping, and "lexical closures" has been used to mean the same thing for about 20 years now. Same thing with "function literals" vs. "anonymous functions."
I'd be intersted to see an example of how D's array slicing compares to C++'s interator-based programming. I'm not sure what's being talked about here, exactly.
Array slicing (displaced arrays) is an awesome abstraction for efficient, in-place array manipulation. For example, you can do in-place bit-blit with 2d displaced arrays. Unfortunately, the D specification leaves out any mention of multidimensional arrays - looks like you can only displace to vectors. All the modern languages I've come across that do this are crippled in the same way. Zetalisp let you do real nifty stuff, like multidimensional displaced arrays, and displacement to different types - so for example you could access an array of words as an array of bytes (or bits!) very efficiently.
There's really no meaningful way you can say C++ doesn't have array bounds checking. Come on! What C++ has, which might be much better than D, is switchable array bounds checking. You don't _have_ to check array bounds (e.g. for release builds), but it's trivial to add if you want it.
Array bounds checking should always be there unless it is a performance problem. Constructs like iterators in C++ and foreach in D allow bounds checking (and some other stuff) to be optimized out (not to mention providing a base for vector/parallel code generation that is a whole lot less brain damaged than the for loop analysis the current C vector-targeting compilers have to do). For D, this is also a really good idea since strings are arrays.
Conditional compilation At least this gives you some of the power of a preprocessor. But why stop there? Why not have _all_ the power. While you at it, make a cool preprocessor, like O'Caml's, or Lisp's.
The O'Caml preprocessor (Camlp4) is very neat (from what I understand, you can adapt it for source-to-source transformations for pretty much any syntax with a context-free grammar - this could be a starting point for a hypothetical D preprocessor). (Common) Lisp doesn't have a pre-processor (aside from reader-macros so you can write 'foo instead of (quote foo)) - you really can't get anything similar in D (or O'Caml) until you have run-time code generation and loading, a uniform representation for program source code, and a large amount of introspection facilities.
Alias/Wavefront's Maya package is the leading product in the high-end animation industry today, having displaced Softimage.
And how large is that market really? I was under the impression that the US 3d animation industry has largely been in decline for the past four years (at least it seems that way from the layoffs and closings of the large studios, and things I've heard and read).
Arguably, it's SGI's most successful business.
I've heard that it's SGI's most publicly visible business, but that SGI makes most of their money from selling computers to the government.
I've heard/read (sorry, forgot where) that upwards of 90% of new residential developments in the US are built based on recycled blueprints. Since developers buy in bulk, they're made out of the same material, and since nobody has any taste or originality left anymore, they're all painted either light blue or peach. Living in Canada, it looks to be pretty much the same up here too.
Some of you may know this already, but for those who don't, RMS and James Gosling had a feud in the 80s over Gosling's Emacs (which was a TECO Emacs workalike). Apparently, there were agreements between Gosling and several other developers to the effect that they could modify and redistribute the source to Gosling's Emacs. RMS decided to base the original GNU Emacs on Gosling's code. Apparently, this happened after Gosling decided to sell the rights to his Emacs clone to Unipress, and bitter legal threats ensued. This seems to have been one of the primary motivations for the GPL. I've never seen Gosling speak or write about the incident since. RMS gave a speech in 1986 where he recounted the incident, and he didn't have a lot of good things to say about Gosling:
"In the summer of that year, about two years ago now, a friend of mine told me that because of his work in early development of Gosling Emacs, he had permission from Gosling in a message he had been sent to distribute his version of that. Gosling originally had set up his Emacs and distributed it free and gotten many people to help develop it, under the expectation based on Gosling's own words in his own manual that he was going to follow the same spirit that I started with the original Emacs. Then he stabbed everyone in the back by putting copyrights on it, making people promise not to redistribute it and then selling it to a software-house. My later dealings with him personally showed that he was every bit as cowardly and despicable as you would expect from that history."
That speech also has a few memorable quotes, and I highly recommend you read it. I haven't heard or read RMS referring to Gosling personally since, but I believe that the incident itself has been recalled by him a few times since.
Now for my part of the disclosure: I currently attend the University of Calgary, where James Gosling is the only persona anywhere near to fame that the Computer Science department has ever produced (Theo de Raadt doesn't count, unless your definition of "produce" involves scandal and legal threats).
The above is mostly just hearsay and speculation, and should not be taken as authoritative, except the excerpt from RMS's speech.
Sun doesn't provide their own JRE for the BSDs, and FreeBSD's JRE is only at version 1.3.1 (I don't even know if this much is available for NetBSD and OpenBSD). If you want the current JRE (1.4.2), you're going to have to pay for a commercial one. On the other hand, GCC and the GNU C library work on all the platforms you mention (and many more besides that, some where a JRE does not even exist). In a way, it's not surprising that ISO C is the most portable language available, but when you look at the calendar, it is also kind of sad. This is of course talking about source distribution, but when some person on Slashdot asks to run his programs on hundreds of other people's computers, it would be a little suspicious for him not to provide the source code.
The conventional way of thinking, at least out here in the great and powerful North American countries (I consider Canada the 51st state, when it comes to consumerism), is to spend your weekends alternatively shopping and stuffing yourself with fast food (those who like to believe in fads also spend some time in church).
We like to make lists, connect the dots, whathaveyou.
Most people prefer connect-the-dots to oil paint (most people are young, after all:)). As for making lists, it may shock and surprise you that LISP is actually an acronym for LISt Processing. I hear it's pretty good at that.
I mean, look at how much trouble people have thinking about stacks these days, and thats really just reverse-sequential.
This is why most people should be kept away from real computers, never mind programming. I look forward to the day when all consumer computer needs either migrate to cellphones or better yet to a device comparable to an Etch-a-Sketch in complexity.
Humans don't like recursion, thats why nobody uses LISP or anything like it.
Most humans don't like work or responsibility. Too bad for them.
When I see a screenful of lisp, I see words and brackets. I have to read in order to parse struture.
When I see a screenful of java, even a brief glance shows me what's going on. I can recognise a for-loop, a while with an Iterator, a method definition, a method call, an assignment. I can see the try and catch blocks. Before I mentally parse any of the words.
Unfortunately, you have to read your Java code to figure out what it does too. Sorry to disappoint you. You may or may not also be surprised to know that the ability to tell where your catch blocks are are shared by most imperative programming languages (indentation - welcome to the world of tomorrow!); Python even requires it. What you probably don't realize is that none of this helps you any. The baroque syntax of C-derived languages necessitates an excessive use of whitespace, which, combined with Java's pretty little exception handlers (which are really a systematic way to force you to code defensively) means that you will need many a screenful to display any useful body of code. This is not even to mention the stupid operator restrictions which force weird naming conventions (LikeStupidStudlyCaps because we can't have no minus signs anywhere, and the underscore is too hard to type - and forget about putting something sane like a question mark at the end of a predicate name). This is why I like to advocate Python as the ultimate imperative language - you cannot do too much better in terms of syntax. Unfortunately, this does little to no good when you really want to apply multi-paradigm and reflective programming; eventually, it all ends up looking kind of like Lisp (and when it doesn't you get some horror like DIANA for Ada that needs a 300 page specification).
Lisp isn't code. Lisp is assembler for the Lisp VM, that somebody forgot to write a code parser on top of.
Glad you mentioned this. Nobody forgot anything; McCarthy's original intention was to have exactly this for Lisp. Fortunately, saner minds (the users' and implementors') recognized the utility of S-expression (also known as "Cambridge Polish" notation) and kept it around for almost 50 years. Programmers new to Lisp often do exactly that; by the time they're done they either realize the value of the notation or go away. There have been a few efforts to add a more conventional syntax to Lisp (Dylan being the most technically successful). Seems no one was interested anyway.
You're wrong in your level of concern, though. The languages in question don't offer the foot-shooting capabilities of C/C++. You can't leak memory in a GC'ed language, so that removes that concern. Passing objects vs passing pointers isn't an issue in languages that only pass symbols which have references to the objects themselves. Etc, etc. Yes, there are other concerns in place to watch for bottlenecks and ways to improve speed, but these factors will not prevent the new programmers' code from running, just from running quickly, which can be solved in an iterative fashion.
Maybe we're reading the OP differently, but I think that is exactly his point. I don't think he was talking about new programmers as those that can't even get their code to compile, but to those that can't yet write very good code. Higher-level PLs may make it easier to get a running program, but they also make it ridiculously easy to write inefficiently stupid code (just because it seems to run doesn't mean it doesn't have major bugs!). In C, there's really only one "right" way to do things, and it tends to be fast enough for most compilers on most architectures. In contrast, C++ and other, higher-level languages often present several differing ways to do things with many trade-offs, some differing for implementations and machines. This is where a knowledge of the implementation is needed. Unfortunately, this does not work with a human-wave hieararchy of developers - you can't just assign one implementation guru to digest newbie's code, because more likely than not he will just rewrite most of it. Fortunately, many environments provide good profiling and advice tools, so the hot-spots of a system can be identified and improved without spending time on other stuff.
There's a lot of hand-pointing at C from some of the users of the high-level languages when they need efficiency: "Oh, we'll just rewrite the critical parts in C and be done with it." Unfortunately, to do that they need to know how to write efficient code for their C compiler and how to get an efficient interface between their language's runtime and the C code; they've just replaced one problem with two. Now they have to know about their C compiler and all the inner workings of their higher-level language implementation. If you have a half-decent native-code compiler for your language and are somewhat familiar with it, it is not all that hard to produce fast-enough (sometimes even faster:)) code with it than in C or C++. With some single-paradigm languages with no native-code compilers (Javascript, Pearl 5) you don't really have a choice, but I don't think you should be using a single-paradigm language anyway.
Why not do GNU/Gnome and the developers they want to attract a favor?... Make it a language they can take back with them to their jobs.
Between the.com orgy and subsequent bust and lessons (not) learned, and the overwhelming successes of Free Software and the Java/C++/PL/1 human wave "software engineering," there won't be any (programming) jobs to go back to unless you're in India or the Philippines. Quite frankly I'd be glad for that. Ship all the monkey work overseas (we are supposed to be living in the age of automation innovation productivity growth, after all!), and let the hobbyists use whatever language they want. Many people forget that the interactive computer was invented by a bunch of crazies, and that the PC industry was started by a bunch of crazy hobbyists. They didn't need or want the shit that businesses love to shovel onto their customers, or right now you'd be punching COBOL on a cardboard IBM card.
Two-tier water systems have been around for a while. First I've heard of them being proposed for large-scale was from a Paolo Soleri book from the 70s, but people have been recycling water in washing pots before, etc. then. Last summer I spent a lot of working as a tour guide around remote places in the Canadian Rockies, and some places (the hotel at the Columbia Icefields being the biggest example - they're right near a melting glacier, but purifying your own water is very expensive) are employing grey water for sewage. Gray water systems work by recycling drinking and washing water after it comes into a building for flushing toilets. I haven't seen any systems where they separate the drinking and washing water though; that's a lot more complicated and maybe not even worth the cost (unless you're a laundry or something:)).
There was a study done (sorry, forgot where I saw it) that concluded that almost everyone cannot tell the difference between even "low-quality" tap water (they used garden hose water) and expensively branded bottled water anyway. All the bottled water I've tried doesn't seem to taste particularly good anyway (some I think tasted worse than my tap water). Of course, nothing I've tried comes even close to a fast-flowing gravel-bed mountain stream.
By way of example, one of the axioms is that parallel lines never meet. We don't actually know if that's true, but it's pretty close. If we do turn out to live in a curved universe, we'll have to throw away some bits of maths.
I have a first class degree in Maths, and a lower second in Physics too.
It's hard to believe you managed to do both without learning anything about either non-Euclidean geometry or the geometry of the universe (for the curious: yes, it is curved). It's even harder to believe that someone with a degree in math would use appeal to authority (his own authority no less!) to debate mathematical points. The poster to whom you are replying makes some valid (and quite interesting) points; you are just making an ass out of yourself.
... Iron Curtain during the hight of the cold war, military officers armed with automatic weapons boarding the train at the border crossing and such... but at least, In Soviet Russia, they didn't strip search me and they didn't photograph and print me. They checked my passport.
Last time I was there (4 years ago now), there were military officers with automatic weapons boarding the train on both sides of a border crossing (and this wasn't some shithole I was travelling to - I was going from Russia to Lithuania). The only difference compared to what it was like in the good old days is that now the Russian border guards want bribes in addition to looking at your passport (quite frankly, I couldn't figure out what the hell the Lithuanian ones wanted).
In most American cities, the auto-park is a solution looking for a problem. The machinery itself is fairly complex to build and maintain. The average cost of a parking spot in the auto-park is $25,000. In most American cities, the average cost of a parking spot is a lot less than that. Now you tell me which is the "waste of money".
You're thinking like the developers and planners of "most American cities": five minutes ahead. Population is only going to grow, and land need and price with it. As a lot of cities are starting to find out, it's a lot less expensive to build something right the first time, than try to fix/expand it once all the land around is in private ownership*. I'd wager auto-stacked parking would make financial sense in the downtown areas of most American cities.
Huhh?? What does expensive stack parking have to do with pollution? I hope you're not suggesting that the extra 100 yards a car has to drive in your average parking lot is a measurable source of pollution. Ditto for sprawl.
Take than 100 yards and multiply it by 10. Ignore the fact that you now have to drive significantly more. Forget about all the useful land you've wasted. What you should keep in mind is that you are preventing other people from walking and biking from place to place. Since land is in 2 dimensions, each yard you're adding to the parking lot adds between one and two yards of extra travel. Since parking lots are covered in asphalt and have no overhead cover, it's uncomfortably hot for pedestrians in sunny weather, and the lack of drainage creates deep puddles during rain. For several large parking lots these factors quickly add up to make walking unmanageable and cycling unnecessarily slow and uncomfortable.
* - For example, I live in Calgary, Alberta, Canada. The Trans-Canada Highway goes right through the city, and is 2 lanes wide in residential parts. This causes major congestion problems, and in order to expand it to three lanes they've had to negotiate the buy-out of all the private properties along that stretch of road (something that took them over two years, and who knows how many millions of dollars). Now they have to demolish all those properties and pave over them. It would have been a lot more economical to reserve space for an extra lane, or better yet make the highway bypass the city. There's a bypass proposal in the works, but unfortunately by now the city is so sprawled out that it will add a significant amount of travel time. It's a lose-lose situation (for everyone but Canadian Pacific Railway:)).
I do the same thing, except I try to imagine reading page after page of that code written by someone other than me (the examples they give are usually less than a dozen lines long, so it actually requires some imagination). Except, of course, I compare that to Common Lisp:). Most of the time, I come to the same conclusion. I deal with quite a bit of open source/public domain/free software CL code, and it always seems to be very well written (good use of macros makes the language look declarative enough that I can read it out as English without too much thought).
Slashdot Mirror
The ones I'm most familiar with are extensions of Common Lisp. There are 3 CL web servers, each with dynamic HTML generation capability (AllegroServe, Araneida, CL-HTTP). Then there's Lisp Server Pages, Active Lisp Pages, etc., and another whole load of CGI solutions. I use (and highly recommend) AllegroServe. There is a whole big list over at Cliki (which runs on Araneida).
There are many CGI bindings for various Scheme implementations, and the PLT web server is kind of popular. I'm not very familiar with Scheme web solutions though, so I probably left something out.
There is a lot of activity with Smalltalk-based web apps. Seaside is a continuation-based framework that gets a lot of attention. There's also AIDA/Web, and an unfinished mod.Smalltalk. I am not very familiar with Smalltalk web solutions either, so I probably missed a few.
Python is a very popular option, and Zope seems to be a very popular framework. I don't know anything about web programming in Python aside from that.
Take pretty much any of the recent lightweight (in the conference meaning of the term) languages, and you're bound to find good options, almost all of them better in terms of security and speed than PHP; I can't think of a single one that has a more annoying syntax or more convoluted and limited semantics than PHP, though. Another thing that you should consider is the website we're posting on is pretty interactive, and kind of popular, and it's written in Perl.
I remember reading some announcement about how Lotus (owned at the time by IBM) was going to put out a web-based "utility" metered Java version of their office suite. This was back in about 1998. I don't recall anything after that. One has to wonder where this new announcement leaves Smartsuite, since it too is competing directly against MS Office (and if they haven't changed Word Pro too much in the last seven years, they have a pretty good go at it, too - Word Pro 97 is still my favorite word processor).
One thing that shouldn't be missed is that object-oriented exception handling, as popularized by Java, was invented in MIT Lisp Machine Lisp. This simplified and regularized error handling tremendously, to the point where today hooks into the deepest aspects of a typical implementation of Common Lisps' debugger are reduced to about a page's worth of code to deal with stack handling. I did a little work on the CLISP backend for SLIME, and this really surprised me.
Oh yes, now I get it! You're an ignoramus troll who doesn't know what he is talking about.
Believe it or not, file descriptors, sockets, and pretty much any other objects, are, well, objects, and so they have to reside in memory, where the garbage collector eventually comes to take them away. When it does so, it can tell apart a file descriptor from a pile of dung (please sir, will you spare me a few tag bits?), and call the appropriate routine to free the resource! Yes, the miracles of modern computers, indeed. Now please go away, before you embarass yourself much further.
With the amount of responses this guy had, I am amazed that no one noticed this. Perhaps we're all a little too busy arguing about GCed languages instead of using them?
I think you mean "mark and sweep" collectors. "Stop and copy" collectors just trace the working set from whatever your heap root is. Add in the copy step, and you only touch twice the size of you working set. If your collector is well-written and the OS provides the hooks, it will ask for the new space to be allocated in core, and the old space to be discarded, wherever it is.
I own an MSI TV-Anywhere capture board, which itself kicks a lot of ass (PAL and NTSC in one card, very good capture quality), but unfortunately they had the shitmonkeys at Intervideo do the software and driver side of things. If you thought that what Valenti said about Winstein's program was rude, well, rest assured my opinions of Intervideo are much ruder. Those shitheads are committed to Linux all right; that's why I can only use the damned card under Windows, only with their software, which only encodes in their proprietary MPEG-II based codecs. If Intervideo did release a licensed DVD player for Linux, I wouldn't even bother looking at it.
"It is the difference of point of view that leads to problems: point of view is worth 80 IQ points."
It is from an essay of Alan Kay's, printed in Winston and Prendergast's (eds.) AI Business, 1984.
The thing that most of the GC naysayers in this thread are ignoring is that you only need to garbage collect when you allocate too much. It's trivial to write your own object pooling doohicky - pre-allocate all the objects that you think you will need, and stick them in a vector (optionally declare it static so if the GC ever runs it won't even look at them). Pop off an object when you need it, return it when you're done (or better yet, mark the entire resource unused at one point in your program), and in case you need more than you thought, just allocate another object as you normally would - the difference is that this object will be there the next time around. This is much more efficient that new/delete in C++ - you don't wait for memory to be fetched from the OS, you don't wait for that memory to be laid out, if you don't need it (and you really don't need it most of the time) you don't wait for object initialization, and you don't wait for deallocation (especially not if you return the whole thing at once!). Object allocation costs at best one function call and integer increment, and at worst that plus the cost of allocating the object; object de-allocation costs at worst one integer decrement (I suppose if you're worried about safety you'd do a range check too). Fancy, dynamically-sized data structures (arrays mostly) need a little search and pointer comparisons, but with hashing it's also pretty cheap. If you need to actually get rid of the thing, you just lose the reference, call the GC, and the whole thing gets reclaimed at once. Oh, and in case you didn't notice, this method has nothing to do with GC besides being safe and fast. I use it all the time with C++ and it works faster (and IMO the style helps prevent and debug memory leaks and other errors better) than manual memory allocation.
I've heard/read (sorry, forgot where) that upwards of 90% of new residential developments in the US are built based on recycled blueprints. Since developers buy in bulk, they're made out of the same material, and since nobody has any taste or originality left anymore, they're all painted either light blue or peach. Living in Canada, it looks to be pretty much the same up here too.
Some of you may know this already, but for those who don't, RMS and James Gosling had a feud in the 80s over Gosling's Emacs (which was a TECO Emacs workalike). Apparently, there were agreements between Gosling and several other developers to the effect that they could modify and redistribute the source to Gosling's Emacs. RMS decided to base the original GNU Emacs on Gosling's code. Apparently, this happened after Gosling decided to sell the rights to his Emacs clone to Unipress, and bitter legal threats ensued. This seems to have been one of the primary motivations for the GPL. I've never seen Gosling speak or write about the incident since. RMS gave a speech in 1986 where he recounted the incident, and he didn't have a lot of good things to say about Gosling:
That speech also has a few memorable quotes, and I highly recommend you read it. I haven't heard or read RMS referring to Gosling personally since, but I believe that the incident itself has been recalled by him a few times since.
Now for my part of the disclosure: I currently attend the University of Calgary, where James Gosling is the only persona anywhere near to fame that the Computer Science department has ever produced (Theo de Raadt doesn't count, unless your definition of "produce" involves scandal and legal threats).
The above is mostly just hearsay and speculation, and should not be taken as authoritative, except the excerpt from RMS's speech.
Sun doesn't provide their own JRE for the BSDs, and FreeBSD's JRE is only at version 1.3.1 (I don't even know if this much is available for NetBSD and OpenBSD). If you want the current JRE (1.4.2), you're going to have to pay for a commercial one. On the other hand, GCC and the GNU C library work on all the platforms you mention (and many more besides that, some where a JRE does not even exist). In a way, it's not surprising that ISO C is the most portable language available, but when you look at the calendar, it is also kind of sad. This is of course talking about source distribution, but when some person on Slashdot asks to run his programs on hundreds of other people's computers, it would be a little suspicious for him not to provide the source code.
And I sure as hell trust Theodore Nelson a lot more that I do some anonymous slashdot jerk.
There's a lot of hand-pointing at C from some of the users of the high-level languages when they need efficiency: "Oh, we'll just rewrite the critical parts in C and be done with it." Unfortunately, to do that they need to know how to write efficient code for their C compiler and how to get an efficient interface between their language's runtime and the C code; they've just replaced one problem with two. Now they have to know about their C compiler and all the inner workings of their higher-level language implementation. If you have a half-decent native-code compiler for your language and are somewhat familiar with it, it is not all that hard to produce fast-enough (sometimes even faster :)) code with it than in C or C++. With some single-paradigm languages with no native-code compilers (Javascript, Pearl 5) you don't really have a choice, but I don't think you should be using a single-paradigm language anyway.
There was a study done (sorry, forgot where I saw it) that concluded that almost everyone cannot tell the difference between even "low-quality" tap water (they used garden hose water) and expensively branded bottled water anyway. All the bottled water I've tried doesn't seem to taste particularly good anyway (some I think tasted worse than my tap water). Of course, nothing I've tried comes even close to a fast-flowing gravel-bed mountain stream.
* - For example, I live in Calgary, Alberta, Canada. The Trans-Canada Highway goes right through the city, and is 2 lanes wide in residential parts. This causes major congestion problems, and in order to expand it to three lanes they've had to negotiate the buy-out of all the private properties along that stretch of road (something that took them over two years, and who knows how many millions of dollars). Now they have to demolish all those properties and pave over them. It would have been a lot more economical to reserve space for an extra lane, or better yet make the highway bypass the city. There's a bypass proposal in the works, but unfortunately by now the city is so sprawled out that it will add a significant amount of travel time. It's a lose-lose situation (for everyone but Canadian Pacific Railway :)).
I do the same thing, except I try to imagine reading page after page of that code written by someone other than me (the examples they give are usually less than a dozen lines long, so it actually requires some imagination). Except, of course, I compare that to Common Lisp :). Most of the time, I come to the same conclusion. I deal with quite a bit of open source/public domain/free software CL code, and it always seems to be very well written (good use of macros makes the language look declarative enough that I can read it out as English without too much thought).