In turn, I can't see Apple doing that. Dropping the basic four button and a click wheel style of interface that has been with the iPod since it first came out would, in the eyes of a great many iPod users, be tantamount to dropping the iPod. I and most other iPod users I know like our iPods because I find it easier to work with than other mp3 players, not because Apple makes it. Apple is pretty full of hubris, but I doubt they're _that_ full of hubris.
Do you seriously believe that an iPod that is primarily devoted to video has no cause to be considered a different product from the one that is devoted to music? I'd say it gets more cause than, say, an iPod that's pretty much the exact same thing only in a different form factor (like, say, the regular vs. the mini).
I read your comment fully. I just assumed you weren't being 100% dense about this and might just be going off of a less-than-complete knowledge of the whole iPod product line.
Hmm. I see someone else modded this post insightful, which is interesting. I would have modded it funny; the essay didn't really go anywhere so I can't see how it was meant to be anything but a satire of the attitudes of men who lack the backbone to define themselves however the hell they want and instead must cling to "safe" ideas like the manly man.
And then I start surfing the rest of the site, and it becomes clear to me that this guy might be serious. But I really can't tell. Everything seems like a caricature of the archetypical man-child, but nothing goes quite overboard enough for me to be entirely sure.
But I think I'm going to stick with thinking this is really meant to be a joke. Or maybe Kim du Toit isn't joking, just pretending. He wants us to take him seriously, because he's trying to ride on Ted Nugent's coattails.
I just cringed when you were grouping Perl with Java there... For that matter, I'd cringe if anyone would group any language with Java. It's really hard to make comparisons when you know that Java is pretty much always the worst choice in efficiency, speed and transparacy.
I have a feeling you're spouting cool-kid party line more than anything. Yeah, Perl has Java on memory consumption. But Java beats Perl hands down on speed. As for transparency, well, I guess there's no accounting for taste, but I think this is far, far more readable than this.
It's a scripting language that was designed toward the end of the 20th century. It doesn't need all sorts of integers and whatnot. If you need to care that much about speed, memory consumption, etc, you shouldn't be using an interpreted language in the first place. In the domain for which Lua was designed, tall numeric towers are rice.
I agree that using rare languages is problematic, but it's not showstopping, and it's not an argument for not using them - after all, if using them were always a bad idea, we'd still all be stuck with nothing more than a few languages like FORTRAN and BCPL.
I question the idea that programmers not knowing the language is much of an issue - for the most part, all languages use variations of the same C-like syntax with only a few break-aways such as Smalltalk, Lisp, or FORTH. Besides, there are plenty of programmers with minds flexible enough to learn new languages; lots of hackers like to learn them for fun.
The debugging issue can be a bother, but ideally the border between the bits written in a each language are well-defined enough that you can mostly debug each model separately and use techniques other than stepping through code with a debugger to handle the boudary cases. Besides, I'd argue that a debugger should be the absolute last line of defense in minimizing bugs. In my personal experience, multi-language development tends to be easier to write without bugs in the first place because it demands more careful design, which makes just jumping into the code without much of a plan a lot less tempting, and time spent debugging stuff like this seems to actually be shorter. I'd certainly hope that's the case, because a quick survey of new software and projects suggests that multi-language is rapidly becoming a standard way to handle large projects.
There's a lot limiting how much a language can really get refactored - for one, there's the urge to maintain backward compatibility. This is a pretty strong pull on languages, to the point that seven years after C99 I'm still not aware of a commonly-available compiler that implements it - and at least in the case of gcc it looks like backward compatibility is one of the major reasons this hasn't happened yet. Also, I'm really not aware of any major language refactorings aside from FORTRAN and Common Lisp. Usually what happens is that someone instead creates a new language that is similar to one or more other languages, but with (what the author thinks are) syntax improvements, and then the whole thing gets pushed as a new language. This is how Sheme relates to Lisp, C to B, Java to C++, etc.
Also, it's really not fair to characterize all rare languages as not being notably superior to existing languages. In the current case, a quick look around the other comments on this page will give you a long list of things that make Lua really stand out as a language. These comments come from people who actually know Lua, and probably know how to read all the major languages and have written a few lines of code in most of them. Meanwhile, judging from the generalities you're using, I'd be inclined to guess that you don't actually know a whole lot about Lua and therefore are mostly just asuming that its existence is somehow harmful based on nothing more than the observation that it exists.
The grandparen't wasn't saying that Lua's speed on these benchmarks alone is why Lua is the greatest language or anything. However, it does make Lua worth caring about. There are plenty of other reasons to like it - it's a fairly clean language, and in situations where maintainability matters it's probably preferable for a lot of people who don't like, say, perl's terseness and tangled syntax. It's a reflective language, which makes it useful for some more complex tasks than some other scripting languages.
Of course these aren't reasons why Lua is categorically better than other languages - perl is my first choice whenever I need an extraction and reporting language, C is still my first choice when performance matters, ObjC when performance matters a bit more but not as muc as in C (though in both those cases it's common for me to be working with an embedded scripting language, too), C++ if the gods turn sour on me and I end up having to be able to work with C++ libraries, postscript for dicking around in printers, etc.
I hate to burst your bubble, but if C++, Perl, Python, and Java are really such solid languages that there's no reason why any programmer would want anything else, then the world is screwed. Furthermore, adding new features to existing languages really isn't the solution - that path leads to madness, to kitchen-sink monstrosities like C++ and Perl. Both of them have traveled so far beyond the pale that their creators have admitted the desire to more or less start over and make a cleaner language that does the same thing.
While I know this is a strained metaphor, when you're trying to do serious work a box of tools is better than a swiss army knife. That's part of the genius behind.Net and the reason why Mono started - with an environment where you can write different modules in different languages and not have to care quite so much about the boundaries between them, you really are free to use the best tool for the job. This is also why embedded languages are getting so popular - yeah, I can do everything I need to do in ObjC, but damn is it nice to be able to save myself a crapload of time by doing all the "big picture" work in something like Lua or F-Script. Nor do I find either to be an irritant - F-Script produced a drastic improvement in my productivity and the maintainability of my code, and now that I'm learning Lua I'm loving it for similar reasons. I'll probably keep using both because each is best for slightly different things.
Lua is definitely more portable, and it's easier to get it to talk to other languages. I had originally looked at Guile for my current app (which does the heavy lifting with Objective-C), and decided against. Judging from the small number of Guile bridges, it looks like Guile doesn't play so nice with languages that aren't substantially similar to C, and even then there seem to be a lot of conditions and complications floating along the boundary between it and C.
Lua, on the other hand, is happy to run on anything from mainframes to toasters. It also has a number of existing bridges, many fewer of which seem to have been orphaned by their maintainers.
The language itself is a solid alternative to Sheme, too: It has enough functional-y features (first class functions, closures, reflection, etc.) to keep me happy, while also being designed well enough to handle other programming styles without getting unwieldy. It's really rather similar to Sheme in that it's a small language with just enough of a feature set to make you do large things. It does other things more nicely, too - implementing an ADT with tables involves a whole lot less boilerplate code than doing it with lists, for example.
It goes the other way, too. Last I checked, Dell computers are generally regarded as being pretty horrible from a reliability perspective. Despite all the noise that consumers make, Apple computers tend to be pretty solid. (Very solid if you never buy rev. A hardware from them.)
The most densely populated city anywhere near me is Chicago. Chicago has lots and lots of room to grow. The city proper is pretty dense, but you can always knock down two-flats and build larger apartment complexes. What really needs to happen, though, is for someone to tear up all the wasted space that was created by the suburban fetish for asphalt and start doing something useful with that 60-mile-radius wasteland that surrounds the city.
That would make maintenance easier for the KDE and GNOME teams, but it wouldn't create a situation that is functionally different for application developers. Much better to just completely migrate to Portland. (Of course, re-implementing the old stuff to use Portland might be a great intermediate step in the process.)
While I've heard that argument many times, as a longtime Slackware user who's used to having only what I want in my distro, I've found that that simply isn't how it works in the real world.
The problem is that every application developer chooses their own set of libraries to use, so that to use X image editor I need to install libraries A, B, and C. But then I decide to install Y media player, and find that to get it working I need to install libraries D, E and F, plus add a second audio interface to my kernel. Incidentally libraries D and F are analogous to libraries B and C. And the situation just keeps snowballing as I add more applications to my computer. Eventually I'm left with a huge pile of overlapping functionality, I'm forced to keep multiple versions of various libraries floating around, my kernel has just about everything under the sun compiled in, etc.
I suppose that if I really wanted to I could choose a lean, well-selected set of libraries and features for myself and then proceed to only use applications that work with all of that. But I live in the real world.
You do realize that, despite a lot of pedantic noise made by a few people like RMS, the word "Linux" is commonly used as shorthand for an entire family of operating systems based on the Linux kernel, and that for most everybody concerned the desktop environment is an integral part of any Linux install for workstation and desktop computers?
I assume you do, since you know enough about it to know that yes, technically, Linux is a kernel. Which means I have reason to think you understand what I was say and know that your response is pretty well beside the point.
Right. This only makes sense from any standpoint if Portland replaces the existing interfaces in KDE and GNOME. But of course that can't be done right away because there are too many apps that rely on them.
My guess is that, if all goes well, the situation you're talking about will just be some growing pain until the next major releases for KDE and GNOME, when they can force everyone to upgrade their code.
But the reality is probably that, since this is the FOSS community we're talking about, neither of the old sets of functions will be dropped for a good long while because somebody has developed a codependent attachment to them and won't let them go. That or just because it's a job that nobody really wants to do. Either way, Linux will continue to bloat and bloat and bloat until the end of time.
(disclaimer: not trying to characterize filesystem developers or pass judgmement on Hans Reiser, just being pedantic)
I was wondering why some guy smart enough and sane enough to develop a filesystem would go and murder his wife.
You certainly have to be smart to develop a filesystem, but what does sanity have to do with it? Personally, I'm of the opinion that there are a number of personality traits that your average psychologist would consider to be less-than-great but which are a huge boon for a filesystem developer. Compulsive tendencies, introversion, and possibly even a touch of psychopathy could all help someone stick around at the keyboard twiddling tiny little uncooperative bits and bytes without being driven mad.
Furthermore, there are lots of different kinds of smarts. Being a good software engineer doesn't translate into being able to weigh the consequences of one's actions, or having the ability to manage one's emotions, or accept hardship and hurt with grace, or anything like that.
I severely doubt that his being the developer of ReiserFS has much at all to do with this situation.
I get really sick of this particular snipe. It doesn't contribute anything useful to the conversation, and mostly serves as a low blow because most of us lack decent access to journal articles. Furthermore, the argument is essentially self-contradictory because it hinges on the idea that an idea is wrong if the person who suggested it doesn't have a list of journal articles in hand so they can back it up when someone responds with "OMFG teh PEER REVIEW!!!!111!!1!!" It's a painfully obvious logical fallacy, and the hurt is only increased when you put it in the same sentence as language about scientific studies.
If you really want to bring peer-reviewed research into the debate, why don't YOU do some legwork of your own and respond with some evidence that killers are wracked by guilt?
(And mods, what's interesting about the parent post? It only takes a short time on internet discussions to see about a millionty-five one or two sentence posts that are almost identical to this one. It's not interesting, it's banal.)
While I have to agree that SQL can be an annoying language, I have to wonder what you have against a textual querying language.
The only real alternative to text that I can think of would be some sort of drag-and-drop system for creating queries with flowcharts or something like that. But there are two big hits against that idea. First, it wouldn't work well with any major programming languages, all of which are textual. Second, I've done some work with that kind of scheme for writing programs - I've even created my own mini graphical programming language - and so far I have yet to meet one that isn't either extremely limited or hard to work with. Which isn't to say that a decent graphical language is impossible, just that the state of the art isn't nearly up to snuff yet.
I'd differ with you in that I've found cases where an undocumented but fully implemented API can be almost useless if the source isn't available or is poorly commented. I can think of a couple cases at work where I've tried to use a library that was written by somebody who is no longer around, and found that it was so arcane that after spending several days of trying to make sense of a commentless and overcomplicated pile of over-abbreviated function names and single-letter variables for the sake of making my boss happy by using existing code, I finally gave up and rolled my own code (this time with documentation) in a day or two.
Slashdot Mirror
In turn, I can't see Apple doing that. Dropping the basic four button and a click wheel style of interface that has been with the iPod since it first came out would, in the eyes of a great many iPod users, be tantamount to dropping the iPod. I and most other iPod users I know like our iPods because I find it easier to work with than other mp3 players, not because Apple makes it. Apple is pretty full of hubris, but I doubt they're _that_ full of hubris.
ARRRRGH yourself.
Do you seriously believe that an iPod that is primarily devoted to video has no cause to be considered a different product from the one that is devoted to music? I'd say it gets more cause than, say, an iPod that's pretty much the exact same thing only in a different form factor (like, say, the regular vs. the mini).
I read your comment fully. I just assumed you weren't being 100% dense about this and might just be going off of a less-than-complete knowledge of the whole iPod product line.
Hmm. I see someone else modded this post insightful, which is interesting. I would have modded it funny; the essay didn't really go anywhere so I can't see how it was meant to be anything but a satire of the attitudes of men who lack the backbone to define themselves however the hell they want and instead must cling to "safe" ideas like the manly man.
And then I start surfing the rest of the site, and it becomes clear to me that this guy might be serious. But I really can't tell. Everything seems like a caricature of the archetypical man-child, but nothing goes quite overboard enough for me to be entirely sure.
But I think I'm going to stick with thinking this is really meant to be a joke. Or maybe Kim du Toit isn't joking, just pretending. He wants us to take him seriously, because he's trying to ride on Ted Nugent's coattails.
Since they first came out with two models of iPod (Mini and regular) and pretty much continuously since then.
I have a feeling you're spouting cool-kid party line more than anything. Yeah, Perl has Java on memory consumption. But Java beats Perl hands down on speed. As for transparency, well, I guess there's no accounting for taste, but I think this is far, far more readable than this.
Yeah, quite a numeric tower it has, eh?
They address this issue in the book's section on numbers.
It's a scripting language that was designed toward the end of the 20th century. It doesn't need all sorts of integers and whatnot. If you need to care that much about speed, memory consumption, etc, you shouldn't be using an interpreted language in the first place. In the domain for which Lua was designed, tall numeric towers are rice.
I agree that using rare languages is problematic, but it's not showstopping, and it's not an argument for not using them - after all, if using them were always a bad idea, we'd still all be stuck with nothing more than a few languages like FORTRAN and BCPL.
I question the idea that programmers not knowing the language is much of an issue - for the most part, all languages use variations of the same C-like syntax with only a few break-aways such as Smalltalk, Lisp, or FORTH. Besides, there are plenty of programmers with minds flexible enough to learn new languages; lots of hackers like to learn them for fun.
The debugging issue can be a bother, but ideally the border between the bits written in a each language are well-defined enough that you can mostly debug each model separately and use techniques other than stepping through code with a debugger to handle the boudary cases. Besides, I'd argue that a debugger should be the absolute last line of defense in minimizing bugs. In my personal experience, multi-language development tends to be easier to write without bugs in the first place because it demands more careful design, which makes just jumping into the code without much of a plan a lot less tempting, and time spent debugging stuff like this seems to actually be shorter. I'd certainly hope that's the case, because a quick survey of new software and projects suggests that multi-language is rapidly becoming a standard way to handle large projects.
There's a lot limiting how much a language can really get refactored - for one, there's the urge to maintain backward compatibility. This is a pretty strong pull on languages, to the point that seven years after C99 I'm still not aware of a commonly-available compiler that implements it - and at least in the case of gcc it looks like backward compatibility is one of the major reasons this hasn't happened yet. Also, I'm really not aware of any major language refactorings aside from FORTRAN and Common Lisp. Usually what happens is that someone instead creates a new language that is similar to one or more other languages, but with (what the author thinks are) syntax improvements, and then the whole thing gets pushed as a new language. This is how Sheme relates to Lisp, C to B, Java to C++, etc.
Also, it's really not fair to characterize all rare languages as not being notably superior to existing languages. In the current case, a quick look around the other comments on this page will give you a long list of things that make Lua really stand out as a language. These comments come from people who actually know Lua, and probably know how to read all the major languages and have written a few lines of code in most of them. Meanwhile, judging from the generalities you're using, I'd be inclined to guess that you don't actually know a whole lot about Lua and therefore are mostly just asuming that its existence is somehow harmful based on nothing more than the observation that it exists.
The grandparen't wasn't saying that Lua's speed on these benchmarks alone is why Lua is the greatest language or anything. However, it does make Lua worth caring about. There are plenty of other reasons to like it - it's a fairly clean language, and in situations where maintainability matters it's probably preferable for a lot of people who don't like, say, perl's terseness and tangled syntax. It's a reflective language, which makes it useful for some more complex tasks than some other scripting languages.
Of course these aren't reasons why Lua is categorically better than other languages - perl is my first choice whenever I need an extraction and reporting language, C is still my first choice when performance matters, ObjC when performance matters a bit more but not as muc as in C (though in both those cases it's common for me to be working with an embedded scripting language, too), C++ if the gods turn sour on me and I end up having to be able to work with C++ libraries, postscript for dicking around in printers, etc.
I hate to burst your bubble, but if C++, Perl, Python, and Java are really such solid languages that there's no reason why any programmer would want anything else, then the world is screwed. Furthermore, adding new features to existing languages really isn't the solution - that path leads to madness, to kitchen-sink monstrosities like C++ and Perl. Both of them have traveled so far beyond the pale that their creators have admitted the desire to more or less start over and make a cleaner language that does the same thing.
.Net and the reason why Mono started - with an environment where you can write different modules in different languages and not have to care quite so much about the boundaries between them, you really are free to use the best tool for the job. This is also why embedded languages are getting so popular - yeah, I can do everything I need to do in ObjC, but damn is it nice to be able to save myself a crapload of time by doing all the "big picture" work in something like Lua or F-Script. Nor do I find either to be an irritant - F-Script produced a drastic improvement in my productivity and the maintainability of my code, and now that I'm learning Lua I'm loving it for similar reasons. I'll probably keep using both because each is best for slightly different things.
While I know this is a strained metaphor, when you're trying to do serious work a box of tools is better than a swiss army knife. That's part of the genius behind
Lua is definitely more portable, and it's easier to get it to talk to other languages. I had originally looked at Guile for my current app (which does the heavy lifting with Objective-C), and decided against. Judging from the small number of Guile bridges, it looks like Guile doesn't play so nice with languages that aren't substantially similar to C, and even then there seem to be a lot of conditions and complications floating along the boundary between it and C.
Lua, on the other hand, is happy to run on anything from mainframes to toasters. It also has a number of existing bridges, many fewer of which seem to have been orphaned by their maintainers.
The language itself is a solid alternative to Sheme, too: It has enough functional-y features (first class functions, closures, reflection, etc.) to keep me happy, while also being designed well enough to handle other programming styles without getting unwieldy. It's really rather similar to Sheme in that it's a small language with just enough of a feature set to make you do large things. It does other things more nicely, too - implementing an ADT with tables involves a whole lot less boilerplate code than doing it with lists, for example.
It goes the other way, too. Last I checked, Dell computers are generally regarded as being pretty horrible from a reliability perspective. Despite all the noise that consumers make, Apple computers tend to be pretty solid. (Very solid if you never buy rev. A hardware from them.)
The most densely populated city anywhere near me is Chicago. Chicago has lots and lots of room to grow. The city proper is pretty dense, but you can always knock down two-flats and build larger apartment complexes. What really needs to happen, though, is for someone to tear up all the wasted space that was created by the suburban fetish for asphalt and start doing something useful with that 60-mile-radius wasteland that surrounds the city.
Is there a name yet for "The enjoyability of the game is inversely proportional to its graphic design and art budget"?
That would make maintenance easier for the KDE and GNOME teams, but it wouldn't create a situation that is functionally different for application developers. Much better to just completely migrate to Portland. (Of course, re-implementing the old stuff to use Portland might be a great intermediate step in the process.)
While I've heard that argument many times, as a longtime Slackware user who's used to having only what I want in my distro, I've found that that simply isn't how it works in the real world.
The problem is that every application developer chooses their own set of libraries to use, so that to use X image editor I need to install libraries A, B, and C. But then I decide to install Y media player, and find that to get it working I need to install libraries D, E and F, plus add a second audio interface to my kernel. Incidentally libraries D and F are analogous to libraries B and C. And the situation just keeps snowballing as I add more applications to my computer. Eventually I'm left with a huge pile of overlapping functionality, I'm forced to keep multiple versions of various libraries floating around, my kernel has just about everything under the sun compiled in, etc.
I suppose that if I really wanted to I could choose a lean, well-selected set of libraries and features for myself and then proceed to only use applications that work with all of that. But I live in the real world.
You do realize that, despite a lot of pedantic noise made by a few people like RMS, the word "Linux" is commonly used as shorthand for an entire family of operating systems based on the Linux kernel, and that for most everybody concerned the desktop environment is an integral part of any Linux install for workstation and desktop computers?
I assume you do, since you know enough about it to know that yes, technically, Linux is a kernel. Which means I have reason to think you understand what I was say and know that your response is pretty well beside the point.
Right. This only makes sense from any standpoint if Portland replaces the existing interfaces in KDE and GNOME. But of course that can't be done right away because there are too many apps that rely on them.
My guess is that, if all goes well, the situation you're talking about will just be some growing pain until the next major releases for KDE and GNOME, when they can force everyone to upgrade their code.
But the reality is probably that, since this is the FOSS community we're talking about, neither of the old sets of functions will be dropped for a good long while because somebody has developed a codependent attachment to them and won't let them go. That or just because it's a job that nobody really wants to do. Either way, Linux will continue to bloat and bloat and bloat until the end of time.
(disclaimer: not trying to characterize filesystem developers or pass judgmement on Hans Reiser, just being pedantic)
I was wondering why some guy smart enough and sane enough to develop a filesystem would go and murder his wife.
You certainly have to be smart to develop a filesystem, but what does sanity have to do with it? Personally, I'm of the opinion that there are a number of personality traits that your average psychologist would consider to be less-than-great but which are a huge boon for a filesystem developer. Compulsive tendencies, introversion, and possibly even a touch of psychopathy could all help someone stick around at the keyboard twiddling tiny little uncooperative bits and bytes without being driven mad.
Furthermore, there are lots of different kinds of smarts. Being a good software engineer doesn't translate into being able to weigh the consequences of one's actions, or having the ability to manage one's emotions, or accept hardship and hurt with grace, or anything like that.
I severely doubt that his being the developer of ReiserFS has much at all to do with this situation.
I get really sick of this particular snipe. It doesn't contribute anything useful to the conversation, and mostly serves as a low blow because most of us lack decent access to journal articles. Furthermore, the argument is essentially self-contradictory because it hinges on the idea that an idea is wrong if the person who suggested it doesn't have a list of journal articles in hand so they can back it up when someone responds with "OMFG teh PEER REVIEW!!!!111!!1!!" It's a painfully obvious logical fallacy, and the hurt is only increased when you put it in the same sentence as language about scientific studies.
If you really want to bring peer-reviewed research into the debate, why don't YOU do some legwork of your own and respond with some evidence that killers are wracked by guilt?
(And mods, what's interesting about the parent post? It only takes a short time on internet discussions to see about a millionty-five one or two sentence posts that are almost identical to this one. It's not interesting, it's banal.)
While I have to agree that SQL can be an annoying language, I have to wonder what you have against a textual querying language.
The only real alternative to text that I can think of would be some sort of drag-and-drop system for creating queries with flowcharts or something like that. But there are two big hits against that idea. First, it wouldn't work well with any major programming languages, all of which are textual. Second, I've done some work with that kind of scheme for writing programs - I've even created my own mini graphical programming language - and so far I have yet to meet one that isn't either extremely limited or hard to work with. Which isn't to say that a decent graphical language is impossible, just that the state of the art isn't nearly up to snuff yet.
If I wanted to tech my child programming, I'd start with Scheme. Here's why:
- I hate loops
- I hate variables
- I hate kids
You lucky bastard. I used to have to make do with the empty set. We didn't even have successor sets back then!
Back in day, no fancy pronouns! And!
I'd differ with you in that I've found cases where an undocumented but fully implemented API can be almost useless if the source isn't available or is poorly commented. I can think of a couple cases at work where I've tried to use a library that was written by somebody who is no longer around, and found that it was so arcane that after spending several days of trying to make sense of a commentless and overcomplicated pile of over-abbreviated function names and single-letter variables for the sake of making my boss happy by using existing code, I finally gave up and rolled my own code (this time with documentation) in a day or two.
Yeah. Tubes.