Imho, case-sensitivity was in general, one of the worst ideas the computer science world ever produced.
Case sensitivity wasn't an idea people developed, it's the default you get out of string comparisons: the ASCII codes for "A" and "a" are just different. In order to get case insensitivity, you need a lot more machinery in order to determine whether two strings are "the same". It may look trivial to you, but it isn't in real life, in particular, once you get to other languages (in some languages, the length of a string changes with capitalization).
So, people use case sensitivity because it is simple and straightforward to explain and the alternatives are much worse.
I thought the problem was that Microsoft told everybody that they didn't have any patents on C# or.NET, but they are actually a licensee of somebody else who has patents on it?
Well, let's be precise. C# and.NET are two different things.
C# is an ECMA standard with features that are found in dozens of other languages. There is no indication that there is anything patentable about it. In fact, if you look at the C# specification, it is clear that they have been careful to avoid patents that Sun owns on Java (yes, Java is patent encumbered).
Then there is.NET. It is a huge collection of APIs, many of them Windows specific. In a trial balloon, Microsoft has attempted to patent the totality of those APIs. What the significance of that patent is going to be isn't clear--it may not be worth the paper it is written on.
So, what's the upshot of it all? You can't avoid the risk of patent infringement no matter what language you use. However, at this point, it is pretty clear that C# exposes you to no greater risk than other languages. As for.NET, you don't have to use it: most open source applications developed in Mono are written using the Gnome APIs, not the.NET APIs.
It's not an ideal world, but if you want a reasonably popular and practical natively compiled language with garbage collection and reflection, your choice basically comes down to C# and Java. Java is completely owned by Sun: Sun owns the specifications, Sun holds many patents on it, and Sun effectively can control who may implement Java and who may not (they have chosen not to exercise that control vis-a-vis implementations like gcj and classpath yet, but if they want to, they can). C# may not be the ideal choice, but it's the best you are going to get.
Once again, for 0.1% of the cellphone-using population (i.e. the fanatical Linux zealots), this may be a major issue, but Joe Sixpack doesn't know/care what Linux is.
You are quite right: users don't care what the toolkit is. They care about size, battery life, performance, ease of use, and choice of software. So do I, in fact. Unfortunately, Qtopia affects all of those negatively relative to other possible GUIs on top of Linux. In the end, the dominance of Qtopia for Linux PDAs/phones may well mean that people will continue to buy mostly Palm and PocketPC-based devices.
Well, at least Palm is switching to a Linux kernel, and unlike Qtopia, their user interface doesn't suck. So, Linux may yet live on PDAs.
Many current phones allow users to install applications. Java is probably the most popular for that purpose right now. What could give Linux phones a big advantage is the large number of applications and tools that exist for the platform already.
It's good to see Linux on more phones. But the dependence on Qtopia is worrisome. Unlike Qt on the desktop, where Qt applications can run alongside applications written in other toolkits, Qtopia takes over the display: the only way you can write applications for these devices is by using Qt/Embedded.
That's a good deal for Troll Tech, who gain lots of Qt developers if Qtopia catches on. It's not such a good deal for users, because their choice of toolkits and applications is greatly restricted, and because Qt/Embedded is not a particularly efficient toolkit. Furthermore, the PIM applications that Qtopia ships with simply are nowhere near as good as those on Palm (I have had several Sharp Zaurus PDAs and I wouldn't want to use them as a PDA). It's unfortunate that Linux's first shot at the PDA and phone market is hampered by Qtopia.
I just read the committee's report on the book and the author's response. There is no evidence that the author committed fraud (i.e., intentionally falsified data)--the committee says so. What he did do is advance a controversial thesis based on sloppy data collection. That warrants a harsh response in a professional journal, no more. Instead, the guy got torn apart by the gun lobby, who got people like you to believe that he committed fraud.
Whether his theory is true, we will never know, because no other historian is going to spend any amount of time collecting the data again, only to risk his job and reputation when publishing the results.
No, I was not referring to any book. The book you mentioned disputes that people owned guns. I don't know what the level of gun ownership was, but it's pretty clear that their attitudes differed from that of your typical NRA member today.
The problem isn't getting rid of CO2 (we can do that already), it's capturing it prior to release. Tailpipes, fires, etc. don't release CO2 in neat little packages.
We have a government that does pretty much what we tell it because we have two guns for every three citizens and a tradition of cleaning house when needed.
You mean the American revolution? As far as democratic change goes, that was a pretty lightweight and recent effort. Nations like France fought long and hard for democracy, other nations in Europe have had a tradition of democracy going back a thousand years, and yet others had democracies and lost them again. America is a newcomer in the area of creating and maintaining democratic government, and there is no support for the view that America's gun policies are responsible for the current existence of democracy in the US, in particular since attitudes towards guns and gun ownership were altogether different around the time of the American revolution.
Well, then it's not the cell architecture that speeds it up, but the increased memory bandwidth. You can expect that a more traditional(perhaps multi-core) Intel or AMD chip will likely come out soon with similar memory buses and similar perforance.
A longer pass phrase consisting of correctly spelled words and a shorter cryptic password both are likely going to have roughly the same information content and are therefore equivalent from a cryptographic point of view.
This "technology" is a few millenia old. Sure, maybe it uses different materials and robots instead of people now to lay down the contours, but it's still the same method. And people have built pretty wild shapes out of bricks over the last few thousand years.
What has Microsoft done that other small and large corporations don't also do?
Succeeded at monopolizing a huge market. Many companies may be dreaming of that, but few are succeeding.
The point is, if you're going to insult someone who works for Microsoft, then you might as well snub others for working for Apple, Sun, IBM, Philips, GE, Verizon, Dow, Monsanto, etc, etc. Before you know, you won't even be able to walk into a bar for fear of meeting someone.
Actually, small and medium sized businesses are the backbone of the economy, not these corporate black holes, and he won't be running out of people to meet.
But, in any case, it probably is better to talk to employees of those companies about their companies and make them politely aware both of the impression their company makes and what their role in it is. If it turns out that they are firm believers in the company vision for world domination, then you can still politely excuse yourself and leave.
If you've ever done some detailed algorithm work, you will quickly realize that there are many algorithms where you can make tradeoffs between memory and CPU time.
No, sorry, it doesn't work that way. It isn't the total amount of memory that the algorithm uses that matters, it's locality of reference And people already maximize locality of reference in their performance critical implementations because it already pays back handsomely on current processors.
Unless you are computing digital orreries, whether it has 256GFlops or 256TFlops makes little difference if the memory bandwidth isn't substantially increased, and people don't increase the memory bandwidth because that has expensive consequences all over the system.
On the whole, my impression is that current mainstream CPUs have a pretty reasonable balance between CPU power and all the other system components. Changing just the CPU without making substantial (and expensive) changes to the rest of the system will not magically give you more performance.
While Lisp is nice and interesting, its also rather limited in terms of choice, you either have to do it the Lisp-way or don't do it at all
Lisp has historically had many syntactic frontends, and it would be easy to put a Perl or Python parser in front of it. In fact, Lisp started out using M-expressions, a vaguely Algol-like notation. Why aren't people using those? Because anybody who spends any time using them quickly comes to the conclusion that it's easiest just to use S-expressions.
Parrot turns out well it might end up uniting all the scripting languages out there,
The goal itself is flawed.
but again Perl and friends offer you choice about the environment,
You mean the choice of editing Perl in Notepad and editing Perl in vi? Where is the "choice" in that?
People like freedom, people like doing it there way. Smalltalk and Lisp simply force far to much into doing things their way.
And what "freedom" does Perl give me? The "freedom" to choose among three different ways of accessing arrays or objects, none of which make much sense? Perl's "freedoms" are meaningless syntactic variations; Lisp gives you real control over both syntax and semantics.
The intended purpose of trademarks was to give consumers a reliable way of identifying a product. However, identification is not the same as control. When I search for a trademarked name, it is entirely appropriate to get information about competing products, as long as it is clear that those competing products are different from the product I was looking for. Likewise, it is entirely appropriate to report bad experiences with a trademarked product using the trademark--the trademark is there for identification, not just for advertising.
Limiting the use of trademarks only to communications that the trademark owner likes and approves of is bad for consumers and really contradicts the purpose of trademark law. Trademarks were intended as a protection for buyers, not as an advertising vehicle for corporations.
Actually, the primary U.S. Army artillery fire control system is written in Ada.
If you throw enough money at it, you can write anything in almost any language. People managed to do this in Ada, but that doesn't mean that Ada was a "reasonable" choice. Depending on their requirements, I would argue that there were almost certainly simpler, cheaper, and better-supported options than Ada.
(Mind you, I don't think everything in Ada is bad; the language is a bit safer than C++, but Ada really does look like Pascal's $5000 toilet seat.)
It's great that Google put in the hard work to make this work. But, really, the underlying browser technology for this sort of thing is just awful: it just shouldn't be that hard. In part, it's limitations in JavaScript. In part, it's lack of vector graphics and client-side graphics APIs.
I agree that you can argue that Perl syntax is convenient for writing "killer programs in just a few lines of code". But there are two other considerations: is it easy to learn, and is it error prone? That's where it falls short IMO.
If you want a quick and simple answer, you can't go wrong learning Python and/or C#: they are good, useful compromises between language design and practicality and if you do anything with computers, you'll probably find a use for them at some point. And they support and teach what are generally considered good mainstream programming practices. (Python has excellent numerical support, by the way, and may be a reasonable alternative to MATLAB if you don't depend on toolboxes that aren't available for Python yet.)
It is perfectly fine, though, to stick with C and MATLAB as long as they work for you; programming languages are a means to an end, and everybody's needs are different. I was using MATLAB for many years even though I thought the language sucked, and I stopped using it only when the language actually started getting in the way too much.
If people point out that Microsoft is really just shipping proprietary versions of what amounts to commodity functionality (kernels, GUI toolkits, Java-like languages, etc.), he is going to make big claims about how "innovative" stuff like the NT kernel, Avalon,.NET, and WinFS supposedly are. If one points out to him that all of that already exists in other products and open source form, he is going to start talking about the billions of dollars Microsoft is investing in research (which they are) and the thousands of patents they are filing (which they are), and just conclude from that that their products must be innovative because, after all, Microsoft is spending so much money on innovation, so they must be delivering innovation. Never mind that Xerox, AT&T, and IBM have managed to demonstrate for decades that innovative research labs don't necessarily translate into a lot of innovative products.
I don't think there is much to be said between the open source community and Microsoft; they understand each other. Microsoft is trying to get away with setting proprietary standards for commodity functionality and staying filthy rich that way, and open source is trying to help users get what they want at a cost that is as low as possible. We'll have to see who wins in the long run; my bet is on market forces rather than monopolies, which means open source.
Slashdot Mirror
Imho, case-sensitivity was in general, one of the worst ideas the computer science world ever produced.
Case sensitivity wasn't an idea people developed, it's the default you get out of string comparisons: the ASCII codes for "A" and "a" are just different. In order to get case insensitivity, you need a lot more machinery in order to determine whether two strings are "the same". It may look trivial to you, but it isn't in real life, in particular, once you get to other languages (in some languages, the length of a string changes with capitalization).
So, people use case sensitivity because it is simple and straightforward to explain and the alternatives are much worse.
The prospect of GNOME becoming dependant was the straw that broke the camels back and made me switch to XFCE,
.NET APIs, they rely only on ECMA C#.
.NET patented API out of GTK!
.NET APIs in Gtk+; Gtk# is a Gtk binding for Mono, not the other way around.
The Gnome for Mono libraries don't use
keep the
There won't be any
And you better hope that Mono succeeds, becaues there is really not much else out there to develop the next generation of Linux desktop apps in.
I thought the problem was that Microsoft told everybody that they didn't have any patents on C# or .NET, but they are actually a licensee of somebody else who has patents on it?
.NET are two different things.
.NET. It is a huge collection of APIs, many of them Windows specific. In a trial balloon, Microsoft has attempted to patent the totality of those APIs. What the significance of that patent is going to be isn't clear--it may not be worth the paper it is written on.
.NET, you don't have to use it: most open source applications developed in Mono are written using the Gnome APIs, not the .NET APIs.
Well, let's be precise. C# and
C# is an ECMA standard with features that are found in dozens of other languages. There is no indication that there is anything patentable about it. In fact, if you look at the C# specification, it is clear that they have been careful to avoid patents that Sun owns on Java (yes, Java is patent encumbered).
Then there is
So, what's the upshot of it all? You can't avoid the risk of patent infringement no matter what language you use. However, at this point, it is pretty clear that C# exposes you to no greater risk than other languages. As for
It's not an ideal world, but if you want a reasonably popular and practical natively compiled language with garbage collection and reflection, your choice basically comes down to C# and Java. Java is completely owned by Sun: Sun owns the specifications, Sun holds many patents on it, and Sun effectively can control who may implement Java and who may not (they have chosen not to exercise that control vis-a-vis implementations like gcj and classpath yet, but if they want to, they can). C# may not be the ideal choice, but it's the best you are going to get.
Once again, for 0.1% of the cellphone-using population (i.e. the fanatical Linux zealots), this may be a major issue, but Joe Sixpack doesn't know/care what Linux is.
You are quite right: users don't care what the toolkit is. They care about size, battery life, performance, ease of use, and choice of software. So do I, in fact. Unfortunately, Qtopia affects all of those negatively relative to other possible GUIs on top of Linux. In the end, the dominance of Qtopia for Linux PDAs/phones may well mean that people will continue to buy mostly Palm and PocketPC-based devices.
Well, at least Palm is switching to a Linux kernel, and unlike Qtopia, their user interface doesn't suck. So, Linux may yet live on PDAs.
Many current phones allow users to install applications. Java is probably the most popular for that purpose right now. What could give Linux phones a big advantage is the large number of applications and tools that exist for the platform already.
It's good to see Linux on more phones. But the dependence on Qtopia is worrisome. Unlike Qt on the desktop, where Qt applications can run alongside applications written in other toolkits, Qtopia takes over the display: the only way you can write applications for these devices is by using Qt/Embedded.
That's a good deal for Troll Tech, who gain lots of Qt developers if Qtopia catches on. It's not such a good deal for users, because their choice of toolkits and applications is greatly restricted, and because Qt/Embedded is not a particularly efficient toolkit. Furthermore, the PIM applications that Qtopia ships with simply are nowhere near as good as those on Palm (I have had several Sharp Zaurus PDAs and I wouldn't want to use them as a PDA). It's unfortunate that Linux's first shot at the PDA and phone market is hampered by Qtopia.
I just read the committee's report on the book and the author's response. There is no evidence that the author committed fraud (i.e., intentionally falsified data)--the committee says so. What he did do is advance a controversial thesis based on sloppy data collection. That warrants a harsh response in a professional journal, no more. Instead, the guy got torn apart by the gun lobby, who got people like you to believe that he committed fraud.
Whether his theory is true, we will never know, because no other historian is going to spend any amount of time collecting the data again, only to risk his job and reputation when publishing the results.
No, I was not referring to any book. The book you mentioned disputes that people owned guns. I don't know what the level of gun ownership was, but it's pretty clear that their attitudes differed from that of your typical NRA member today.
100% functionality vs 100% open source. You pick open source, I pick functionality.
Well, I pick open source because it gives me the functionality I want and need, something OS X does not do.
I lost the ability to what, modify and recompile my programs. I still have access to all/most of the same programs, due to BSD+Fink, though.
I was trying to use Fink for a couple of years and finally gave up: it's too much hassle. Ditto for all the proprietary stuff Apple has put into OS X.
For people who want a UNIX or Linux system, OS X simply is not a good replacement.
The problem isn't getting rid of CO2 (we can do that already), it's capturing it prior to release. Tailpipes, fires, etc. don't release CO2 in neat little packages.
We have a government that does pretty much what we tell it because we have two guns for every three citizens and a tradition of cleaning house when needed.
You mean the American revolution? As far as democratic change goes, that was a pretty lightweight and recent effort. Nations like France fought long and hard for democracy, other nations in Europe have had a tradition of democracy going back a thousand years, and yet others had democracies and lost them again. America is a newcomer in the area of creating and maintaining democratic government, and there is no support for the view that America's gun policies are responsible for the current existence of democracy in the US, in particular since attitudes towards guns and gun ownership were altogether different around the time of the American revolution.
Well, then it's not the cell architecture that speeds it up, but the increased memory bandwidth. You can expect that a more traditional(perhaps multi-core) Intel or AMD chip will likely come out soon with similar memory buses and similar perforance.
A longer pass phrase consisting of correctly spelled words and a shorter cryptic password both are likely going to have roughly the same information content and are therefore equivalent from a cryptographic point of view.
This "technology" is a few millenia old. Sure, maybe it uses different materials and robots instead of people now to lay down the contours, but it's still the same method. And people have built pretty wild shapes out of bricks over the last few thousand years.
What has Microsoft done that other small and large corporations don't also do?
Succeeded at monopolizing a huge market. Many companies may be dreaming of that, but few are succeeding.
The point is, if you're going to insult someone who works for Microsoft, then you might as well snub others for working for Apple, Sun, IBM, Philips, GE, Verizon, Dow, Monsanto, etc, etc. Before you know, you won't even be able to walk into a bar for fear of meeting someone.
Actually, small and medium sized businesses are the backbone of the economy, not these corporate black holes, and he won't be running out of people to meet.
But, in any case, it probably is better to talk to employees of those companies about their companies and make them politely aware both of the impression their company makes and what their role in it is. If it turns out that they are firm believers in the company vision for world domination, then you can still politely excuse yourself and leave.
If you've ever done some detailed algorithm work, you will quickly realize that there are many algorithms where you can make tradeoffs between memory and CPU time.
No, sorry, it doesn't work that way. It isn't the total amount of memory that the algorithm uses that matters, it's locality of reference And people already maximize locality of reference in their performance critical implementations because it already pays back handsomely on current processors.
Unless you are computing digital orreries, whether it has 256GFlops or 256TFlops makes little difference if the memory bandwidth isn't substantially increased, and people don't increase the memory bandwidth because that has expensive consequences all over the system.
On the whole, my impression is that current mainstream CPUs have a pretty reasonable balance between CPU power and all the other system components. Changing just the CPU without making substantial (and expensive) changes to the rest of the system will not magically give you more performance.
While Lisp is nice and interesting, its also rather limited in terms of choice, you either have to do it the Lisp-way or don't do it at all
Lisp has historically had many syntactic frontends, and it would be easy to put a Perl or Python parser in front of it. In fact, Lisp started out using M-expressions, a vaguely Algol-like notation. Why aren't people using those? Because anybody who spends any time using them quickly comes to the conclusion that it's easiest just to use S-expressions.
Parrot turns out well it might end up uniting all the scripting languages out there,
The goal itself is flawed.
but again Perl and friends offer you choice about the environment,
You mean the choice of editing Perl in Notepad and editing Perl in vi? Where is the "choice" in that?
People like freedom, people like doing it there way. Smalltalk and Lisp simply force far to much into doing things their way.
And what "freedom" does Perl give me? The "freedom" to choose among three different ways of accessing arrays or objects, none of which make much sense? Perl's "freedoms" are meaningless syntactic variations; Lisp gives you real control over both syntax and semantics.
The intended purpose of trademarks was to give consumers a reliable way of identifying a product. However, identification is not the same as control. When I search for a trademarked name, it is entirely appropriate to get information about competing products, as long as it is clear that those competing products are different from the product I was looking for. Likewise, it is entirely appropriate to report bad experiences with a trademarked product using the trademark--the trademark is there for identification, not just for advertising.
Limiting the use of trademarks only to communications that the trademark owner likes and approves of is bad for consumers and really contradicts the purpose of trademark law. Trademarks were intended as a protection for buyers, not as an advertising vehicle for corporations.
But I like to have the originals in a lossless, archivable physical format.
I also still buy everything in CD format. Keep in mind, however, that CDs are not "archivable"--they degrade with time.
Actually, the primary U.S. Army artillery fire control system is written in Ada.
If you throw enough money at it, you can write anything in almost any language. People managed to do this in Ada, but that doesn't mean that Ada was a "reasonable" choice. Depending on their requirements, I would argue that there were almost certainly simpler, cheaper, and better-supported options than Ada.
(Mind you, I don't think everything in Ada is bad; the language is a bit safer than C++, but Ada really does look like Pascal's $5000 toilet seat.)
It's great that Google put in the hard work to make this work. But, really, the underlying browser technology for this sort of thing is just awful: it just shouldn't be that hard. In part, it's limitations in JavaScript. In part, it's lack of vector graphics and client-side graphics APIs.
I agree that you can argue that Perl syntax is convenient for writing "killer programs in just a few lines of code". But there are two other considerations: is it easy to learn, and is it error prone? That's where it falls short IMO.
If you want a quick and simple answer, you can't go wrong learning Python and/or C#: they are good, useful compromises between language design and practicality and if you do anything with computers, you'll probably find a use for them at some point. And they support and teach what are generally considered good mainstream programming practices. (Python has excellent numerical support, by the way, and may be a reasonable alternative to MATLAB if you don't depend on toolboxes that aren't available for Python yet.)
It is perfectly fine, though, to stick with C and MATLAB as long as they work for you; programming languages are a means to an end, and everybody's needs are different. I was using MATLAB for many years even though I thought the language sucked, and I stopped using it only when the language actually started getting in the way too much.
If people point out that Microsoft is really just shipping proprietary versions of what amounts to commodity functionality (kernels, GUI toolkits, Java-like languages, etc.), he is going to make big claims about how "innovative" stuff like the NT kernel, Avalon, .NET, and WinFS supposedly are. If one points out to him that all of that already exists in other products and open source form, he is going to start talking about the billions of dollars Microsoft is investing in research (which they are) and the thousands of patents they are filing (which they are), and just conclude from that that their products must be innovative because, after all, Microsoft is spending so much money on innovation, so they must be delivering innovation. Never mind that Xerox, AT&T, and IBM have managed to demonstrate for decades that innovative research labs don't necessarily translate into a lot of innovative products.
I don't think there is much to be said between the open source community and Microsoft; they understand each other. Microsoft is trying to get away with setting proprietary standards for commodity functionality and staying filthy rich that way, and open source is trying to help users get what they want at a cost that is as low as possible. We'll have to see who wins in the long run; my bet is on market forces rather than monopolies, which means open source.