Have you ever used a system that was based on packages other than RPMs? It seems like a lot of Slackware users formed their only opinions of non-Slack distros back in the mid-1990s, when Debian was comatose and Red Hat was the only other option.
From which point in my post are people assuming I think GOTOs are evil?
From the context of a 40-year-old free-floating flamewar over the topic of gotos, which reignites every time the construct is mentioned, even in passing. It is one of the hardiest perennials in programming discourse.
OK, so how do you handle deallocation of resources upon finding an unrecoverable error midway through the function? It seems a lot more readable and maintainable to have all deallocation code in one location near the end of the function, as opposed to duplicated wherever an error might be found, which means at least one copy of the code is likely to be wrong, or shunted off into its own function, which would force all of the local variables holding dynamic resources to be made into globals or similar.
So formatting is worthless, then? And why do we have so many languages, many of them domain-specific? Compilers don’t care about how understandable the metaphors are or how many lines are needed to do a specific thing.
decent languages support labeled for/while cycles and apropriate "break label" constructs.
You often cannot develop software with the language you want, but must develop it with the language you have. C has no such features and, therefore, goto is used more often than in languages that have them. Fit the strategy to the tool.
if you do this kind of thing, you are MUCH better off separating lookup code to method or function
This is reasonable, but it assumes some other function can do the needed cleanup code or other data massaging just as cleanly. If the goto is being used because finding the value is an error condition, you often have to do certain things as soon as possible in the code so you do not lose important debugging information.
And, no, exceptions are not part of C, and setjmp/longjmp is, if anything, even less likely to pass code review. An advantage of goto is that you can keep the cleanup code in the same function, visually close to the rest of the logic and sharing the same locals.
I’m a goto-user, but this is a bad reason to use them: If you regard language features as ‘just’ syntactic sugar, why aren’t you programming in raw machine code? That is what everything eventually gets turned into anyway.
You use gotos when the normal control structures are inadequate somehow. It doesn’t matter what the compiler does; source code is for humans.
Breaking out of a deeply-nested loop, as can happen when you’re looking for a specific element in a multidimensional array. The alternative involves adding state variables and complicating the logic terribly.
The Internet is all about price. As you point out, quality is meaningless. If it isn't free, it is going to garner only a fraction of the interest.
I disagree. I think both iTunes and the experiences of Radiohead and Trent Reznor disprove this statement.
I think this article sums it up reasonably well: "The Great Apathetic Revolution". In summary, people will do whatever is easiest as long as it isn't absolutely insanely expensive. iTunes makes it easy to pay $0.99/track, so people do that. It's easier than finding what they want on the torrent sites. It's also easier than finding and buying the album that has the song they want, which is why Sony gets so jihaddy at them.
Today we have "clever hackers" getting their content for free and "noobs" paying the fare for everyone.
This is true. It isn't fair, but it's less unfair than it used to be: It's easier for a poor person to become clever than to become rich. The Digital Divide is self-imposed to a larger degree than previous divides have been.
The obvious solution is to block or severely slow down all encrypted traffic (that is, all traffic the ISP can’t interpret). This would have the obvious effect on online banking, which could be solved by the ISP’s computers handling it: The SSL tunnel stops at your ISP, which inspects the decrypted packets before handing them to you. You know the ISP isn’t going to do anything bad with the information because they told you so (in specific, there’s both a contract and fraud laws stopping them). This might hinder the adoption of new streaming video codecs and the like, but it’s a small price to pay for increased profits.
Hitler came to power because he had a street gang, called the Brownshirts, ensuring he would. The existing Weimar government was “blind in the right eye”, meaning it came down hard on left-wing gangs but ignored right-wing gangs like the Brownshirts. Hitler’s rise to power came because the existing German government was broken and allowed intimidation to beat (literally) democracy.
But this information will never make much of an impression on people because people need A Moral Lesson. The Moral Lesson here, apparently, is “voting is evil”.
BBSes were local because that was the only affordable option.
Ditto Internet message boards, only precisely in reverse: They’re run on advertising and (in some cases) paid subscriptions, and the only way to do that is to make them as geographically wide-ranging as possible.
There's nothing inherent about a BBS that requires it to be local
There’s nothing inherent about the Internet that requires it to be global. My point is that they were local and the Internet is global, and to ignore that is to ignore one of the most salient features of the BBS world.
If their local nature was an inherent part of BBSes, then why did software authors try to overcome that? (For instance, networking the message boards of different BBSes together, propagating the messages with a nightly dial-out script...)
Yes, I’m aware of Fidonet and other efforts of that type. But the BBS world never completely broke out of the ‘local board with local callers’ mold. The Internet left it behind without so much as pausing. Perhaps ‘inherent’ was the wrong word, however.
You've obviously forgotten the whole point of a BBS: It's local to a specific area, usually designated by an area code. This locality is enforced by the fact long-distance calls were really expensive back in the day and you could only make so many before breaking your (parents') bank. The Internet, even back in the old days, was not local and the BBS users of that era realized that. There was no cohesion around area codes or even general regions of the country. The BBS users of that era knew that the Internet would kill the local aspect of networking, and some of them even predicted the death of the Internet because of that.
Dial-up BBSes still exist, but when's the last time you called one? When's the last time you saw one advertised? Are there any running in your area code?
(The limited hours of operation and the limited number of phone lines are also part of the whole experience but the local flavor is essential. Telnet shell accounts, even the ones with ANSI that call themselves BBSes, lack that, even if they replicate the other features.)
And a resounding cry of "So what?" goes up from the huddled geek masses.
This is purely down to Apple having enough money to get the Open Group to administer the relevant tests. Everyone who understands this stuff knows NetBSD, FreeBSD, OpenBSD, and even Linux are more Unix than Mac OS X will ever be in terms of both philosophy and technical details, but nobody connected to any of those projects has both the money and the incentive to get a specific version of those certified so they remain officially "Unix-like" in every context where you have to worry about Rabid Attack Lawyers.
Presumably, Apple has some reason for doing this. I don't pretend to understand what. It isn't the kind of thing that would appeal to their core demographic (iPod kids and Photoshop hacks) and they know Mac OS X doesn't have the technical chops to compete in real-world server farms where being SUS-compliant means being able to run lots of pre-existing software.
I'm probably wrong. Apple isn't known for being stupid. This just doesn't make a lot of sense to me.
If it doesn't, it isn't a replacement for Perl. It might be a replacement for PHP or Python or Ruby, but not Perl.
Perl's biggest advantage over everything else is that it has one huge repository of 99.9% of the modules you'll ever need. In fact, it's probably most useful to define Perl's domains of competence by listing what the modules in CPAN are capable of doing.
Perl has some interesting semantic and syntactic features. It probably brought regexes out of obscurity and neglect. But CPAN is its single killer feature.
Without CPAN, Perl isn't Perl. Without a CPAN equivalent, your language isn't a Perl alternative.
Here in Europe (Finland, to be exact), we can just go to our local library to read Mao's book. No forms of requests are neccessary.
At every little library in Finland?
This guy got harassed because the library he went to didn't have the edition of the Little Red Book he wanted, so it had to send out an Inter-Library Loan form to get it from another institution. If it had been on hand, he wouldn't have been bothered.
Everything is an x86 (except for high end IBM POWER and Sun SPARC workstations, which may be dying too; embedded machines don't count). The days of choosing from a wide range of platforms are dead.
First off, I disagree that embedded platforms 'don't count': You can do increasing amounts of cool stuff with things like cell phones and gaming consoles (which are practically non-IBM-clone PCs anyway at this point), a pursuit which even includes real hardware modifications (essentially a dead hobby in the card-centric PC world).
Second, the chips made by Intel and AMD are x86 in name and ISA only. 64-bit is already a reality (albeit an expensive one) for the average non-übergeek, and dual-core is either already available or will be shortly. SIMD ISAs have been a standard on-chip component for about a decade (give or take) and modern x86 chips have been RISC in CISC clothing for even longer.
Operating systems and environments are still improving (OS X is still adding nice features, and development with GNUstep still shows just how ahead NEXTSTEP was back in the day), but nothing's happening to the core of the operating system. Where is my exokernel OS? Heck, we don't really have a pure microkernel OS in wide usage now, and that's 80's research.
Again, it may well seem that way, but look beneath the POSIX-compatible surface and you'll find unsuspected complexity and, yes, innovation. Xen, something that either is an exokernel or simply acts like one, is going to be a standard part of new Red Hat releases quite shortly now. (Slashdot had an article on this yesterday or so.) Microkernels, while they don't seem to be practical in desktop systems, have generated plenty of research on important OS topics that can be applied to more conventional kernels. Loadable modules, anyone? Linux even has userland filesystems now (the FUSE project is in the official kernel now (2.6.14-rc1)). (As an aside, look at QNX if you want to see a real-world microkernel that even runs on a variety of non-x86 hardware, to boot.)
My point in all this is that things only stay the same on the surface, largely for compatibility reasons. Compatibility is a necessary evil in an industry as large as IT has become, but it does not preclude innovation. It simply forces it to areas just beneath the surface.
Someone Please Get Jack An Interview On Comedy Central. That Would Be So Much Fun to Watch.
Someone please teach this guy how to capitalize. This is so annoying to read.
More seriously, an interview between Jack "Mehoff" Thompson and Stewart or Colbert would be hilarious. Jack might try to throttle the person interviewing him, but isn't the senseless violence of the insane the foundation of American entertainment and what Jack's whole campaign is about?
(Jack Thompson: A Daffy Duck waiting for a Bugs Bunny.)
BeOS was interesting because it was a very graphical, easy-to-use (or so I've heard) media-centric OS that was based on a real preemptive-multitasking kernel with native support for the POSIX API and a good Unix-like CLI pre-installed. The kernel, to my knowledge, wasn't really Unix-like (it was a single-user OS) but it had Unix-like stability and (as I've mentioned) true multitasking.
Basically, it was MacOS X back when Apple's Macintosh was stagnating and losing serious ground to the Microsoft-centric PC world. It lost because Be, Inc. didn't think it needed to produce an Internet-ready OS until it was far too late.
(For a while, Be, Inc. thought Apple would buy their OS and make it the center of the next-generation MacOS. When Steve Jobs became head of Apple again, however, he brought the NeXT system with him and now MacOS X is basically NeXTSTEP on more competitive hardware and with a somewhat more familiar interface. There was serious bad blood between Be fans and Apple fans over this.)
There is nothing saying that Linux must fragment into two different OSes. It is perfectly possible for developers to build user-friendly interfaces onto fundamentally complex and technical software. Apple has been doing this, with varying degress of success, for twenty-one years now. (Arguably, they have been doing it somewhat longer, but the eight-bit Apple machines don't fit the current ideas of 'usable' or 'friendly'.) To pick a better example, the Internet itself is used by all kinds of determinedly anti-technical people all the time, and it was designed in the late 1960s as a military communications network that could survive a nuclear war.
I called the Internet a better example because Linux can learn from the Internet more than it can learn from Apple. The Internet now is still based on the same fundamental packet-switching technology as it was in the 1970s, but what we do with it now is vastly different. This works because the Internet is flexible and simple, and it works well when someone wants to try out a simple hacked-together protocol. HTTP and NNTP are both examples of this fact. TCP/IP, the core protocols, are almost completely system- and use-agnostic.
Unix is similar. Unix has been implemented on machines ranging from Cray supercomputers to 8088 microcomputers. It has user interfaces that go from the tersest, most primitive shell to the most bloated GUI Apple has ever called Aqua. The core has remained largely unchanged since 1969. Creating a user-friendly interface, and I do not consider any current GUI really friendly, should be more than possible without fracturing the foundation. Unix has seen more radical changes.
Yes. Re-invent the wheel. A wheel that weakly does something specialized languages do extremely well. Let me go get that hammer to do the welding while we're at it.
You're exactly right: Most languages have very weak support for that kind of dynamic, introspective, functional programming. It would be ugly in C, for example, and impossible in Fortran. (In theory, everything is possible in every Turing-equivalent language. But eventually you blow out all your tendons and have to be put in a madhouse.) You should always fit the language to the strategy.
Except when that would be even more painful. Calling system APIs from Lisp, for example, is getting a hell of a lot better on most systems from most Lisps, but there are systems where it's even more of a pain of the ass than coding up data-driven code in C. Perl and Ruby and Python have taken off because they've made it possible to use a moderately pleasant language without screaming in agony every time you need to touch an API, but very few of the specialized languages are that obliging on most systems.
So by all means advocate the right language for the job, but remember that the job may be more complex than you think.
Slashdot Mirror
Wikipedia uses Ubuntu now as its server OS. That should lay to rest any notion of Ubuntu being technically inferior to any other distro.
Have you ever used a system that was based on packages other than RPMs? It seems like a lot of Slackware users formed their only opinions of non-Slack distros back in the mid-1990s, when Debian was comatose and Red Hat was the only other option.
From the context of a 40-year-old free-floating flamewar over the topic of gotos, which reignites every time the construct is mentioned, even in passing. It is one of the hardiest perennials in programming discourse.
OK, so how do you handle deallocation of resources upon finding an unrecoverable error midway through the function? It seems a lot more readable and maintainable to have all deallocation code in one location near the end of the function, as opposed to duplicated wherever an error might be found, which means at least one copy of the code is likely to be wrong, or shunted off into its own function, which would force all of the local variables holding dynamic resources to be made into globals or similar.
So formatting is worthless, then? And why do we have so many languages, many of them domain-specific? Compilers don’t care about how understandable the metaphors are or how many lines are needed to do a specific thing.
You often cannot develop software with the language you want, but must develop it with the language you have. C has no such features and, therefore, goto is used more often than in languages that have them. Fit the strategy to the tool.
This is reasonable, but it assumes some other function can do the needed cleanup code or other data massaging just as cleanly. If the goto is being used because finding the value is an error condition, you often have to do certain things as soon as possible in the code so you do not lose important debugging information.
And, no, exceptions are not part of C, and setjmp/longjmp is, if anything, even less likely to pass code review. An advantage of goto is that you can keep the cleanup code in the same function, visually close to the rest of the logic and sharing the same locals.
This is conceptually no different from goto, but I agree that it could be more intuitive for some people.
I’m a goto-user, but this is a bad reason to use them: If you regard language features as ‘just’ syntactic sugar, why aren’t you programming in raw machine code? That is what everything eventually gets turned into anyway.
You use gotos when the normal control structures are inadequate somehow. It doesn’t matter what the compiler does; source code is for humans.
Breaking out of a deeply-nested loop, as can happen when you’re looking for a specific element in a multidimensional array. The alternative involves adding state variables and complicating the logic terribly.
I disagree. I think both iTunes and the experiences of Radiohead and Trent Reznor disprove this statement.
I think this article sums it up reasonably well: "The Great Apathetic Revolution". In summary, people will do whatever is easiest as long as it isn't absolutely insanely expensive. iTunes makes it easy to pay $0.99/track, so people do that. It's easier than finding what they want on the torrent sites. It's also easier than finding and buying the album that has the song they want, which is why Sony gets so jihaddy at them.
This is true. It isn't fair, but it's less unfair than it used to be: It's easier for a poor person to become clever than to become rich. The Digital Divide is self-imposed to a larger degree than previous divides have been.
The obvious solution is to block or severely slow down all encrypted traffic (that is, all traffic the ISP can’t interpret). This would have the obvious effect on online banking, which could be solved by the ISP’s computers handling it: The SSL tunnel stops at your ISP, which inspects the decrypted packets before handing them to you. You know the ISP isn’t going to do anything bad with the information because they told you so (in specific, there’s both a contract and fraud laws stopping them). This might hinder the adoption of new streaming video codecs and the like, but it’s a small price to pay for increased profits.
Mine can. w3m displays images just fine in both xterm and rxvt if it's built to.
Hitler came to power because he had a street gang, called the Brownshirts, ensuring he would. The existing Weimar government was “blind in the right eye”, meaning it came down hard on left-wing gangs but ignored right-wing gangs like the Brownshirts. Hitler’s rise to power came because the existing German government was broken and allowed intimidation to beat (literally) democracy.
But this information will never make much of an impression on people because people need A Moral Lesson. The Moral Lesson here, apparently, is “voting is evil”.
Ditto Internet message boards, only precisely in reverse: They’re run on advertising and (in some cases) paid subscriptions, and the only way to do that is to make them as geographically wide-ranging as possible.
There’s nothing inherent about the Internet that requires it to be global. My point is that they were local and the Internet is global, and to ignore that is to ignore one of the most salient features of the BBS world.
Yes, I’m aware of Fidonet and other efforts of that type. But the BBS world never completely broke out of the ‘local board with local callers’ mold. The Internet left it behind without so much as pausing. Perhaps ‘inherent’ was the wrong word, however.
You've obviously forgotten the whole point of a BBS: It's local to a specific area, usually designated by an area code. This locality is enforced by the fact long-distance calls were really expensive back in the day and you could only make so many before breaking your (parents') bank. The Internet, even back in the old days, was not local and the BBS users of that era realized that. There was no cohesion around area codes or even general regions of the country. The BBS users of that era knew that the Internet would kill the local aspect of networking, and some of them even predicted the death of the Internet because of that.
Dial-up BBSes still exist, but when's the last time you called one? When's the last time you saw one advertised? Are there any running in your area code?
(The limited hours of operation and the limited number of phone lines are also part of the whole experience but the local flavor is essential. Telnet shell accounts, even the ones with ANSI that call themselves BBSes, lack that, even if they replicate the other features.)
And a resounding cry of "So what?" goes up from the huddled geek masses.
This is purely down to Apple having enough money to get the Open Group to administer the relevant tests. Everyone who understands this stuff knows NetBSD, FreeBSD, OpenBSD, and even Linux are more Unix than Mac OS X will ever be in terms of both philosophy and technical details, but nobody connected to any of those projects has both the money and the incentive to get a specific version of those certified so they remain officially "Unix-like" in every context where you have to worry about Rabid Attack Lawyers.
Presumably, Apple has some reason for doing this. I don't pretend to understand what. It isn't the kind of thing that would appeal to their core demographic (iPod kids and Photoshop hacks) and they know Mac OS X doesn't have the technical chops to compete in real-world server farms where being SUS-compliant means being able to run lots of pre-existing software.
I'm probably wrong. Apple isn't known for being stupid. This just doesn't make a lot of sense to me.
Does it have its own CPAN equivalent?
If it doesn't, it isn't a replacement for Perl. It might be a replacement for PHP or Python or Ruby, but not Perl.
Perl's biggest advantage over everything else is that it has one huge repository of 99.9% of the modules you'll ever need. In fact, it's probably most useful to define Perl's domains of competence by listing what the modules in CPAN are capable of doing.
Perl has some interesting semantic and syntactic features. It probably brought regexes out of obscurity and neglect. But CPAN is its single killer feature.
Without CPAN, Perl isn't Perl. Without a CPAN equivalent, your language isn't a Perl alternative.
At every little library in Finland?
This guy got harassed because the library he went to didn't have the edition of the Little Red Book he wanted, so it had to send out an Inter-Library Loan form to get it from another institution. If it had been on hand, he wouldn't have been bothered.
The Bible may be your manual, but it is not mine.
First off, I disagree that embedded platforms 'don't count': You can do increasing amounts of cool stuff with things like cell phones and gaming consoles (which are practically non-IBM-clone PCs anyway at this point), a pursuit which even includes real hardware modifications (essentially a dead hobby in the card-centric PC world).
Second, the chips made by Intel and AMD are x86 in name and ISA only. 64-bit is already a reality (albeit an expensive one) for the average non-übergeek, and dual-core is either already available or will be shortly. SIMD ISAs have been a standard on-chip component for about a decade (give or take) and modern x86 chips have been RISC in CISC clothing for even longer.
Again, it may well seem that way, but look beneath the POSIX-compatible surface and you'll find unsuspected complexity and, yes, innovation. Xen, something that either is an exokernel or simply acts like one, is going to be a standard part of new Red Hat releases quite shortly now. (Slashdot had an article on this yesterday or so.) Microkernels, while they don't seem to be practical in desktop systems, have generated plenty of research on important OS topics that can be applied to more conventional kernels. Loadable modules, anyone? Linux even has userland filesystems now (the FUSE project is in the official kernel now (2.6.14-rc1)). (As an aside, look at QNX if you want to see a real-world microkernel that even runs on a variety of non-x86 hardware, to boot.)
My point in all this is that things only stay the same on the surface, largely for compatibility reasons. Compatibility is a necessary evil in an industry as large as IT has become, but it does not preclude innovation. It simply forces it to areas just beneath the surface.
Someone please teach this guy how to capitalize. This is so annoying to read.
More seriously, an interview between Jack "Mehoff" Thompson and Stewart or Colbert would be hilarious. Jack might try to throttle the person interviewing him, but isn't the senseless violence of the insane the foundation of American entertainment and what Jack's whole campaign is about?
(Jack Thompson: A Daffy Duck waiting for a Bugs Bunny.)
BeOS was interesting because it was a very graphical, easy-to-use (or so I've heard) media-centric OS that was based on a real preemptive-multitasking kernel with native support for the POSIX API and a good Unix-like CLI pre-installed. The kernel, to my knowledge, wasn't really Unix-like (it was a single-user OS) but it had Unix-like stability and (as I've mentioned) true multitasking.
Basically, it was MacOS X back when Apple's Macintosh was stagnating and losing serious ground to the Microsoft-centric PC world. It lost because Be, Inc. didn't think it needed to produce an Internet-ready OS until it was far too late.
(For a while, Be, Inc. thought Apple would buy their OS and make it the center of the next-generation MacOS. When Steve Jobs became head of Apple again, however, he brought the NeXT system with him and now MacOS X is basically NeXTSTEP on more competitive hardware and with a somewhat more familiar interface. There was serious bad blood between Be fans and Apple fans over this.)
Don't you mean reir? ;)
There is nothing saying that Linux must fragment into two different OSes. It is perfectly possible for developers to build user-friendly interfaces onto fundamentally complex and technical software. Apple has been doing this, with varying degress of success, for twenty-one years now. (Arguably, they have been doing it somewhat longer, but the eight-bit Apple machines don't fit the current ideas of 'usable' or 'friendly'.) To pick a better example, the Internet itself is used by all kinds of determinedly anti-technical people all the time, and it was designed in the late 1960s as a military communications network that could survive a nuclear war.
I called the Internet a better example because Linux can learn from the Internet more than it can learn from Apple. The Internet now is still based on the same fundamental packet-switching technology as it was in the 1970s, but what we do with it now is vastly different. This works because the Internet is flexible and simple, and it works well when someone wants to try out a simple hacked-together protocol. HTTP and NNTP are both examples of this fact. TCP/IP, the core protocols, are almost completely system- and use-agnostic.
Unix is similar. Unix has been implemented on machines ranging from Cray supercomputers to 8088 microcomputers. It has user interfaces that go from the tersest, most primitive shell to the most bloated GUI Apple has ever called Aqua. The core has remained largely unchanged since 1969. Creating a user-friendly interface, and I do not consider any current GUI really friendly, should be more than possible without fracturing the foundation. Unix has seen more radical changes.
Sorry, I don't want to get sued by SCO. It's cheaper to pay them $699 and run Linux. ;)
You're exactly right: Most languages have very weak support for that kind of dynamic, introspective, functional programming. It would be ugly in C, for example, and impossible in Fortran. (In theory, everything is possible in every Turing-equivalent language. But eventually you blow out all your tendons and have to be put in a madhouse.) You should always fit the language to the strategy.
Except when that would be even more painful. Calling system APIs from Lisp, for example, is getting a hell of a lot better on most systems from most Lisps, but there are systems where it's even more of a pain of the ass than coding up data-driven code in C. Perl and Ruby and Python have taken off because they've made it possible to use a moderately pleasant language without screaming in agony every time you need to touch an API, but very few of the specialized languages are that obliging on most systems.
So by all means advocate the right language for the job, but remember that the job may be more complex than you think.