You gain bonus points if you can actually prove we are not currently seeing a singularity. Some points to back that up:
1. Stock markets are traded algorithmicly, using, among others, genetic algorithms. 2. Most of our (digital) communication is analysed, scrutinized and profiled by algorithms. Social status, personal wealth and according to some, even happiness is partly influenced by this. These are basic elements of our identities which are slowly being taken over by hidden computations. Many of the design decisions behind these algorithms are made using genetic algorithms, advanced statistics and neural networks (either directly or indirectly). 3. Our world view is getting ever more shallow by priming news to individuals, not communities. A classical divide-and-conquer approach. Perhaps politically motivated, it could only be executed using feedback systems that operate on the semantic and contextual level. Partly, these systems are operated by humans, but it has been ever more automated over the last two decades by using language processing, knowledge bases and many other tools.
There are also points clearly opposed to the singularity. One point:
1. Many optimal solutions to advanced game theoretic problems have a provable double exponential time complexity, but have interesting heuristic solutions which human beings seem to be ideally suited for. Our genes, history, culture and memory are all tools which have been developed to test and solve these advanced game theoretic problems.
You're not sorry. You'll do it again the next opportunity.
It really pisses me off when people say they are sorry, while they actually aren't. It ruins the meaning of the word and makes people who are truly sorry left without words.
Interesting, it seems that nowadays we suddenly first have to put numbers into a pie chart, before we can see what percentage it has. This seems like primary school knowledge to me.
Your point does not hit the mark at all. It only takes a simple expected value measurement to bring statistics back into play. If every customer brings in 1 dollar but the jerk who hacks into your application will cost you 1 million dollars instead, then a 1 out of 10 billion chance is a chance to take. Statistics is a very valuable asset to any developer/systems architect.
And before you come up with an even more contrived example, I suggest you take a quick glance at fields such as decision theory, game theory or other utilitarian techniques to reassess your obvious lack of understanding of the subject.
I'm baffled. Here we use extensive extra documentation, mostly outside of the code. Programming changes are related to changes in design documents and deployment documents. Also most of the design follows UML diagrams which are thoroughly kept together with all programming code. As far as we use programming code, every change is reviewed by another developer. Without these, we would quickly lose our minds, heads and bodies to the massive complexity.
I always thought NASA was one of the top quality software engineers, but apparently not in every department.
Not that Google is the best at everything, but they usually do quite a bit better than average. I find it hard to believe someone has managed to best them at both of these technologies and their first attempt to market it is an iPhone app.
Not that I want to be called a nitpicker, but do you have any evidence? Does your average scale by market-value?
Then you didn't really understand the morals, or maybe only part of the morals were given to you.
An important moral is to not have greed, you just showed greed.
Yesterday I saw a movie about farming in the 1920's in the Netherlands. People farmed because it was a necessity. Nobody had greed because greed meant others would not work for you the next year. I'm not a jock, but I have a beautiful life with ups and downs, a beautiful girlfriend and the opportunity to learn every day.
If money is not the thing you can get, then let it be knowledge, the passion to perceive something new every day. Why this focus on the negative?
Yesyes! Absolutely. Arrogance is the real problem in software engineering, and so is greed. Anyways, I must admit I was completely ignorant of CS history until I started reading about Herbert Simon, Alan Newell, Turing, etc. etc. Now I realize we're truly standing on the shoulders of giants, and we should hallow them instead of despise them. Nevertheless, we should learn from the past, and use it to look ever more forward.
Sorry, but on the level of projects I'm working at, diff and patch are quite useless tools.
and every version control system has to explicitly support every distinct language
VCS's currently already work badly together with databases and knowledge systems, let alone distributed knowledge. But your point is cutting right into the core of the problem: we need a new, logical representation and reasoning system for our languages. So, I was not directly aiming at one specific language, but a range of them.
and examples on Stack Overflow are files you have to download and open in an IDE before you can examine them
I guess you'll have to rephrase here, because given I understand you, your statement is completely off-topic.
And Google has to learn each language's binary serialization so that it can search code snippets.
Google has (nearly) no ontological knowledge of the things it crawls anyways. Besides, a code-snippet is fundamentally a flaw in the computer language, as it indicates the presence of a potential pattern which should have been captured by either the language design, or an assorted library.
In a time when every other type of file is moving to standardized formats, I just love the idea of my industry balkanizing into a million crap representations.
In my opinion, the fragmentation of computer languages is fundamentally fed by the demand of personel with different knowledge and demands to be able to function and communicate with a specific language. By making languages more independant of ascii/unicode and move into the realm of reasoning about languages, reflecting the languages on different representations, shortly: modern meta-object oriented representations of the language-language model, we will allow ourselves to bridge more gaps between conceptual and structural thinkers.
That is certain to make us all more productive.
Yeps!
Well, I understand your misgivings, but we cannot look but forward. In a time when we are able to visualize more than an 80x25 screen, the computer programmer should be the first to join a progressive group of thinkers. Sadly, this is not always (if not, almost never) the case.
I've heard of it. The trick for me depends on device independent, reader-base and editor-based independent formatting and editing, i.e. multiple views on multiple internal representations by means of inferred logic by means of recursive object-class representations. Just nicely typeset code is interesting, but does not make the programming task itself more transparent.
True, Smalltalk was way ahead of its time. There are some intrinsic details to the language that make it less usable though. Particularly, it lacks a strong mechanism to determine polymorphism rules at run-time. A more modern meta-object oriented system will create a new development here, such as found in CLOS. Aspect Oriented Programming also takes steps to allow these developments. Current developments in Domain Oriented Programming are moving strongly in this direction.
One could mark a block/statement/expression as dirty. Any AST nodes depending on this scope would temporarily be dirty as well.
But maybe it's time for some essentially new concepts in programming. Basically, our linear representation of code is a remnant from high memory cost and the assumption that human-machine communication is linear as well. Modern OOP languages already show strongly we don't necessarily have to think like this (eg. in Aspect Oriented Programming). Successful application of software driven by automatic reasoners show an even stronger indication we can quite well interact non-linear with computers.
I hope I make sense. I communicate better person to person.
Euhm, yes, does not vi force certain formatting elements in the comments on top of a file? Does vi not leave extra files around for indexing identifiers? Don't get me started about emacs in the regard.
Also, coding Lisp or Scheme in Emacs is much easier (for an experienced Lisp user) as the IDE is build around the language.
The language Java chooses to use many different files for its representation. It also assumes a professional working environment, with extensive testing, linking to requirement and design documents and extensive use of UML. In this context, it is only logical to also use one IDE (which can be extensively modified to ones taste, by the way).
Interesting development, but not quite what I meant. I'm interested in Domain Oriented Languages (google) and developments inbetween Aspect Oriented Programming and Meta-object Oriented Programming (google, google).
Uhm, although I risk with this post as being marked as a commie, I assure you beforehand that I have trust in a free market.
Ok, I'm going to denounce every single statement you made and it would be nice if you could be a bit less partisan and try to see it from 'our' way.
Freedom includes the risk of losing as well as the possibility of winning.
Indeed, and it includes the possibility of sharing our losses and our winnings, and deciding to have an elected government to control these parameters. Thus it allows those under a more powerful government to take more risks, thus innovate more while keeping our streets relatively clean of the down and out.
Or, you can turn your life over to a government with the promises of all your needs being taken care of from cradle to grave. All you have to give them is... everything.
Wow, making a relative statement is not one of your strengths. Just as in your idealized free market system, we also negotiate about the amount of income we spend on taxes. Besides, many of our taxes spend flow back into the economic quietly and quickly. I don't give my government everything, just about 50% so I can keep living in relative equanimity.
The problem, for admirers of this system such as yourself, anyway, is that Europe itself is starting to question such an arrangement.
You're late with that statement. Here in the Netherlands we were starting to question in the middle 90's. Right now we're actually seeing the damage done by blatantly privatizing many of our public sector and many are doubting the motives of our right wing.
People are beginning to wonder why they can't have a good medical care system without massive government expenditures.
We're also wondering what the result is of an oligopoly marketplace in pharmacy and medicare without strict quality control. We are wondering how our residents can insure themselves sufficiently (and relatively independently) against malpractice and how we will provide security to an increasing individualizing (fragmenting?) civilization.
They're starting to wonder just why it's necessary to be paying so much in taxes.
We practically invented taxes. Right now we wonder why we have to pay for extensive media campaigns by our medicare providers and insurance companies. Also, we are wondering why none of the players in this oligopoly are providing sufficient data to make a well informed decision. Nor is the free-market working here, since nobody is stepping up (yet).
They're starting to wonder why starting a business has to be a bureaucratic nightmare.
In any one of your large organizations, starting a new subdivision is just as much a large bureaucratic nightmare. If you can't handle the bureaucratic stuff, maybe you should hire someone to do it for you, or you should have paid a bit more attention during business classes. Nevertheless, this point is a very interesting one, as information technology should prove to be a welcome hand to help newcomers to settle in the market.
And they're starting to vote appropriately.
Here in.nl we happen to have a handful of different parties who have an intricate underlying network. According to demand, our political frameset moves slightly to the left or right side of the spectrum (or any of the other dimensions). In this way we avoid extremism, which, unless you're an anarchist, you must agree with me, proves to always destroy more than it creates.
Many of our political parties are open and with enough intelligence, one can climb the ranks in those even when one does not own 10 oil-firms.
So, tell me, when one can only vote for one out of two media-crazy parties, when ones opinion on these parties is more influenced by ones neighbors or coworkers than by intellect, tell me, what does actually constitute 'appropriate voting'?
In my very humble opinion, tools such as Emacs and vi are precursors to larger development environments, such as Eclipse or Delphi. In your case, and assuming my argument is true, we would all be going back to flipping switches and pressing buttons, since that's the only true way of understanding the code.
If you don't accept my argument, then why are syntax highlighting,:make macros and identifier matching part of every vi install nowadays? And don't even get me started about emacs, which design purposes was to help programmers write better code. So, if you don't accept my premise, where do you draw the line?
For me, this development can't go fast enough. I'm looking forward to languages that integrate completely with an IDE, and leave simple character representation (ASCII e.a.) behind.
Ad 1. I did file many bug-reports, I've also fixed many a bug myself. The kind of user-testing I focus on here involves systematic and controlled user-testing, so bias from developers is completely removed.
Ad 2. MSDN sucks as well, and there is much documentation on commercial projects that is incomplete. But when I make a choice with an OSS project which proclaims to be 'stable' and 'well documented', I also expect those claims to be true.
Ad 3. There are some projects, indeed. In my opinion not enough, and not thorough enough to make it comparable with commercial projects.
Ad 4. On some projects, yes. But when support fails in an integral element of Linux (eg. kernel, sound system, XFree), it causes many other elements to fail as well. There is something to be said about controlled demolition.
Ad 5. X Versions, but exempting the 32-bit/64-bit distinction, I can still install software which is 10 years old on Vista. MacOS shows even better performance in this area.
Ad 6. Commercial land is bad too in this respect. But believe me, once you've seen the huge differences between sendmail, postfix, exim, apache, mutt, bash config files, to just name a few, you have to admit it is a serious problem. Then we have gconf, which every program uses slightly different and has horrible read-write support (crashes often). And now I'm talking only config files. It's just that the principle of least astonishment is broken too often. I just don't have 3 hours time to read through yet another manual describing yet another weird syntax to do essentially the same (namely, make a hierarchical, annotated file). Also, if gconf is going to be the next 'thing', why are the existing UNIX utilities not ported to using the gconf system as well?
7. I'm not going to give a citation, but we can certainly see that the underlying principles (everything is a file, kernel as one ring) is broken. Most obvious here is the horrible integration with current web developments. I'm not saying others are doing much better, but IMHO we're looking back too much, where we should actually look forward and integrate elegantly in the kernel.
8. We're not talking about FOSS/non-FOSS platforms. We're talking Perl, PHP, C, C++, Java, Python, Ruby, Lisp, Scheme, bash, Makefile. And then I'm just talking about the 'core' language many important and widely used tools are written in, or make extensive use of. Then we add to that languages such as TeX/LaTeX, HTML, that man-page language, XML oriented languages and many others. I'm not saying more languages are necessarily a bad thing. I try to get across the amount of effort a potential new developer has to go through if he wants to add/modify an existing program. Especially the existing, 'core' tools, should be rewritten and implemented in a language many people are fluent in. Modernizing and standardizing the languages used also allows us to make the shell more powerful again, eg. by making use of more complex streams.
Ad 9. Well, it's different since the appeal of UNIX was always: keep it simple stupid. Simple tools, doing simple, testable things, working together to form complex behavior. This principle is collapsing with the new developments in GUI's, where one program does one thing. Although, I have to admit KDE is trying very hard to keep to the KISS principle, kuddos for that.
10. Yes, featuritis, I'm not joking, sorry. More features is not necessarily better if they eclipse the core-functionality. More features require more testing, more documentation, more complex libraries and more formal coding. We simply don't have many developers who are knowledgeable in this, plus we don't have many full-time managers to manage the complex interrelationships.
You can be absolutely sure I am flaming. After using OSS ever since Linux was still a little baby, I've become attracted to the KISS model, which is excellent design. However, many linux utilities seem to miscomprehend this philosophy.
But, on your comments. 1-3 can be applied to many different software packages. I'll reinforce my statement a bit further here.
Lets take KDE as an example. KDE is the main viewing port of your Linux experience (given you do not use Gnome). It is a package which has had years of development time, a relatively large developer group and a large user group. We can all conclude that: if you make KDE better, you'll make the experience of the average user better. However, there is *no* controlled user-testing whatsoever. Even Windows, with all its problems, spends many man-months on just testing and researching the user-experience in a controlled manner, and learning valuable lessons.
On documentation: Even experienced Unix veterans have trouble finding the right documentation. We should wake up, and realize that complex multi-faceted software needs complex multi-faceted documentation, instead of spurious text-files, HTML files, online documentation, man-files, LaTeX/PDF documentation. Making this more uniform is a huge step and to be honest, I do not see the OSS guys doing anything about it. Commercial developments from MS and Apple however, show tremendous effort to reintegrate their fractured documentation. Again, I'm trying to paint in more colours than just black and white.
Lack of quality control. Closely related to #1. Most OSS comes without automated testing and detailed deployment systems which involve multiple independent parties. There are some good exceptions though, such as Blender. All-in-all, I often see fixes on one part introduce errors on another, which are often solved in the 'next-next-release'.
Ad #4: This certainly is an issue when these components are integral to the operation of many other components. A full-fledged OS consists of many thousands of components, many of them being dependent on each other. It is difficult for developers to keep an eye on the development effort needed to keep these components working together in a nice fashion. When someone suddenly quits supporting an integral component, it can create a cascade effect, causing many other developers to throw the towel into the ring.
Ad #5. Choice is good, but is not cheap. When you're basically giving away your software for nothing, you should understand that choice will put more strain on developers. Standardization is difficult, since you want to entertain the needs of many, but saves 'money' in the long run (in the OSS case, 'money' equals developer effort).
Ad #6. Yes, Windows has its history, but has tried to make things better often. Apple shows a very good picture. In Unix, I might be able to 'vi' every config file, but I'm presented with a different configuration language every time. To properly understand the configuration language, I need to read manuals, which are often poorly written or badly adjustable to modern world demands (eg. man-pages).
Ad #7. And with such a comment, you basically shoo away all the people who could actually make a difference. You're sailing a sinking ship, people are jumping in the rescue boats and still the passengers and crew maintain their expectations, course and heading. I'm very sorry to have abandoned ship, captain, but I do not see the shore you and me have talked about for so long.
Oh, yes, #7 needs rewording. I meant: the UNIX framework is losing its leverage with new demands in computer engineering. Sorry, I'm not dutch.
I agree completely that these flaws are not shared with other commercial approaches. However, it is clear that many commercial approaches are paying attention (and experts) to solve the problems stated above (with or without success). With OSS, I'm not so sure this is actually the case.
Also, although this is the wrong place to put this comment, I would like to stress the possibility of vandalism/sabotage of certain corporations on OSS.
It seems the developers have no concern whatsoever to test their new user-interfaces with users who will actually use their software. This causes miscommunication between the developer and the user-base, in turn leading to an alienation of both groups. It is paramount to learn to speak the language of the user, or the boat we want to sail will never land on a coast.
Besides this, I find the lack of clear and uniform documentation a big mishap in modern linux systems.
So, my complaint list:
1. Lack of user-testing 2. Incomplete, incomprehensible, multi-format documentation. 3. Lack of quality control (eg. automated testing) 4. Unannounced drop of support on certain projects. 5. A plethora of linux distributions makes it difficult to choose. 6. Too many configuration formats. 7. The UNIX framework is not mature anymore and because of its design flaws, responds horribly to new demands. 8. Too many different programming languages make it difficult for new talent to drop in or to integrate different approaches. 9. KISS principle is broken too many times. 10. Featuritis (http://en.wikipedia.org/wiki/Feature_creep)
1. The result of a compound function, such as f(g(a)), with f and g being functions, and 'a' an argument is not always of complexity O(g(a)) + O(f(a)), it can be much lower.
2. An imperitive language can make 'some' optimizations, but since the language itself cannot optimize further at run-time, compound functions are often a bottleneck and require programming effort and parallel programming effort.
3. A functional language might (or might not) see the possibilities of lambda reductions and give automatic optimization of these compound functions.
4. Therefor, 'using' a sort function sounds rather odd. The word 'apply' sounds much better. You apply the lambda expression on the inner expression, thus allowing certain reductions.
I agree absolutely with flexible code-reuse and the programming language independence of this element. However, to say that OOP saves 'a little typing' is a gross understatement in my opinion. OOPs type morphology is the more flexible one. As the earliest C++ macros show, it is perfectly possible to implement this in C, but not very welcome, as we'd all have different standards.
The case for functional languages is similar: although a good design allows a functional approach in an iterative language, and vice versa, the major difference is uniformity of language and run-time code manipulation, plus a more 'involved' interpretter/compiler, as lambda reductions and optimalizations are somewhat more complicated than simple compiling in an iterative language.
Slashdot Mirror
You gain bonus points if you can actually prove we are not currently seeing a singularity. Some points to back that up:
1. Stock markets are traded algorithmicly, using, among others, genetic algorithms.
2. Most of our (digital) communication is analysed, scrutinized and profiled by algorithms. Social status, personal wealth and according to some, even happiness is partly influenced by this. These are basic elements of our identities which are slowly being taken over by hidden computations. Many of the design decisions behind these algorithms are made using genetic algorithms, advanced statistics and neural networks (either directly or indirectly).
3. Our world view is getting ever more shallow by priming news to individuals, not communities. A classical divide-and-conquer approach. Perhaps politically motivated, it could only be executed using feedback systems that operate on the semantic and contextual level. Partly, these systems are operated by humans, but it has been ever more automated over the last two decades by using language processing, knowledge bases and many other tools.
There are also points clearly opposed to the singularity. One point:
1. Many optimal solutions to advanced game theoretic problems have a provable double exponential time complexity, but have interesting heuristic solutions which human beings seem to be ideally suited for. Our genes, history, culture and memory are all tools which have been developed to test and solve these advanced game theoretic problems.
You're not sorry. You'll do it again the next opportunity.
It really pisses me off when people say they are sorry, while they actually aren't. It ruins the meaning of the word and makes people who are truly sorry left without words.
Interesting, it seems that nowadays we suddenly first have to put numbers into a pie chart, before we can see what percentage it has. This seems like primary school knowledge to me.
Since the word has meaning for programmers, it could be a non-dictionarized meaningful word (in a certain context).
(just as dictionarized is not a dictionary word, but has meaning nevertheless)
Your point does not hit the mark at all. It only takes a simple expected value measurement to bring statistics back into play. If every customer brings in 1 dollar but the jerk who hacks into your application will cost you 1 million dollars instead, then a 1 out of 10 billion chance is a chance to take. Statistics is a very valuable asset to any developer/systems architect.
And before you come up with an even more contrived example, I suggest you take a quick glance at fields such as decision theory, game theory or other utilitarian techniques to reassess your obvious lack of understanding of the subject.
I'm baffled. Here we use extensive extra documentation, mostly outside of the code. Programming changes are related to changes in design documents and deployment documents. Also most of the design follows UML diagrams which are thoroughly kept together with all programming code. As far as we use programming code, every change is reviewed by another developer. Without these, we would quickly lose our minds, heads and bodies to the massive complexity.
I always thought NASA was one of the top quality software engineers, but apparently not in every department.
Not that Google is the best at everything, but they usually do quite a bit better than average. I find it hard to believe someone has managed to best them at both of these technologies and their first attempt to market it is an iPhone app.
Not that I want to be called a nitpicker, but do you have any evidence? Does your average scale by market-value?
Then you didn't really understand the morals, or maybe only part of the morals were given to you.
An important moral is to not have greed, you just showed greed.
Yesterday I saw a movie about farming in the 1920's in the Netherlands. People farmed because it was a necessity. Nobody had greed because greed meant others would not work for you the next year. I'm not a jock, but I have a beautiful life with ups and downs, a beautiful girlfriend and the opportunity to learn every day.
If money is not the thing you can get, then let it be knowledge, the passion to perceive something new every day. Why this focus on the negative?
Yesyes! Absolutely. Arrogance is the real problem in software engineering, and so is greed. Anyways, I must admit I was completely ignorant of CS history until I started reading about Herbert Simon, Alan Newell, Turing, etc. etc. Now I realize we're truly standing on the shoulders of giants, and we should hallow them instead of despise them. Nevertheless, we should learn from the past, and use it to look ever more forward.
Yes, I have actually spend some percentage of my time to try to understand colourforth. Sadly, I did that.
I can't wait until diff and patch no longer work,
Sorry, but on the level of projects I'm working at, diff and patch are quite useless tools.
and every version control system has to explicitly support every distinct language
VCS's currently already work badly together with databases and knowledge systems, let alone distributed knowledge. But your point is cutting right into the core of the problem: we need a new, logical representation and reasoning system for our languages. So, I was not directly aiming at one specific language, but a range of them.
and examples on Stack Overflow are files you have to download and open in an IDE before you can examine them
I guess you'll have to rephrase here, because given I understand you, your statement is completely off-topic.
And Google has to learn each language's binary serialization so that it can search code snippets.
Google has (nearly) no ontological knowledge of the things it crawls anyways. Besides, a code-snippet is fundamentally a flaw in the computer language, as it indicates the presence of a potential pattern which should have been captured by either the language design, or an assorted library.
In a time when every other type of file is moving to standardized formats, I just love the idea of my industry balkanizing into a million crap representations.
In my opinion, the fragmentation of computer languages is fundamentally fed by the demand of personel with different knowledge and demands to be able to function and communicate with a specific language. By making languages more independant of ascii/unicode and move into the realm of reasoning about languages, reflecting the languages on different representations, shortly: modern meta-object oriented representations of the language-language model, we will allow ourselves to bridge more gaps between conceptual and structural thinkers.
That is certain to make us all more productive.
Yeps!
Well, I understand your misgivings, but we cannot look but forward. In a time when we are able to visualize more than an 80x25 screen, the computer programmer should be the first to join a progressive group of thinkers. Sadly, this is not always (if not, almost never) the case.
I've heard of it. The trick for me depends on device independent, reader-base and editor-based independent formatting and editing, i.e. multiple views on multiple internal representations by means of inferred logic by means of recursive object-class representations. Just nicely typeset code is interesting, but does not make the programming task itself more transparent.
True, Smalltalk was way ahead of its time. There are some intrinsic details to the language that make it less usable though. Particularly, it lacks a strong mechanism to determine polymorphism rules at run-time. A more modern meta-object oriented system will create a new development here, such as found in CLOS. Aspect Oriented Programming also takes steps to allow these developments. Current developments in Domain Oriented Programming are moving strongly in this direction.
One could mark a block/statement/expression as dirty. Any AST nodes depending on this scope would temporarily be dirty as well.
But maybe it's time for some essentially new concepts in programming. Basically, our linear representation of code is a remnant from high memory cost and the assumption that human-machine communication is linear as well. Modern OOP languages already show strongly we don't necessarily have to think like this (eg. in Aspect Oriented Programming). Successful application of software driven by automatic reasoners show an even stronger indication we can quite well interact non-linear with computers.
I hope I make sense. I communicate better person to person.
Euhm, yes, does not vi force certain formatting elements in the comments on top of a file? Does vi not leave extra files around for indexing identifiers? Don't get me started about emacs in the regard.
Also, coding Lisp or Scheme in Emacs is much easier (for an experienced Lisp user) as the IDE is build around the language.
The language Java chooses to use many different files for its representation. It also assumes a professional working environment, with extensive testing, linking to requirement and design documents and extensive use of UML. In this context, it is only logical to also use one IDE (which can be extensively modified to ones taste, by the way).
Interesting development, but not quite what I meant. I'm interested in Domain Oriented Languages (google) and developments inbetween Aspect Oriented Programming and Meta-object Oriented Programming (google, google).
Uhm, although I risk with this post as being marked as a commie, I assure you beforehand that I have trust in a free market.
Ok, I'm going to denounce every single statement you made and it would be nice if you could be a bit less partisan and try to see it from 'our' way.
Freedom includes the risk of losing as well as the possibility of winning.
Indeed, and it includes the possibility of sharing our losses and our winnings, and deciding to have an elected government to control these parameters. Thus it allows those under a more powerful government to take more risks, thus innovate more while keeping our streets relatively clean of the down and out.
Or, you can turn your life over to a government with the promises of all your needs being taken care of from cradle to grave. All you have to give them is... everything.
Wow, making a relative statement is not one of your strengths. Just as in your idealized free market system, we also negotiate about the amount of income we spend on taxes. Besides, many of our taxes spend flow back into the economic quietly and quickly. I don't give my government everything, just about 50% so I can keep living in relative equanimity.
The problem, for admirers of this system such as yourself, anyway, is that Europe itself is starting to question such an arrangement.
You're late with that statement. Here in the Netherlands we were starting to question in the middle 90's. Right now we're actually seeing the damage done by blatantly privatizing many of our public sector and many are doubting the motives of our right wing.
People are beginning to wonder why they can't have a good medical care system without massive government expenditures.
We're also wondering what the result is of an oligopoly marketplace in pharmacy and medicare without strict quality control. We are wondering how our residents can insure themselves sufficiently (and relatively independently) against malpractice and how we will provide security to an increasing individualizing (fragmenting?) civilization.
They're starting to wonder just why it's necessary to be paying so much in taxes.
We practically invented taxes. Right now we wonder why we have to pay for extensive media campaigns by our medicare providers and insurance companies. Also, we are wondering why none of the players in this oligopoly are providing sufficient data to make a well informed decision. Nor is the free-market working here, since nobody is stepping up (yet).
They're starting to wonder why starting a business has to be a bureaucratic nightmare.
In any one of your large organizations, starting a new subdivision is just as much a large bureaucratic nightmare. If you can't handle the bureaucratic stuff, maybe you should hire someone to do it for you, or you should have paid a bit more attention during business classes. Nevertheless, this point is a very interesting one, as information technology should prove to be a welcome hand to help newcomers to settle in the market.
And they're starting to vote appropriately.
Here in .nl we happen to have a handful of different parties who have an intricate underlying network. According to demand, our political frameset moves slightly to the left or right side of the spectrum (or any of the other dimensions). In this way we avoid extremism, which, unless you're an anarchist, you must agree with me, proves to always destroy more than it creates.
Many of our political parties are open and with enough intelligence, one can climb the ranks in those even when one does not own 10 oil-firms.
So, tell me, when one can only vote for one out of two media-crazy parties, when ones opinion on these parties is more influenced by ones neighbors or coworkers than by intellect, tell me, what does actually constitute 'appropriate voting'?
Life is hard, and the world is cruel
Someone is feeling sorry for him- or herself...
In my very humble opinion, tools such as Emacs and vi are precursors to larger development environments, such as Eclipse or Delphi. In your case, and assuming my argument is true, we would all be going back to flipping switches and pressing buttons, since that's the only true way of understanding the code.
If you don't accept my argument, then why are syntax highlighting, :make macros and identifier matching part of every vi install nowadays? And don't even get me started about emacs, which design purposes was to help programmers write better code. So, if you don't accept my premise, where do you draw the line?
For me, this development can't go fast enough. I'm looking forward to languages that integrate completely with an IDE, and leave simple character representation (ASCII e.a.) behind.
Ad 1. I did file many bug-reports, I've also fixed many a bug myself. The kind of user-testing I focus on here involves systematic and controlled user-testing, so bias from developers is completely removed.
Ad 2. MSDN sucks as well, and there is much documentation on commercial projects that is incomplete. But when I make a choice with an OSS project which proclaims to be 'stable' and 'well documented', I also expect those claims to be true.
Ad 3. There are some projects, indeed. In my opinion not enough, and not thorough enough to make it comparable with commercial projects.
Ad 4. On some projects, yes. But when support fails in an integral element of Linux (eg. kernel, sound system, XFree), it causes many other elements to fail as well. There is something to be said about controlled demolition.
Ad 5. X Versions, but exempting the 32-bit/64-bit distinction, I can still install software which is 10 years old on Vista. MacOS shows even better performance in this area.
Ad 6. Commercial land is bad too in this respect. But believe me, once you've seen the huge differences between sendmail, postfix, exim, apache, mutt, bash config files, to just name a few, you have to admit it is a serious problem. Then we have gconf, which every program uses slightly different and has horrible read-write support (crashes often). And now I'm talking only config files. It's just that the principle of least astonishment is broken too often. I just don't have 3 hours time to read through yet another manual describing yet another weird syntax to do essentially the same (namely, make a hierarchical, annotated file). Also, if gconf is going to be the next 'thing', why are the existing UNIX utilities not ported to using the gconf system as well?
7. I'm not going to give a citation, but we can certainly see that the underlying principles (everything is a file, kernel as one ring) is broken. Most obvious here is the horrible integration with current web developments. I'm not saying others are doing much better, but IMHO we're looking back too much, where we should actually look forward and integrate elegantly in the kernel.
8. We're not talking about FOSS/non-FOSS platforms. We're talking Perl, PHP, C, C++, Java, Python, Ruby, Lisp, Scheme, bash, Makefile. And then I'm just talking about the 'core' language many important and widely used tools are written in, or make extensive use of. Then we add to that languages such as TeX/LaTeX, HTML, that man-page language, XML oriented languages and many others. I'm not saying more languages are necessarily a bad thing. I try to get across the amount of effort a potential new developer has to go through if he wants to add/modify an existing program. Especially the existing, 'core' tools, should be rewritten and implemented in a language many people are fluent in. Modernizing and standardizing the languages used also allows us to make the shell more powerful again, eg. by making use of more complex streams.
Ad 9. Well, it's different since the appeal of UNIX was always: keep it simple stupid. Simple tools, doing simple, testable things, working together to form complex behavior. This principle is collapsing with the new developments in GUI's, where one program does one thing. Although, I have to admit KDE is trying very hard to keep to the KISS principle, kuddos for that.
10. Yes, featuritis, I'm not joking, sorry. More features is not necessarily better if they eclipse the core-functionality. More features require more testing, more documentation, more complex libraries and more formal coding. We simply don't have many developers who are knowledgeable in this, plus we don't have many full-time managers to manage the complex interrelationships.
You can be absolutely sure I am flaming. After using OSS ever since Linux was still a little baby, I've become attracted to the KISS model, which is excellent design. However, many linux utilities seem to miscomprehend this philosophy.
But, on your comments. 1-3 can be applied to many different software packages. I'll reinforce my statement a bit further here.
Lets take KDE as an example. KDE is the main viewing port of your Linux experience (given you do not use Gnome). It is a package which has had years of development time, a relatively large developer group and a large user group. We can all conclude that: if you make KDE better, you'll make the experience of the average user better. However, there is *no* controlled user-testing whatsoever. Even Windows, with all its problems, spends many man-months on just testing and researching the user-experience in a controlled manner, and learning valuable lessons.
On documentation: Even experienced Unix veterans have trouble finding the right documentation. We should wake up, and realize that complex multi-faceted software needs complex multi-faceted documentation, instead of spurious text-files, HTML files, online documentation, man-files, LaTeX/PDF documentation. Making this more uniform is a huge step and to be honest, I do not see the OSS guys doing anything about it. Commercial developments from MS and Apple however, show tremendous effort to reintegrate their fractured documentation. Again, I'm trying to paint in more colours than just black and white.
Lack of quality control. Closely related to #1. Most OSS comes without automated testing and detailed deployment systems which involve multiple independent parties. There are some good exceptions though, such as Blender. All-in-all, I often see fixes on one part introduce errors on another, which are often solved in the 'next-next-release'.
Ad #4: This certainly is an issue when these components are integral to the operation of many other components. A full-fledged OS consists of many thousands of components, many of them being dependent on each other. It is difficult for developers to keep an eye on the development effort needed to keep these components working together in a nice fashion. When someone suddenly quits supporting an integral component, it can create a cascade effect, causing many other developers to throw the towel into the ring.
Ad #5. Choice is good, but is not cheap. When you're basically giving away your software for nothing, you should understand that choice will put more strain on developers. Standardization is difficult, since you want to entertain the needs of many, but saves 'money' in the long run (in the OSS case, 'money' equals developer effort).
Ad #6. Yes, Windows has its history, but has tried to make things better often. Apple shows a very good picture. In Unix, I might be able to 'vi' every config file, but I'm presented with a different configuration language every time. To properly understand the configuration language, I need to read manuals, which are often poorly written or badly adjustable to modern world demands (eg. man-pages).
Ad #7. And with such a comment, you basically shoo away all the people who could actually make a difference. You're sailing a sinking ship, people are jumping in the rescue boats and still the passengers and crew maintain their expectations, course and heading. I'm very sorry to have abandoned ship, captain, but I do not see the shore you and me have talked about for so long.
Sorry, this is what I meant: Product Life Cycle
Oh, yes, #7 needs rewording. I meant: the UNIX framework is losing its leverage with new demands in computer engineering. Sorry, I'm not dutch.
I agree completely that these flaws are not shared with other commercial approaches. However, it is clear that many commercial approaches are paying attention (and experts) to solve the problems stated above (with or without success). With OSS, I'm not so sure this is actually the case.
Also, although this is the wrong place to put this comment, I would like to stress the possibility of vandalism/sabotage of certain corporations on OSS.
It seems the developers have no concern whatsoever to test their new user-interfaces with users who will actually use their software. This causes miscommunication between the developer and the user-base, in turn leading to an alienation of both groups. It is paramount to learn to speak the language of the user, or the boat we want to sail will never land on a coast.
Besides this, I find the lack of clear and uniform documentation a big mishap in modern linux systems.
So, my complaint list:
1. Lack of user-testing
2. Incomplete, incomprehensible, multi-format documentation.
3. Lack of quality control (eg. automated testing)
4. Unannounced drop of support on certain projects.
5. A plethora of linux distributions makes it difficult to choose.
6. Too many configuration formats.
7. The UNIX framework is not mature anymore and because of its design flaws, responds horribly to new demands.
8. Too many different programming languages make it difficult for new talent to drop in or to integrate different approaches.
9. KISS principle is broken too many times.
10. Featuritis (http://en.wikipedia.org/wiki/Feature_creep)
How to begin the argument, lets see...
1. The result of a compound function, such as f(g(a)), with f and g being functions, and 'a' an argument is not always of complexity O(g(a)) + O(f(a)), it can be much lower.
2. An imperitive language can make 'some' optimizations, but since the language itself cannot optimize further at run-time, compound functions are often a bottleneck and require programming effort and parallel programming effort.
3. A functional language might (or might not) see the possibilities of lambda reductions and give automatic optimization of these compound functions.
4. Therefor, 'using' a sort function sounds rather odd. The word 'apply' sounds much better. You apply the lambda expression on the inner expression, thus allowing certain reductions.
I agree absolutely with flexible code-reuse and the programming language independence of this element. However, to say that OOP saves 'a little typing' is a gross understatement in my opinion. OOPs type morphology is the more flexible one. As the earliest C++ macros show, it is perfectly possible to implement this in C, but not very welcome, as we'd all have different standards.
The case for functional languages is similar: although a good design allows a functional approach in an iterative language, and vice versa, the major difference is uniformity of language and run-time code manipulation, plus a more 'involved' interpretter/compiler, as lambda reductions and optimalizations are somewhat more complicated than simple compiling in an iterative language.