Absinthe is NASTY. I ordered some from Spain. Did a lot of reading on it, and as expected, it's loathsome...
Did you try diluting it and adding sugar? From the Absinthe FAQ:
[Absinthe] is very bitter (due to the presence of absinthin, which has a bitterness threshold of 1:70,000) and is therefore traditionally diluted with cold water which is poured over a perforated spoonful of sugar into a glass containing a shot of absinthe. The drink then turns into an opaque white as the essential oils precipitate out of the alcoholic solution, forming a colloidal suspension.
Re:The better question is ...
on
Why not Ruby?
·
· Score: 1
Certainly not all code is written in those four languages, but the majority of business applications *are* written in one of them.
My point is that today, the majority of new business applications are not being written in these languages. The reason is that they lack features that can be found in more modern languages like Java, or even Visual BASIC.
Any such "proof" of the superiority of one language over another can be easily denied by the supporters of another language exactly in the manner of religious arguments.
I'm not talking about religious wars kinds of things, or saying that a particular language is best. What I am saying is that over the past 50-odd years, programming languages have become more sophisticated, and that the features of more advanced languages provide significant efficiencies over older languages. Older languages that lack these efficiencies tend to fall out of use.
FORTRAN and COBOL are two examples, notwithstanding their continued use in somewhat evolved forms. Their evolution, in fact, only proves my point. No-one is using FORTRAN I or FORTRAN II today, because they are too restrictive and lack useful features.
One example of an important "new" programming language feature that is difficult to refute is automatic memory management. It's easy to demonstrate the productivity differences in programming in a language without this (e.g. C) vs. one with it. The use of languages in the marketplace reflects this difference.
Functional languages have comparatively little support outside academia, and even there they are fading somewhat because their typical use, symbolic AI, is no longer the "hot" area of CS.
In academia, fading and being replaced by what? My experience is the opposite - functional languages are the focus of much CS research, driven by the development in formalisms such as polymorphically typed lambda calcus. There are few other areas of computing science with as rigorous a basis, or that so directly provide powerful language features.
But I won't argue that the pure functional languages have little support outside academia. That's not my point. I brought them up as an example of a rich source of advanced features, some of which have been assimilated into mainstream languages over the past few decades, but many of which have not. My point is that mainstream languages have not even come close to reaching any kind of plateau in terms of their features and capabilities. If the history of language development is anything to go by, mainstream languages will continue to adopt functional features over time, and increased efficiency is likely to follow from this.
Someone writing in a language that they like and know well is more productive than someone writing in a language they hate or don't know well.
Yes, but to make a meaningful comparison, one has to compare people writing in languages they know roughly equally well. Anecdotally, my own experiences and those of other people I know between C/C++ and Java, for example, would seem to support the idea that language features can provide improved development efficiency. The fact that C/C++ is not used to write most business applications is another data point in support of this contention.
There's another aspect to this which may be closer to what you're thinking of. Programmers who are unfamiliar with advanced programming language features tend to take a naive approach to development in which each problem is addressed anew. The "cut and paste" antipattern is an example of this. They write essentially the same code over and over, varying the details to achieve the desired results. Many reports or data entry screens written for business applications are an example of this. In such cases, advanced language features may indeed be wasted. However, such programmers are only capable of writing trivial programs. When writing programs to solve difficult problems, advanced features can become essential, or in their absence, a great deal of effort has to be expended to compensate. For example, an advanced programmer forced to write reports or screens in C might develop a generalized, data-driven reporting or screen layout engine. This, in effect, is developing a new language, in a sense to make up for limitations in C. In this sense, good programmers develop domain-specific languages all the time. It is in these areas that mainstream languages tend to be fairly limited. It's certainly not unlikely that the mainstream may never "need" (or realize that it needs) such features, but many of them may be added "under the hood", as with features like garbage collection.
I know from experience, and I know quite a few, languages having programmed since 1981. let's see:
Our experience intersects to quite a degree - I can't claim any real experience with tcl or Ruby, but I've either written real code with the rest, or at least played with them quite a bit. Pre-1980, I can also add COBOL and FORTRAN to the list, and more recently, things like Self, Scheme, Haskell, and OCaml.
I'm amazed, though, if you have real experience with Smalltalk, that you can't see the productivity advantages it can have over something like Java. Are you familiar with programming techniques which parameterize behavior using first-class functions, for example? This isn't directly possible in Java, which forces one to use workarounds such as a functor-style approach, or actually generate Java code. Either way, it's less productive for the same kind of reason that dealing with memory management in complex C programs is unproductive: it takes additional time, leads to its own class of bugs, and has nothing to do with the application domain.
I notice your list is heavy on procedural/OOP and light on functional. ML is a nice language, but I'd recommend you pick up a copy of The Structure and Interpretation of Computer Languages (SICP) and spend some time with it (from your comments, I can't imagine you've read this). It's probably one of the best introductions to some of the concepts I'm talking about.
Re:The better question is ...
on
Why not Ruby?
·
· Score: 1
Bad analogy. There is real progress in transportation -- new methods are cheaper, faster, etc.
No, the analogy stands. For example, why doesn't all business application development get done in COBOL, or FORTRAN, or C, or C++? Because newer languages are more productive. They have substantial improvements in areas like automatic memory management, type safety, etc. There's no question that we've had significant advances in programming languages, so the only thing you can really argue is whether we've somehow reached a final plateau of language efficiency. Even a small amount of research into past, current, and cutting-edge language features makes it clear that this is highly unlikely to be the case.
You seem to think that functional languages are somehow more "advanced" than procedural languages. There is no objective reason to support this conclusion -- it is like saying chocolate ice cream is more advanced than strawberry
There are plenty of objective reasons, but they probably go beyond the scope of a/. discussion. I come across these time and again as I move between commercial work in languages like Java and C++, and other projects in languages like Scheme and ML. First-order procedures are a good example: the lack of these in languages like Java and Visual BASIC makes all sorts of tasks much more difficult, requires more code, and may even require code generation to achieve dynamic behavior.
In fact, it can be argued that many of the more advanced features in modern programming language derive from functional roots - see Mainstream Influence Of Functional Languages. The reason for this is that the mathematical formalism behind functional programming, e.g. the lambda calculus, provide a far more consistent basis for the development of higher-level features than the ad-hoc design of many older programming languages.
All of them (sans a few mini-languages) are Turing complete and so are objectively exactly the same.
This is such a common claim that you'd think people would have figured out how meaningless it is by now. As another poster mentioned, Unlambda and Intercal are also Turing complete, and their existence alone effectively disproves your argument. However, to make it clearer, I'll go back to my analogy: all methods of transportation are equally capable of getting you from point A to point B. The question is how long it will take, and how much effort you will have to expend to get there. Advances in programming languages are quite closely analogous.
I *know* that new languages can't really make me more productive
How do you know this? And which languages do you know? If you've never experienced the productivity differences between different languages, you can't be familiar with much of a variety of them.
The better question is ...
on
Why not Ruby?
·
· Score: 2
Nice concise troll. In case it's a serious question (in which case I'm guessing you're not a programmer)...
That's like saying "why complicate things with another means of transportation when we already have horses, feet, dogsleds, etc. etc.?" Or "why complicate things with another means of communication when we already have smoke signals, morse code, etc. etc.?" You get the idea.
Existing mainstream languages are all hopelessly primitive when compared against a checklist of powerful capabilities well-known in academic circles, and found in languages such as the functionally-inspired languages like ML, Haskell, and Scheme. If you're using C, C++, or Java, you hit your head against walls daily, to the point where it becomes such second nature that you treat better methods with suspicion ("But it doesn't *hurt* to use this language - why should I switch?")
Programmers who are a little more discerning usually realize how limited the languages they use are, but the realistic alternatives are mostly more of the same. In fifty years time, today's languages will seem incredibly primitive.
Unfortunately, Ruby doesn't really advance the state of the mainstream-language art significantly, although it does have a nice collection of features so can be argued to be an incremental advance. The incentive to switch languages needs to be more than incremental, so Ruby probably isn't going to take over the world anytime soon. However, that doesn't mean development of new languages should stop. The incremental improvement of languages is an incredibly slow process: Java only recently introduced to the mainstream features which were introduced by Smalltalk around 1970 - and Java still doesn't even come close to doing everything that Smalltalk can!
While this is certainly an anti-"web wrap" decision, it's important to understand that the court gets there in part by suggesting that "clickwrap" is OK, then contrasting webwrap unfavorably with clickwrap.
But since the DMCA explicitly validates "clickwrap" (a.k.a. click-through) agreements, the judge isn't "suggesting" that clickwrap is OK, he's simply implicitly acknowledging current federal law.
Check out Anthrocart rack-on-wheels (not so cheap)
on
Rackmounting at Home?
·
· Score: 1
The Anthrocart costs from $719 for a 13U rack. It can also be configured as a 9U rack with some shelves on top. There are versions up to 29U. Here are some pictures, and here's the main product page.
At least two products provide server-side Javascript under JSP (not ASP) on Unix: Resin and JRun.
We're currently using Resin, because it uses an open source-style license, and we liked its implementation. Also, Resin compiles Javascript to Java bytecodes, which actually outperforms ASP.
I agree, Javascript is nice - small but powerful. In the JSP environment, having full access to the entire suite of Java class libraries makes it even more useful. And we don't have to embed Java code in web pages, where it doesn't belong.
...for all their encouragement in switching away from its server platform over the last few years. We've now finally completed the switch, and are much happier.
I'd like to thank Microsoft for all the help they've given us in this process:
The Halloween documents, which gave us the heads up about that wonderfully flexible and open server platform, Linux.
Attempting to use Java as a political tool, instead of focusing on providing customers with actual functionality. Of course, Sun used Java as a political tool too, but Sun provided value to customers at the same time, rather than treating their customers as expendable pawns.
Sending out lawyer's letters to companies, including the one I'm referring to, demanding licensing audits for no apparent reason, and following this up with very threatening behavior when said audit was not performed instantly.
Scaling up anti-competitive and anti-customer behavior to fever pitch in the past year or so, putting its business practices on the radar of top-level executives through critical articles in sources such as CNN and the Wall Street Journal. As a result, any mentioning in high-level meetings of reducing dependency on Microsoft, received approving nods without even needing to explain the reasons.
All in all, Microsoft, you've done a wonderful job. Your PR and customer relations efforts are as masterful as your software.
Here are the details of the switchover I'm referring to, for anyone else out there who might want to do something similar.
Starting in early 1998, we began a redesign and rewrite of all in-house systems at a billion-dollar financial services company which I consult to on architecture and design issues. An important part of this redesign was to convert all in-house and customer applications to support web browsers as the primary user interface. At the time, the company was a 100% Microsoft shop, and IIS/ASP along with SQL Server was chosen as the primary server platform.
However, on my advice, this company used Javascript as their server-side scripting language, and Microsoft Java (J++) to implement business objects on the server. The justification for this was the potential for portability in future. VBScript and VB would have been too uncomfortably proprietary. In addition, I recommended that as far as possible, they avoid use of MS SQL extensions, and do their data processing in Java rather than in non-standard MS SQL stored procedures.
A year or so later, Microsoft effectively pulled the plug on their J++ product. Uh-oh, my recommendations suddenly didn't look so good. We now had two choices: bet the future on something called.NET, even today a proprietary vaporware product with an uncertain future. Or switch away from ASP and move to a more open solution, eliminating the pathological dependency on a single vendor.
We chose the latter. We evaluated alternatives and eventually settled on a Java Server Pages solution, using Javascript as the scripting language. This meant the existing pages required only minor tweaking and changes to wrappers to be ported. We switched the business objects from from Microsoft J++ to "100% Pure Java", which gives us a choice of compilers and VMs (Sun, IBM...), and as part of the deal gave us a whole lot of Java 2 functionality which Microsoft had been depriving us of, by lagging the Java standard by years.
Now, in July 2001, we have finally begun running one of our application servers on Linux, just as a proof of concept of the portability of our system. This has worked like a charm - a system that once seemed so reliant on Microsoft technologies - IIS, ASP, COM, J++, ADO, ODBC, MS SQL - will now run on most server operating systems, with any web server, with any Java compiler and VM (except Microsoft's!), and with any reasonably standard SQL database. A stunning turnaround!
I should point out that the applications I'm talking about aren't simple web apps. They handle the back-office processing for some of the most complex financial transactions I've ever been involved with, and I've been consulting in the financial services industry for 15 years.
This conversion has all been coming together over the past few months, so it's been wonderful to sit in meetings of company department heads and have questions raised about our dependence on Microsoft, and be able to answer by saying "we are no longer dependent on Microsoft for any of our servers."
The IT manager is even beginning to talk about Gnome and Staroffice, now...
I'm currently helping a client to switch their internal applications from NT/IIS/ASP/COM to a JVM/JSP-centric solution. In the client's current scenario, NT, IIS, and COM - all Microsoft-specific, proprietary, closed technologies - are required components to support ASP. With JSP, this changes to a scenario in which the JVM and JSP can be deployed on any mainstream operating system and web server, providing a solution which can be sourced by multiple vendors, and for which published standards and source code is usually available. This reduces dependency on a single vendor and makes it possible to solve problems oneself, without being forced to rely on underqualified tech support personnel and a company which has little interest in actually fixing the bugs in their products, as opposed to forcing upgrades to the next entirely new and untested version.
This perspective is based on multiple experiences in which serious bugs in MS products - like memory leaks in IIS/ASP - were never addressed. Being a highly competent developer, it is not acceptable to me to be at the mercy of a company that does not even do a good job of pretending to have my interests as a customer at heart.
Much the same feeling applies to the operating system and OS-level tools. I know experienced Microsoft systems integrators who have had endless problems with Microsoft's tools, Proxy Server being a prominent example. Problems with Exchange are legion and legendary; System Management Server is a spectacular failure; and their DNS server is little more than a joke. MS Service Packs and hotfixes are as likely to break major functionality as to fix bugs - the original Service Pack 6, and the more recent Exchange hotfix are cases in point.
From my perspective, Microsoft peaked at around the time NT 4.0 came out and has been wandering directionless since then, changing acronyms (DNA anyone?) on a regular basis to attempt to hide the lack of any significant innovation.
Two technologies originally led me to be pro-Microsoft: NT itself, and COM. NT was a good product, for its time, when the betas of NT 3.1 came out in 1992 or so. NT 4 made the catastrophic mistake of importing the Windows 95 user interface, and then turning the ever-buggy Internet Explorer into the GUI shell. Since then stability has only deteriorated, and almost no fundamental progress has been made in making NT/2000/XP support some of the more powerful capabilities and configurability long provided by Unix - proper remote administration capabilities not least amongst those.
It seems that any overall vision that had existed at the time NT or COM were conceived have since deteriorated into a mad rush to maintain control in a changing market, driven by the Internet, which is something Microsoft is still trying to control rather than "get". Factions within Microsoft with backgrounds in things like mainframe transaction server systems argue at cross-purposes with advocates of academically pure object-oriented systems. If there's someone with a global vision at Microsoft, I don't know who it is: Nathan Myrhvold left long ago, and Bill Gates has spent too much of his career making billions to be a competent software architect today.
Microsoft has also never quite gotten the hang of TCP/IP - with the possible exception of the core of IIS, its Internet-oriented tools uniformly suck. I've already mentioned Proxy Server and DNS. In Win2K, Microsoft finally gave up the battle in some areas and fell back on pure BSD tools, such as the telnet implementation. The Wall Street Journal's recent story on Microsoft's reliance on open source software gives more examples of this admission of defeat.
But even while they're resorting to open source code, Microsoft seems to completely miss the power of simplicity and interoperability evident in Unix/Internet tools; or this may be a deliberate strategic policy. If tools are too simple, extensible, interoperable, or open, customers will have too much ability to control their own destiny, and thus won't be as easy to suck into a recurring-revenue future in which Microsoft bills its customers annually and provides arbitrarily chosen upgrades in return ("this new dancing paperclip is better than the old one, honest!")
In addition, Microsoft's own insistence on reinventing everything works against it: sucky initial implementations of Winsock led to applications which didn't get the concept of asynchronous communication. You still see this in products like Outlook today: they can lock up for extended periods while doing network access, something that should be completely transparent and in the background. [I'll say one thing positive here though: I/O completion ports are pretty sweet, and I've used them to good effect in some server applications. They've also helped IIS be an excellent performer. But one good API feature isn't enough, especially when the application developers don't understand how to use it.]
It isn't as difficult as one might imagine to convince hard-nosed business-oriented customers of the perspective I'm outlining: Microsoft's threatening lawyer's letters about license compliance, sent blunderbuss-style to all customers regardless of any evidence of lack of compliance, don't win friends amongst IT staff and CxOs. The threat of rental models, browsers which modify the web sites of other companies, and critical coverage of these things from quarters such as the Wall Street Journal, all combine to make you wonder: is Microsoft aware that it will ultimately need to rely on more than its current desktop monopoly, and instead convince customers to buy its products based on their merits, and the quality of service it provides?
There's no long-term strategy there, just an attempt to keep the excessive revenue flowing until the next set of CxOs can take over and inherit the mess. As a profit generator, Microsoft represents an incredible and possibly unprecedented feat, which I can respect from a certain perspective; but that doesn't mean I want to number myself amongst the cattle slaughtered to feed its unholy appetites.
Server software has become a commodity, and Microsoft is desperately trying to tie unrelated components together and avoid standards, so that customers have no option but to accept the entire package, and pay serious money for that which has become freely available elsewhere. This is done at every level of its software offerings, so that in the application area I'm talking about, for example, the operating system is tied to the web server is tied to the transaction server is tied to the template language is tied to the virtual machine is tied to... did I mention the operating system?
Yet you can go and download the source code to systems that do much the same thing - e.g. the Enhydra or Resin application servers - and, as alluded to above, these systems will run on almost any operating system and web server, with no secrets (you have the source), and no lifetime commitment to a development model espoused by exactly one company. And this applies double to commodity products such as file servers, proxy servers, web servers, DNS, email, and the like: the free products are actually significant improvements in terms of functionality and reliablity, over Microsoft's equivalent offerings.
Microsoft has grown too far, too fast, and become way too voracious and greedy. I rode with it to the peak of its wave; that wave has begun crashing, but instead of crashing onto a nice, wide open beach, it's crashing into an inescapable little Microsoft sandbox. I am jumping off to a different wave in which the currents don't work against me as much. I'm don't argue that.NET has no technical merits whatsoever; but the cost of chaining oneself to it is too high.
Slashdot Mirror
Did you try diluting it and adding sugar? From the Absinthe FAQ:
My point is that today, the majority of new business applications are not being written in these languages. The reason is that they lack features that can be found in more modern languages like Java, or even Visual BASIC.
Any such "proof" of the superiority of one language over another can be easily denied by the supporters of another language exactly in the manner of religious arguments.
I'm not talking about religious wars kinds of things, or saying that a particular language is best. What I am saying is that over the past 50-odd years, programming languages have become more sophisticated, and that the features of more advanced languages provide significant efficiencies over older languages. Older languages that lack these efficiencies tend to fall out of use.
FORTRAN and COBOL are two examples, notwithstanding their continued use in somewhat evolved forms. Their evolution, in fact, only proves my point. No-one is using FORTRAN I or FORTRAN II today, because they are too restrictive and lack useful features.
One example of an important "new" programming language feature that is difficult to refute is automatic memory management. It's easy to demonstrate the productivity differences in programming in a language without this (e.g. C) vs. one with it. The use of languages in the marketplace reflects this difference.
Functional languages have comparatively little support outside academia, and even there they are fading somewhat because their typical use, symbolic AI, is no longer the "hot" area of CS.
In academia, fading and being replaced by what? My experience is the opposite - functional languages are the focus of much CS research, driven by the development in formalisms such as polymorphically typed lambda calcus. There are few other areas of computing science with as rigorous a basis, or that so directly provide powerful language features.
But I won't argue that the pure functional languages have little support outside academia. That's not my point. I brought them up as an example of a rich source of advanced features, some of which have been assimilated into mainstream languages over the past few decades, but many of which have not. My point is that mainstream languages have not even come close to reaching any kind of plateau in terms of their features and capabilities. If the history of language development is anything to go by, mainstream languages will continue to adopt functional features over time, and increased efficiency is likely to follow from this.
Someone writing in a language that they like and know well is more productive than someone writing in a language they hate or don't know well.
Yes, but to make a meaningful comparison, one has to compare people writing in languages they know roughly equally well. Anecdotally, my own experiences and those of other people I know between C/C++ and Java, for example, would seem to support the idea that language features can provide improved development efficiency. The fact that C/C++ is not used to write most business applications is another data point in support of this contention.
There's another aspect to this which may be closer to what you're thinking of. Programmers who are unfamiliar with advanced programming language features tend to take a naive approach to development in which each problem is addressed anew. The "cut and paste" antipattern is an example of this. They write essentially the same code over and over, varying the details to achieve the desired results. Many reports or data entry screens written for business applications are an example of this. In such cases, advanced language features may indeed be wasted. However, such programmers are only capable of writing trivial programs. When writing programs to solve difficult problems, advanced features can become essential, or in their absence, a great deal of effort has to be expended to compensate. For example, an advanced programmer forced to write reports or screens in C might develop a generalized, data-driven reporting or screen layout engine. This, in effect, is developing a new language, in a sense to make up for limitations in C. In this sense, good programmers develop domain-specific languages all the time. It is in these areas that mainstream languages tend to be fairly limited. It's certainly not unlikely that the mainstream may never "need" (or realize that it needs) such features, but many of them may be added "under the hood", as with features like garbage collection.
I know from experience, and I know quite a few, languages having programmed since 1981. let's see:
Basic, Pascal, C, C++, Java, Forth, Actor, Perl, Python, Ruby, tcl, awk, Smalltalk-80, Emacs Lisp, ML, Eiffel
Our experience intersects to quite a degree - I can't claim any real experience with tcl or Ruby, but I've either written real code with the rest, or at least played with them quite a bit. Pre-1980, I can also add COBOL and FORTRAN to the list, and more recently, things like Self, Scheme, Haskell, and OCaml.
I'm amazed, though, if you have real experience with Smalltalk, that you can't see the productivity advantages it can have over something like Java. Are you familiar with programming techniques which parameterize behavior using first-class functions, for example? This isn't directly possible in Java, which forces one to use workarounds such as a functor-style approach, or actually generate Java code. Either way, it's less productive for the same kind of reason that dealing with memory management in complex C programs is unproductive: it takes additional time, leads to its own class of bugs, and has nothing to do with the application domain.
I notice your list is heavy on procedural/OOP and light on functional. ML is a nice language, but I'd recommend you pick up a copy of The Structure and Interpretation of Computer Languages (SICP) and spend some time with it (from your comments, I can't imagine you've read this). It's probably one of the best introductions to some of the concepts I'm talking about.
No, the analogy stands. For example, why doesn't all business application development get done in COBOL, or FORTRAN, or C, or C++? Because newer languages are more productive. They have substantial improvements in areas like automatic memory management, type safety, etc. There's no question that we've had significant advances in programming languages, so the only thing you can really argue is whether we've somehow reached a final plateau of language efficiency. Even a small amount of research into past, current, and cutting-edge language features makes it clear that this is highly unlikely to be the case.
You seem to think that functional languages are somehow more "advanced" than procedural languages. There is no objective reason to support this conclusion -- it is like saying chocolate ice cream is more advanced than strawberry
There are plenty of objective reasons, but they probably go beyond the scope of a /. discussion. I come across these time and again as I move between commercial work in languages like Java and C++, and other projects in languages like Scheme and ML. First-order procedures are a good example: the lack of these in languages like Java and Visual BASIC makes all sorts of tasks much more difficult, requires more code, and may even require code generation to achieve dynamic behavior.
In fact, it can be argued that many of the more advanced features in modern programming language derive from functional roots - see Mainstream Influence Of Functional Languages. The reason for this is that the mathematical formalism behind functional programming, e.g. the lambda calculus, provide a far more consistent basis for the development of higher-level features than the ad-hoc design of many older programming languages.
All of them (sans a few mini-languages) are Turing complete and so are objectively exactly the same.
This is such a common claim that you'd think people would have figured out how meaningless it is by now. As another poster mentioned, Unlambda and Intercal are also Turing complete, and their existence alone effectively disproves your argument. However, to make it clearer, I'll go back to my analogy: all methods of transportation are equally capable of getting you from point A to point B. The question is how long it will take, and how much effort you will have to expend to get there. Advances in programming languages are quite closely analogous.
I *know* that new languages can't really make me more productive
How do you know this? And which languages do you know? If you've never experienced the productivity differences between different languages, you can't be familiar with much of a variety of them.
That's like saying "why complicate things with another means of transportation when we already have horses, feet, dogsleds, etc. etc.?" Or "why complicate things with another means of communication when we already have smoke signals, morse code, etc. etc.?" You get the idea.
Existing mainstream languages are all hopelessly primitive when compared against a checklist of powerful capabilities well-known in academic circles, and found in languages such as the functionally-inspired languages like ML, Haskell, and Scheme. If you're using C, C++, or Java, you hit your head against walls daily, to the point where it becomes such second nature that you treat better methods with suspicion ("But it doesn't *hurt* to use this language - why should I switch?")
Programmers who are a little more discerning usually realize how limited the languages they use are, but the realistic alternatives are mostly more of the same. In fifty years time, today's languages will seem incredibly primitive.
Unfortunately, Ruby doesn't really advance the state of the mainstream-language art significantly, although it does have a nice collection of features so can be argued to be an incremental advance. The incentive to switch languages needs to be more than incremental, so Ruby probably isn't going to take over the world anytime soon. However, that doesn't mean development of new languages should stop. The incremental improvement of languages is an incredibly slow process: Java only recently introduced to the mainstream features which were introduced by Smalltalk around 1970 - and Java still doesn't even come close to doing everything that Smalltalk can!
The Anthrocart costs from $719 for a 13U rack. It can also be configured as a 9U rack with some shelves on top. There are versions up to 29U. Here are some pictures, and here's the main product page.
We're currently using Resin, because it uses an open source-style license, and we liked its implementation. Also, Resin compiles Javascript to Java bytecodes, which actually outperforms ASP.
I agree, Javascript is nice - small but powerful. In the JSP environment, having full access to the entire suite of Java class libraries makes it even more useful. And we don't have to embed Java code in web pages, where it doesn't belong.
I'd like to thank Microsoft for all the help they've given us in this process:
- The Halloween documents, which gave us the heads up about that wonderfully flexible and open server platform, Linux.
- Attempting to use Java as a political tool, instead of focusing on providing customers with actual functionality. Of course, Sun used Java as a political tool too, but Sun provided value to customers at the same time, rather than treating their customers as expendable pawns.
- Sending out lawyer's letters to companies, including the one I'm referring to, demanding licensing audits for no apparent reason, and following this up with very threatening behavior when said audit was not performed instantly.
- Scaling up anti-competitive and anti-customer behavior to fever pitch in the past year or so, putting its business practices on the radar of top-level executives through critical articles in sources such as CNN and the Wall Street Journal. As a result, any mentioning in high-level meetings of reducing dependency on Microsoft, received approving nods without even needing to explain the reasons.
All in all, Microsoft, you've done a wonderful job. Your PR and customer relations efforts are as masterful as your software.Here are the details of the switchover I'm referring to, for anyone else out there who might want to do something similar.
Starting in early 1998, we began a redesign and rewrite of all in-house systems at a billion-dollar financial services company which I consult to on architecture and design issues. An important part of this redesign was to convert all in-house and customer applications to support web browsers as the primary user interface. At the time, the company was a 100% Microsoft shop, and IIS/ASP along with SQL Server was chosen as the primary server platform.
However, on my advice, this company used Javascript as their server-side scripting language, and Microsoft Java (J++) to implement business objects on the server. The justification for this was the potential for portability in future. VBScript and VB would have been too uncomfortably proprietary. In addition, I recommended that as far as possible, they avoid use of MS SQL extensions, and do their data processing in Java rather than in non-standard MS SQL stored procedures.
A year or so later, Microsoft effectively pulled the plug on their J++ product. Uh-oh, my recommendations suddenly didn't look so good. We now had two choices: bet the future on something called .NET, even today a proprietary vaporware product with an uncertain future. Or switch away from ASP and move to a more open solution, eliminating the pathological dependency on a single vendor.
We chose the latter. We evaluated alternatives and eventually settled on a Java Server Pages solution, using Javascript as the scripting language. This meant the existing pages required only minor tweaking and changes to wrappers to be ported. We switched the business objects from from Microsoft J++ to "100% Pure Java", which gives us a choice of compilers and VMs (Sun, IBM...), and as part of the deal gave us a whole lot of Java 2 functionality which Microsoft had been depriving us of, by lagging the Java standard by years.
Now, in July 2001, we have finally begun running one of our application servers on Linux, just as a proof of concept of the portability of our system. This has worked like a charm - a system that once seemed so reliant on Microsoft technologies - IIS, ASP, COM, J++, ADO, ODBC, MS SQL - will now run on most server operating systems, with any web server, with any Java compiler and VM (except Microsoft's!), and with any reasonably standard SQL database. A stunning turnaround!
I should point out that the applications I'm talking about aren't simple web apps. They handle the back-office processing for some of the most complex financial transactions I've ever been involved with, and I've been consulting in the financial services industry for 15 years.
This conversion has all been coming together over the past few months, so it's been wonderful to sit in meetings of company department heads and have questions raised about our dependence on Microsoft, and be able to answer by saying "we are no longer dependent on Microsoft for any of our servers."
The IT manager is even beginning to talk about Gnome and Staroffice, now...
This perspective is based on multiple experiences in which serious bugs in MS products - like memory leaks in IIS/ASP - were never addressed. Being a highly competent developer, it is not acceptable to me to be at the mercy of a company that does not even do a good job of pretending to have my interests as a customer at heart.
Much the same feeling applies to the operating system and OS-level tools. I know experienced Microsoft systems integrators who have had endless problems with Microsoft's tools, Proxy Server being a prominent example. Problems with Exchange are legion and legendary; System Management Server is a spectacular failure; and their DNS server is little more than a joke. MS Service Packs and hotfixes are as likely to break major functionality as to fix bugs - the original Service Pack 6, and the more recent Exchange hotfix are cases in point.
From my perspective, Microsoft peaked at around the time NT 4.0 came out and has been wandering directionless since then, changing acronyms (DNA anyone?) on a regular basis to attempt to hide the lack of any significant innovation.
Two technologies originally led me to be pro-Microsoft: NT itself, and COM. NT was a good product, for its time, when the betas of NT 3.1 came out in 1992 or so. NT 4 made the catastrophic mistake of importing the Windows 95 user interface, and then turning the ever-buggy Internet Explorer into the GUI shell. Since then stability has only deteriorated, and almost no fundamental progress has been made in making NT/2000/XP support some of the more powerful capabilities and configurability long provided by Unix - proper remote administration capabilities not least amongst those.
It seems that any overall vision that had existed at the time NT or COM were conceived have since deteriorated into a mad rush to maintain control in a changing market, driven by the Internet, which is something Microsoft is still trying to control rather than "get". Factions within Microsoft with backgrounds in things like mainframe transaction server systems argue at cross-purposes with advocates of academically pure object-oriented systems. If there's someone with a global vision at Microsoft, I don't know who it is: Nathan Myrhvold left long ago, and Bill Gates has spent too much of his career making billions to be a competent software architect today.
Microsoft has also never quite gotten the hang of TCP/IP - with the possible exception of the core of IIS, its Internet-oriented tools uniformly suck. I've already mentioned Proxy Server and DNS. In Win2K, Microsoft finally gave up the battle in some areas and fell back on pure BSD tools, such as the telnet implementation. The Wall Street Journal's recent story on Microsoft's reliance on open source software gives more examples of this admission of defeat.
But even while they're resorting to open source code, Microsoft seems to completely miss the power of simplicity and interoperability evident in Unix/Internet tools; or this may be a deliberate strategic policy. If tools are too simple, extensible, interoperable, or open, customers will have too much ability to control their own destiny, and thus won't be as easy to suck into a recurring-revenue future in which Microsoft bills its customers annually and provides arbitrarily chosen upgrades in return ("this new dancing paperclip is better than the old one, honest!")
In addition, Microsoft's own insistence on reinventing everything works against it: sucky initial implementations of Winsock led to applications which didn't get the concept of asynchronous communication. You still see this in products like Outlook today: they can lock up for extended periods while doing network access, something that should be completely transparent and in the background. [I'll say one thing positive here though: I/O completion ports are pretty sweet, and I've used them to good effect in some server applications. They've also helped IIS be an excellent performer. But one good API feature isn't enough, especially when the application developers don't understand how to use it.]
It isn't as difficult as one might imagine to convince hard-nosed business-oriented customers of the perspective I'm outlining: Microsoft's threatening lawyer's letters about license compliance, sent blunderbuss-style to all customers regardless of any evidence of lack of compliance, don't win friends amongst IT staff and CxOs. The threat of rental models, browsers which modify the web sites of other companies, and critical coverage of these things from quarters such as the Wall Street Journal, all combine to make you wonder: is Microsoft aware that it will ultimately need to rely on more than its current desktop monopoly, and instead convince customers to buy its products based on their merits, and the quality of service it provides?
There's no long-term strategy there, just an attempt to keep the excessive revenue flowing until the next set of CxOs can take over and inherit the mess. As a profit generator, Microsoft represents an incredible and possibly unprecedented feat, which I can respect from a certain perspective; but that doesn't mean I want to number myself amongst the cattle slaughtered to feed its unholy appetites.
Server software has become a commodity, and Microsoft is desperately trying to tie unrelated components together and avoid standards, so that customers have no option but to accept the entire package, and pay serious money for that which has become freely available elsewhere. This is done at every level of its software offerings, so that in the application area I'm talking about, for example, the operating system is tied to the web server is tied to the transaction server is tied to the template language is tied to the virtual machine is tied to... did I mention the operating system?
Yet you can go and download the source code to systems that do much the same thing - e.g. the Enhydra or Resin application servers - and, as alluded to above, these systems will run on almost any operating system and web server, with no secrets (you have the source), and no lifetime commitment to a development model espoused by exactly one company. And this applies double to commodity products such as file servers, proxy servers, web servers, DNS, email, and the like: the free products are actually significant improvements in terms of functionality and reliablity, over Microsoft's equivalent offerings.
Microsoft has grown too far, too fast, and become way too voracious and greedy. I rode with it to the peak of its wave; that wave has begun crashing, but instead of crashing onto a nice, wide open beach, it's crashing into an inescapable little Microsoft sandbox. I am jumping off to a different wave in which the currents don't work against me as much. I'm don't argue that .NET has no technical merits whatsoever; but the cost of chaining oneself to it is too high.