Without this artificial expansion and contraction of the money supply, business would still come and go but not in large waves.
That expansion and contraction might equally be described as "natural" rather than artificial, in the sense that it's a reflection of human nature. Perfect markets only exist when the participants don't use emotion and whim as decision factors.
100 is evenly divisible by 2,4,5,10,20, and 50. So dividing the day into 10 hours, each of which contains 100 minutes, and each minute of which contains 100 seconds, would probably be just as convenient.
A 100-minute hour can be divided in halves, quarters, fifths, tenths, twentieths, and fiftieths. Thirds are fractional, but how important is that?
You're defending the original reasons for the choice of base 6, which was the divisibility of numbers like 24. The question is whether that's really a benefit now that other numbering systems are metric, and given the greater arithmetic and mathematical sophistication that exists today.
What reason is that? Afaik, it dates back 4000 years or more to the Sumerians or Babylonians and their base 6 number systems. Are you aware of any other reasons? I think today, the reasons are strictly "legacy".
Static or not, software can be quality in each case--and it does _not_ make it easier with static typing (as was your _original_ reason for Java's greatness.. the safety net rant). Try Lisp vs. C/C++. I'd much rather have a neophyte coding Lisp than C.
You're still missing the most important point, which is that critical business systems can't always be developed by small teams. What works for a small team doesn't necessarily work for larger teams, and what works for development of an application over a short timescale doesn't necessarily work for evolution of that application over a longer timescale as the team changes. This is one of the major areas in which I'm saying static typing is important.
You don't understand Lisp-like macros.
No, you didn't understand what I was saying, specifically:
Custom languages are a good thing.
I completely agree. And I'm saying that Lisp macros are simply a convenient but also limited way to prototype a custom language. There are other ways, and the only real benefit that Lisp macros provides is a low barrier to entry. XML offers a similiar capability, as it happens, but there are other means to that end also, such as simply implementing a domain-specific language using a grammar and parser generator.
You completely miss that macros are _compile time_ and for the most part not runtime.
You plucked that out of nowhere. I talked about code generation as an alternative to macros, and that would be a compile time operation.
They are essentially a meta-programming language.
Correct. And there's nothing to stop you from developing your own meta-programming languages - macros simply lower the barriers to entry for this. If you're misled into thinking that macros are the only way or even the best way to achieve this end, though, then macros are doing you a disservice. They're a shortcut, and they exhibit the typical tradeoffs of a shortcut.
Riiight. Delphi, C/C++, Perl, Smalltalk. Are you that damn ignorant?
Ha! If you think those languages are so different from each other, you prove my point perfectly. I haven't seen you mention any logic languages, or functional languages (Scheme doesn't count, since I brought it up, and you've primarily been talking about CL). You seem to be stuck on a particular kind of semantics, specifically mutable languages with class-based object orientation, or subsets thereof. It's certainly true that the dominant and popular languages all tend to have these kinds of semantics, but I'm saying you need to learn how to apply the appropriate principles, regardless of the language you're using.
NO WAY! And all this time I was using macros as training wheels. I could have been abstracting all my code away.
In my consulting experience, this is absolutely true. You probably write a lot of code which could be abstracted away. Sometimes it's done because of the startup costs involved in developing generic solutions, and that's certainly an area where macros can help, but they're not a silver bullet, and one of the reasons is maintainability.
I understand fully. You have to keep your boss happy, which keeps his boss happy, which keeps the CEO happy, which demands that the IT department is buzzword-compatible.
This is simply the explanation you use to sooth yourself and to justify not extending your knowledge into areas with which you're less comfortable. I don't have a boss, and I sell to customers on the basis of being able to deliver working, in-house maintainable, extensible systems at competitive prices. BTW, I've never met a CEO that demands that his IT department is buzzword compatible, but they do tend to demand things like good return on investment, which includes the ability to extend and maintain systems, often over decades. Choice of a language like Java gets made far more for legitimage reasons of addressing business risk than you realize.
I don't see what the point of it is. Just use C/C++. It's more "write once, run anywhere" than Java will ever hope to be.
You're clearly talking from a complete lack of experience. I've worked on large, cross platform C and C++ systems, and I've worked on large, cross platform Java systems. With the caveat that the Java systems are server-based, there's no question that Java is immeasurably more portable than C++ across different compilers and OSes. We move our server side Java apps between OSes without changing a line of code, and without a single line of conditional code. Switching between compilers is completely transparent. There tends to be more variations amongst VMs, but nothing compared to the variation between platforms when using C++, even with portable class frameworks.
There's no question that Craig's answer was required by the executive and legal team at Google. What would you have him do, stiff all his co-workers? That's just naive.
Oh, c'mon. Yeah, sure, it's a conspiracy by the editors. Look, thousands of people get to moderate, and it's not unusual to read and moderate older stories.
But your sig demonstrates that you're paranoid about this kinda stuff, so I guess there's not much point trying to argue you out of your worldview - especially since after this latest boneheaded post of yours, I'm out to get you too. Self-fulfilling prophecy, I guess.
So 10 gigabytes per day, with one megabyte per second at peak load.
IOW, you're guessing that Google could serve all its traffic over a single 100Mbit/s connection, i.e. the LAN card in my PC? That seems kinda modest, surely?
LEARN TO READ! I specifically quoted your bit about Pascal not being object-oriented.
Learn to comprehend! You were saying Java (and XML) was simply reinvention, and I was pointing out ways in which Java at least combined things in a new and useful way. Focusing on a single statement about Pascal the way you did completely missed what I was saying. I said that UCSD Pascal, which used a p-code interpreter, was not object-oriented. Delphi is irrelevant to that statement. I realize you misunderstood me, but the vehemence of your responses, elicited by your own misunderstanding, doesn't do you credit.
In 1995 and earlier, using a VM was absurd in most cases. You obviously never touched Java then.
I began working with Java when the first public betas became available, which was around '95, IIRC. In addition, I worked on the object-oriented engine for a commercial p-code based dynamically-typed language between 1991 and 1995. Your claim that "a VM was absurd in most cases" seems like a narrow perspective to me. VMs have had a very important role in serious software development, dating back to the IBM 360 mainframes in the '60s, and the precursors to the IBM VM OS.
You continue to throw out examples of conventional "wisdom" which don't hold up to scrutiny, and presumably reflect a lack of direct exposure to these things, such as "write once, test everywhere" related to Java. Focusing on Java as a system for developing GUI applications (which is what you have to be doing to come to the conclusions you do) completely misses the point. Java, as a server-side language, meets the WORA claim, and does not need to be "tested everywhere". We and many other large commercial organizations deploy Java server applications on Solaris, Linux, and Windows without needing anything more than a sanity test on platforms other than our primary test platform.
If the same significance was placed on Lisp, Smalltalk, etc. as is on Java, we would have developments by leaps and bounds.
The first thing that would be needed for serious commercial use is the addition of static typing. If you know anything about type theory, you'd realize that this has significant implications for a language. If you love Lisp so much, you would probably hate the result.
Consider Java. They choose not to use S-expressions. Now they don't have the macro capabilities of Lisp-like languages
You're allowing your narrow viewpoint to unnecessarily constrain your capabilities. It's easy to achieve macro-like functionality in Java. Take a look at tools like AspectJ for commercial examples of macro-like functionality being used in Java. Most larger Java shops do some code generation somewhere along the line.
When you really think about it, and if you have experience generating code in other languages, you realize that Lisp macros are a minor convenience - kind of like training wheels - that help you create custom languages. If you're saying you can't achieve the same capabilities in other languages, you're making a statement about your limitations as a programmer.
If you allow the features of a single language or a set of similar languages to constrain your thinking about programming, you're guaranteed to hate any system that doesn't provide the exact features you need in the exact form you're used to. It sounds to me as though you're doing that.
When you become a truly good programmer, you realize what matters are the abstractions that you design. The language you use to implement those abstractions, in a sense, becomes an implementation detail. There are certainly many valid objections that can be brought against a language like Java, as there are for CL and Scheme. But when you actually take the time to examine why those limitations exist, in many cases you find the reasons may be more valid than you thought, and that there's a tradeoff involved.
You then have to decide which side of the tradeoff you want to take. In commercial development, there are some good reasons to make some of the tradeoffs that Java makes. Your wish that as much focus be applied to Lisp and Smalltalk simply ignores this, which makes it nothing more than an impractical pipedream.
I'm telling you that you don't understand what's important to commercial development. To understand it, you need to look at what businesses are using and what they get out of it. You also need to look honestly at the problems with large and complex dynamically typed and heavily macroed systems - many of them suffer from the Perl problem of write-only code, and this is acknowledged even within the Lisp community. These are problems which languages like Java and even C++ address.
You are then completely dependent upon external architecture working as it should (Sun's Java spec and the Java implementation you choose to purchase and run on). If the Java implementation doesn't work as it should (as specified by Sun), you are shit out of luck.
You're descending into pure FUD now. There are multiple compatible Java VMs, compilers, and application servers today, so your point is strictly academic. Could the Java "platform" somehow splinter in future? Sure. But the future of software developement is always risky, because everything changes so fast. The availability of multiple compatible Java implementations is a benefit which insures against some of that future risk, and is another reason why it's attractive to businesses.
In your haze of apparent anger at the rest of the programming world, you seem to be missing what I'm saying. ("You" is intended to refer to an arbitrary number of anonymous cowards.)
Delphi wasn't a p-code language, and it didn't have the dynamic runtime capabilities Java does. Borland missed the importance of the virtual machine. Sun got that right. What I've pointed out is that Java is unique amongst commercial languages, in combining static typing with a virtual machine with object orientation, and on top of that, improving on the most common OO model, which confused interface with implementation, by adding pure interface types. Name the predecessor that fits this bill: not UCSD p-code, not Delphi, not Lisp. So Java is not simply a reinvention.
My point about successful languages is that there are usually reasons for their success, and if you deliberately blind yourself to those reasons, you're going to be one frustrated puppy - which judging by your messages, you are. Visual BASIC also had reasons for its success, as does Perl.
As for the perfection comment, my point was that Lisp misses out on some important issues, which other languages address. If you simply dismiss that without looking at the things that other tools do better, you're simply sticking your head in the sand. One of those things is static typing, and it's an important issue for large commercial projects, whether you're willing to acknowledge it or not.
As for shitty software, if Lisp were such an improvement over other languages, it would do better in the marketplace - there would be many more Paul Grahams. But when you get down to it, the business case simply isn't there. It's a myth perpetuated by single-language zealots, Graham, Pitman and yourself included. And I say that as a proud Scheme programmer, who fully recognizes the power of s-expressions, macros, code-is-data, and functional programming (not that Lisp really qualifies).
I'd suggest that you actually try an object oriented language with static typing, since there's a lot more to it than you're imagining.
By supporting the definition of types as distinct from any implementation (these are called interfaces in Java), and by checking the types of variables and assignments at compile time, an entire class of errors is caught at compiel time instead of runtime. It's not just about floats and strings, it's about every data type in the system, including complex business types, and every variable in the system, which must have a declared type, and the fact that the integrity of the relationships between values and variables is validated at compile time.
Providing the compiler with all this additional info - specifically, about the types of all your variables - then buys a number of additional capabilities. Your tools now "understand" your code much better, which allows automated refactoring - many Java IDEs support dragging and dropping of methods between classes, classes between packages, renaming of methods, etc., automatically updating the references to those entities as appropriate, because it can tell absolutely where all those references are, which is close to impossible with dynamically typed systems (with the partial exception of academic "soft typing" systems).
So when you talk about "casting schema in concrete", the surprising result is that the dynamic languages can actually end up *less* flexible than a statically-typed language. Take method renaming as an example. If you want to rename a method of a particular class in a dynamically-typed language, no tool can do that for you automatically, because in a reference like "obj.foo()", it's impossible to reliably tell what type "obj" is, and you can't simply rename every "foo" throughout the system, since some of them may belong to a different class than the one whose method you're trying to rename.
In a statically typed language, the type of every variable is known, and this kind of renaming and other refactoring can be performed automatically and reliably throughout a system. In addition, in cases where a refactoring requires some manual changes, the areas requiring changes generate compiler errors, so are clearly identified; again, a dynamic language can't do this, except by crashing at runtime. Static typing allows refactoring to become automated and reliable, which improves the maintainability and flexibility of systems.
BTW, as for generic code and reflection, it's not uncommon to use reflection in Java to map database or other data to Java objects; and interfaces provide a very powerful mechanism for developing generic code in a statically typed environment.
Understand I'm not dissing dynamic languages. I'm a heavy user of a number of dynamic languages, and have developed products for and with dynamic languages. I love the flexibility and ease of prototyping that they provide. However, I am pointing at that there are pros and cons, and that the heavy use of Java in the corporate world is not at all irrational - there are good reasons for it. Another way to think about it is that the type annotations in a program are a kind of documentation that's guaranteed to be in sync with the code.
If you're interested in furthering your education as a programmer, I'd strongly recommend adding a full understanding of static typing to your repertoire. If you can't bring yourself to learn Java in depth, take it to the next level and look at some of the polymorphic type inferencing languages, like Haskell, ML, or OCaml, all of which have the benefit of teaching important functional concepts also. For more rigorous academic coverage of types, check out the book "Types and Programming Languages" by Benjamin C. Pierce.
No, I don't make any such mistake - you make the mistake of making a number of assumptions and then basing your reaction to my comment on things you've only imagined.
There is such a thing as courtesy. Your parents might have taught you about it.
Courtesy might include not responding to people as though they've committed some act which you've only imagined.
There's also such a thing as unintended irony, for example a comment about courtesy followed directly by a condescending remark about parents.
And your point is?/. won't become as widely read as the Wall Street Journal amongst corporate CEOs? I think that's a given...
As for the professional habit of two-facedness, I've found that sometimes the most effective strategy is to be confrontational when there's a problem, even in a professional setting. The two-faced ones are the ones who are scared to rock the boat, because they're not secure about their own ability to survive an open battle. Their insecurity is usually justified!
Using the Bill Gates borg isn't childish - aside from the fact that it communicates/.'s bias honestly and concisely, it also satirizes aspects of Microsoft's real-life conduct. Not so much childish as chillingly accurate.
Why do you oppose the government clamping down on extremely addictive drugs then?
Simple: because the government does such a bad job of it, criminalizing innocent people instead of getting them help, and generally creating more problems than they solve.
Reinvention is still reinvention. There is nothing new about Java.
Java is not a reinvention of UCSD Pascal. One of the things that's new about Java is the combination of object-orientation (not in Pascal), with interfaces separable from implementation, with static typing, running on a bytecode interpreter which supports runtime loading of modules. This combination is actually quite unique. I don't doubt there are systems, probably academic, that did something along these lines previously, but there's Java was the first to make any kind of impact.
Frankly, if it's anything more than simple trolling, I don't understand the kind of mindless language evangelism that leads someone to try to dismiss a successful language as containing nothing new or no new ideas. This simply implies you don't have very much experience with different languages to realize that there are no perfect languages, everything is a tradeoff, and most languages have some unique strengths and weaknesses. I mentioned Guy Steele in a concise attempt to encapsulate this idea, since he's demonstrated an understanding of these kinds of issues and has created two very different, successful (in different ways) languages.
I said all of those were reinventions (to a certain degree) of Lisp.
Your qualification there is all-important. Reinventing something "to a certain degree" but adding new functionality, like static typing, is not reinventing, it's building on what's come before, which is how nearly all technological and academic progress occurs. Java represents such progress, even over Lisp. No, it doesn't address every niche that Lisp addresses (which is why I use both Scheme and Java myself), but Lisp doesn't address every niche that Java addresses, either. Are you quite sure your reinvention meme isn't simply annoyed FUD, driven by a prejudice against the unfamiliar?
Thanks for the thoughtful post. I'd like to add that I've found it quite easy to evangelize against.NET, even in diehard MS shops, and I suggest that anyone in a position to should try doing this.
There's hardly an MS shop out there that hasn't felt some misgivings about Microsoft and specifically.NET over the past couple of years - whether because of Microsoft tightening the licensing screws, dumping support for Java, radically changing VB for.NET, or pushing a brand new language (C#) for Microsoft's own benefit, or simply all the information that's come out in court which makes it clear that Microsoft has always been more than willing to screw their customers to make a buck.
IOW, Microsoft has provided us with an enormous amount of FUD ammunition, all we have to do is load up and start firing. Don't be too in-your-face about it, though. Instead, start by asking questions:
Do you feel comfortable committing to.NET as a single-vendor standard? (Point out that open-source alternatives like Mono are still vaporware.)
If you're not going to use C# because it's too new and unproven, which language are you going to use to target.NET?
If you use VB.NET, aren't you concerned that the next version will leave you out in the cold, as just happened with the previous version of VB in the transition to.NET?
Wouldn't it be beneficial to be able to run your server-side apps on any hardware and OS? What if you need to scale up substantially? Will you simply build a huge farm of Windows machines and pay for all those server licenses?
Don't get overly emphatic about any of this, you're just asking questions. Once the target has had a chance to think about this - maybe over a period of days, weeks, or even months, depending on the degree to which their brains are set in Microsoft concrete - you can slowly start pointing out the benefits of open platforms.
For example, running Java means using any hardware and OS as your server, today. The WORA creed actually does apply to Java on the server side - we regularly run our server apps on Windows, Linux and Solaris, without changing a line of code. Linux server farms are a heck of a lot cheaper than Windows farms, because of licensing. And if you need a single box that's bigger than any PC-class server, you can't beat the Unix-based hardware that's out there.
Running Java means wide support from multiple vendors, some of them very large and reliable, like IBM and Sun. There's competition amongst vendors in the form of multiple implementations of application servers, JVMs, and Java compilers - you can pick what you need, from open source to expensive enterprise-oriented products. The equivalents on.NET are all single-sourced - no competition, no openness.
The lack of competition within.NET has important implications: Microsoft can't fill all niches, and it doesn't even try. Its offerings are usually skewed towards the most lucrative markets, the biggest enterprises, and as a result smaller businesses that don't need all the features have unnecessary stuff pushed on them. In the Java world, if you want something small and light, you can just download an application server like Jetty, a lightweight but powerful persistence solution like Hibernate, and you've got a kick-ass application development and deployment solution. Powerful open and extensible IDEs abound, with Eclipse being a top contender.
What it comes down to is that companies have to be on some weird kind of crack to think that it makes sense to commit their development to.NET. Microsoft has upped the stakes in platform commitment required from their customers, but it's not offering anything in return. Meanwhile, there's a widely used, widely supported, competitive, successful, open, multi-platform alternative that's available today. The choice here is a no-brainer, folks.
[P.S. for those who object to the Java-centricness of all this, I'm talking about commercial scenarios where Perl, Python etc. are just not considered options. But once companies begin using open solutions, they tend to become more open to other such solutions - I had one IT manager who switched from IIS/ASP to Java/JSP recently ask me where he could download Perl for Windows.]
Trying to use Java for it would mean.. well, using Java. Slow to load and slow to use, the trade off here is responsiveness.
I bet you haven't tried this. It performs fine, we use a Java XML-bound combo box in in-house web apps which replaced traditional two-tier GUI apps. Used by professional data entry operators who love it. It's not slow to load or use.
The nice thing about memetic trolls is it's easy to refute them.
All the languages referenced in your links were not statically typed (Python, Perl, Lisp).
The dynamically-typed languages are very useful and powerful for individual programmers, smart programmers, and small, tightly-knit teams. But static typing is an important feature in the commercial world, where software has to be worked on by ever-changing teams of often mediocre people. Static typing provides an enormous safety net in these environments, and supports capabilities - such as automated refactoring and IDE hinting - which are nowhere near as powerful in dynamically typed languages.
The best way to understand the benefits of static typing is to ask the question "would it help if the computer had more information about the program it was running?" The answer, by many criteria - performance, safety, reliability, maintainability - is yes.
As for p-code, the last widely-used p-code based system that had static typing was probably USCD Pascal, which dates back to at least 1980 or so. Java is certainly an improvement over that. Java did in fact advance the state of the art, quite significantly. Considering that Guy Steele, coinventor of the awesome language Scheme, was on the original Java team, perhaps they got some things right which you haven't understood yet.
Finally, the "XML as flawed S-expressions" meme may have some truth to it, but it's also so misleading that it's valid to characterize it as simply wrong. The real benefit of S-expressions arises in "code is data" languages like Lisp. No-one has yet come up with a statically typed language that supports this model, so it's not valid to claim that Java+XML is a reinvention of Lisp+S-expressions; it's an evolution in a direction in which Lisp has typically been very weak.
If you're enough of an old-timer, you'll know that the.NET hackers will be face down in the dirt with large-caliber bullet holes in their backs soon enough - just as soon as Microsoft comes up with the next strategy du jour, just like all the poor VB programmers who were put out to pasture with VB.NET.
If you want quad CPU, you have to go Intel - AMD doesn't support quad. Quad systems tend to be very expensive, though (anyone who knows differently, please tell me!) You might be better off going to a server farm solution with a number of cheaper boxes, if possible.
Dual CPU systems are a pretty ordinary item these days - any reputable vendor that sells them should be fine. There, you have a choice of AMD or Intel. As the submitter of this topic points out, though, if you're specifying parts yourself (even if someone else is building them for you), at the lower end you'll find the Intel solution can be quite a bit cheaper overall, because of the low cost and wide selection of dual CPU Intel motherboards.
So if you're looking for a low cost, high performance dual CPU setup, Intel is the answer. But if you must have AMD for whatever reason, find a vendor who'll sell you something similar to the Ars Technica God Box. The Tyan Tiger MPX motherboard is excellent.
The headline and story is pure sensationalism. SmartFilter isn't blocking sourceforge, the individual company is.
The headline "All Sourceforge.net Being Blocked by SmartFilter" applies perfectly to your statement: if an individual company chooses to use SmartFilter to block certain categories, all of sourceforge.net will be blocked, thus "all Sourceforge.net is being blocked by SmartFilter".
Personally, I think it's an interesting story that's worth posting. Many companies use open source software for their own development - I work for one. We're using at least one Sourceforge project, in fact. OTOH, many other companies might really wish to restrict access to Sourceforge, for the usual perverse legalistic and fascistic reasons. If it's true that Sourceforge was added to the Smartfilter list for those kinds of reasons, I think that's worth discussing.
Slashdot Mirror
That expansion and contraction might equally be described as "natural" rather than artificial, in the sense that it's a reflection of human nature. Perfect markets only exist when the participants don't use emotion and whim as decision factors.
100 is evenly divisible by 2,4,5,10,20, and 50. So dividing the day into 10 hours, each of which contains 100 minutes, and each minute of which contains 100 seconds, would probably be just as convenient.
You're defending the original reasons for the choice of base 6, which was the divisibility of numbers like 24. The question is whether that's really a benefit now that other numbering systems are metric, and given the greater arithmetic and mathematical sophistication that exists today.
What reason is that? Afaik, it dates back 4000 years or more to the Sumerians or Babylonians and their base 6 number systems. Are you aware of any other reasons? I think today, the reasons are strictly "legacy".
Slashdotted already? Here's the Google cache of the page.
You're still missing the most important point, which is that critical business systems can't always be developed by small teams. What works for a small team doesn't necessarily work for larger teams, and what works for development of an application over a short timescale doesn't necessarily work for evolution of that application over a longer timescale as the team changes. This is one of the major areas in which I'm saying static typing is important.
You don't understand Lisp-like macros.
No, you didn't understand what I was saying, specifically:
Custom languages are a good thing.
I completely agree. And I'm saying that Lisp macros are simply a convenient but also limited way to prototype a custom language. There are other ways, and the only real benefit that Lisp macros provides is a low barrier to entry. XML offers a similiar capability, as it happens, but there are other means to that end also, such as simply implementing a domain-specific language using a grammar and parser generator.
You completely miss that macros are _compile time_ and for the most part not runtime.
You plucked that out of nowhere. I talked about code generation as an alternative to macros, and that would be a compile time operation.
They are essentially a meta-programming language.
Correct. And there's nothing to stop you from developing your own meta-programming languages - macros simply lower the barriers to entry for this. If you're misled into thinking that macros are the only way or even the best way to achieve this end, though, then macros are doing you a disservice. They're a shortcut, and they exhibit the typical tradeoffs of a shortcut.
Riiight. Delphi, C/C++, Perl, Smalltalk. Are you that damn ignorant?
Ha! If you think those languages are so different from each other, you prove my point perfectly. I haven't seen you mention any logic languages, or functional languages (Scheme doesn't count, since I brought it up, and you've primarily been talking about CL). You seem to be stuck on a particular kind of semantics, specifically mutable languages with class-based object orientation, or subsets thereof. It's certainly true that the dominant and popular languages all tend to have these kinds of semantics, but I'm saying you need to learn how to apply the appropriate principles, regardless of the language you're using.
NO WAY! And all this time I was using macros as training wheels. I could have been abstracting all my code away.
In my consulting experience, this is absolutely true. You probably write a lot of code which could be abstracted away. Sometimes it's done because of the startup costs involved in developing generic solutions, and that's certainly an area where macros can help, but they're not a silver bullet, and one of the reasons is maintainability.
I understand fully. You have to keep your boss happy, which keeps his boss happy, which keeps the CEO happy, which demands that the IT department is buzzword-compatible.
This is simply the explanation you use to sooth yourself and to justify not extending your knowledge into areas with which you're less comfortable. I don't have a boss, and I sell to customers on the basis of being able to deliver working, in-house maintainable, extensible systems at competitive prices. BTW, I've never met a CEO that demands that his IT department is buzzword compatible, but they do tend to demand things like good return on investment, which includes the ability to extend and maintain systems, often over decades. Choice of a language like Java gets made far more for legitimage reasons of addressing business risk than you realize.
I don't see what the point of it is. Just use C/C++. It's more "write once, run anywhere" than Java will ever hope to be.
You're clearly talking from a complete lack of experience. I've worked on large, cross platform C and C++ systems, and I've worked on large, cross platform Java systems. With the caveat that the Java systems are server-based, there's no question that Java is immeasurably more portable than C++ across different compilers and OSes. We move our server side Java apps between OSes without changing a line of code, and without a single line of conditional code. Switching between compilers is completely transparent. There tends to be more variations amongst VMs, but nothing compared to the variation between platforms when using C++, even with portable class frameworks.
Make that a 10Mbit/s connection...
There's no question that Craig's answer was required by the executive and legal team at Google. What would you have him do, stiff all his co-workers? That's just naive.
But your sig demonstrates that you're paranoid about this kinda stuff, so I guess there's not much point trying to argue you out of your worldview - especially since after this latest boneheaded post of yours, I'm out to get you too. Self-fulfilling prophecy, I guess.
IOW, you're guessing that Google could serve all its traffic over a single 100Mbit/s connection, i.e. the LAN card in my PC? That seems kinda modest, surely?
Learn to comprehend! You were saying Java (and XML) was simply reinvention, and I was pointing out ways in which Java at least combined things in a new and useful way. Focusing on a single statement about Pascal the way you did completely missed what I was saying. I said that UCSD Pascal, which used a p-code interpreter, was not object-oriented. Delphi is irrelevant to that statement. I realize you misunderstood me, but the vehemence of your responses, elicited by your own misunderstanding, doesn't do you credit.
In 1995 and earlier, using a VM was absurd in most cases. You obviously never touched Java then.
I began working with Java when the first public betas became available, which was around '95, IIRC. In addition, I worked on the object-oriented engine for a commercial p-code based dynamically-typed language between 1991 and 1995. Your claim that "a VM was absurd in most cases" seems like a narrow perspective to me. VMs have had a very important role in serious software development, dating back to the IBM 360 mainframes in the '60s, and the precursors to the IBM VM OS.
You continue to throw out examples of conventional "wisdom" which don't hold up to scrutiny, and presumably reflect a lack of direct exposure to these things, such as "write once, test everywhere" related to Java. Focusing on Java as a system for developing GUI applications (which is what you have to be doing to come to the conclusions you do) completely misses the point. Java, as a server-side language, meets the WORA claim, and does not need to be "tested everywhere". We and many other large commercial organizations deploy Java server applications on Solaris, Linux, and Windows without needing anything more than a sanity test on platforms other than our primary test platform.
If the same significance was placed on Lisp, Smalltalk, etc. as is on Java, we would have developments by leaps and bounds.
The first thing that would be needed for serious commercial use is the addition of static typing. If you know anything about type theory, you'd realize that this has significant implications for a language. If you love Lisp so much, you would probably hate the result.
Consider Java. They choose not to use S-expressions. Now they don't have the macro capabilities of Lisp-like languages
You're allowing your narrow viewpoint to unnecessarily constrain your capabilities. It's easy to achieve macro-like functionality in Java. Take a look at tools like AspectJ for commercial examples of macro-like functionality being used in Java. Most larger Java shops do some code generation somewhere along the line.
When you really think about it, and if you have experience generating code in other languages, you realize that Lisp macros are a minor convenience - kind of like training wheels - that help you create custom languages. If you're saying you can't achieve the same capabilities in other languages, you're making a statement about your limitations as a programmer.
If you allow the features of a single language or a set of similar languages to constrain your thinking about programming, you're guaranteed to hate any system that doesn't provide the exact features you need in the exact form you're used to. It sounds to me as though you're doing that.
When you become a truly good programmer, you realize what matters are the abstractions that you design. The language you use to implement those abstractions, in a sense, becomes an implementation detail. There are certainly many valid objections that can be brought against a language like Java, as there are for CL and Scheme. But when you actually take the time to examine why those limitations exist, in many cases you find the reasons may be more valid than you thought, and that there's a tradeoff involved. You then have to decide which side of the tradeoff you want to take. In commercial development, there are some good reasons to make some of the tradeoffs that Java makes. Your wish that as much focus be applied to Lisp and Smalltalk simply ignores this, which makes it nothing more than an impractical pipedream.
I'm telling you that you don't understand what's important to commercial development. To understand it, you need to look at what businesses are using and what they get out of it. You also need to look honestly at the problems with large and complex dynamically typed and heavily macroed systems - many of them suffer from the Perl problem of write-only code, and this is acknowledged even within the Lisp community. These are problems which languages like Java and even C++ address.
You are then completely dependent upon external architecture working as it should (Sun's Java spec and the Java implementation you choose to purchase and run on). If the Java implementation doesn't work as it should (as specified by Sun), you are shit out of luck.
You're descending into pure FUD now. There are multiple compatible Java VMs, compilers, and application servers today, so your point is strictly academic. Could the Java "platform" somehow splinter in future? Sure. But the future of software developement is always risky, because everything changes so fast. The availability of multiple compatible Java implementations is a benefit which insures against some of that future risk, and is another reason why it's attractive to businesses.
Delphi wasn't a p-code language, and it didn't have the dynamic runtime capabilities Java does. Borland missed the importance of the virtual machine. Sun got that right. What I've pointed out is that Java is unique amongst commercial languages, in combining static typing with a virtual machine with object orientation, and on top of that, improving on the most common OO model, which confused interface with implementation, by adding pure interface types. Name the predecessor that fits this bill: not UCSD p-code, not Delphi, not Lisp. So Java is not simply a reinvention.
My point about successful languages is that there are usually reasons for their success, and if you deliberately blind yourself to those reasons, you're going to be one frustrated puppy - which judging by your messages, you are. Visual BASIC also had reasons for its success, as does Perl.
As for the perfection comment, my point was that Lisp misses out on some important issues, which other languages address. If you simply dismiss that without looking at the things that other tools do better, you're simply sticking your head in the sand. One of those things is static typing, and it's an important issue for large commercial projects, whether you're willing to acknowledge it or not.
As for shitty software, if Lisp were such an improvement over other languages, it would do better in the marketplace - there would be many more Paul Grahams. But when you get down to it, the business case simply isn't there. It's a myth perpetuated by single-language zealots, Graham, Pitman and yourself included. And I say that as a proud Scheme programmer, who fully recognizes the power of s-expressions, macros, code-is-data, and functional programming (not that Lisp really qualifies).
By supporting the definition of types as distinct from any implementation (these are called interfaces in Java), and by checking the types of variables and assignments at compile time, an entire class of errors is caught at compiel time instead of runtime. It's not just about floats and strings, it's about every data type in the system, including complex business types, and every variable in the system, which must have a declared type, and the fact that the integrity of the relationships between values and variables is validated at compile time.
Providing the compiler with all this additional info - specifically, about the types of all your variables - then buys a number of additional capabilities. Your tools now "understand" your code much better, which allows automated refactoring - many Java IDEs support dragging and dropping of methods between classes, classes between packages, renaming of methods, etc., automatically updating the references to those entities as appropriate, because it can tell absolutely where all those references are, which is close to impossible with dynamically typed systems (with the partial exception of academic "soft typing" systems).
So when you talk about "casting schema in concrete", the surprising result is that the dynamic languages can actually end up *less* flexible than a statically-typed language. Take method renaming as an example. If you want to rename a method of a particular class in a dynamically-typed language, no tool can do that for you automatically, because in a reference like "obj.foo()", it's impossible to reliably tell what type "obj" is, and you can't simply rename every "foo" throughout the system, since some of them may belong to a different class than the one whose method you're trying to rename.
In a statically typed language, the type of every variable is known, and this kind of renaming and other refactoring can be performed automatically and reliably throughout a system. In addition, in cases where a refactoring requires some manual changes, the areas requiring changes generate compiler errors, so are clearly identified; again, a dynamic language can't do this, except by crashing at runtime. Static typing allows refactoring to become automated and reliable, which improves the maintainability and flexibility of systems.
BTW, as for generic code and reflection, it's not uncommon to use reflection in Java to map database or other data to Java objects; and interfaces provide a very powerful mechanism for developing generic code in a statically typed environment.
Understand I'm not dissing dynamic languages. I'm a heavy user of a number of dynamic languages, and have developed products for and with dynamic languages. I love the flexibility and ease of prototyping that they provide. However, I am pointing at that there are pros and cons, and that the heavy use of Java in the corporate world is not at all irrational - there are good reasons for it. Another way to think about it is that the type annotations in a program are a kind of documentation that's guaranteed to be in sync with the code.
If you're interested in furthering your education as a programmer, I'd strongly recommend adding a full understanding of static typing to your repertoire. If you can't bring yourself to learn Java in depth, take it to the next level and look at some of the polymorphic type inferencing languages, like Haskell, ML, or OCaml, all of which have the benefit of teaching important functional concepts also. For more rigorous academic coverage of types, check out the book "Types and Programming Languages" by Benjamin C. Pierce.
There is such a thing as courtesy. Your parents might have taught you about it.
Courtesy might include not responding to people as though they've committed some act which you've only imagined.
There's also such a thing as unintended irony, for example a comment about courtesy followed directly by a condescending remark about parents.
As for the professional habit of two-facedness, I've found that sometimes the most effective strategy is to be confrontational when there's a problem, even in a professional setting. The two-faced ones are the ones who are scared to rock the boat, because they're not secure about their own ability to survive an open battle. Their insecurity is usually justified!
BTW, yes, conciseness is a word.
Using the Bill Gates borg isn't childish - aside from the fact that it communicates /.'s bias honestly and concisely, it also satirizes aspects of Microsoft's real-life conduct. Not so much childish as chillingly accurate.
I agree - as Brian Aldiss said, "When childhood dies, its corpses are called adults."
Simple: because the government does such a bad job of it, criminalizing innocent people instead of getting them help, and generally creating more problems than they solve.
Java is not a reinvention of UCSD Pascal. One of the things that's new about Java is the combination of object-orientation (not in Pascal), with interfaces separable from implementation, with static typing, running on a bytecode interpreter which supports runtime loading of modules. This combination is actually quite unique. I don't doubt there are systems, probably academic, that did something along these lines previously, but there's Java was the first to make any kind of impact.
Frankly, if it's anything more than simple trolling, I don't understand the kind of mindless language evangelism that leads someone to try to dismiss a successful language as containing nothing new or no new ideas. This simply implies you don't have very much experience with different languages to realize that there are no perfect languages, everything is a tradeoff, and most languages have some unique strengths and weaknesses. I mentioned Guy Steele in a concise attempt to encapsulate this idea, since he's demonstrated an understanding of these kinds of issues and has created two very different, successful (in different ways) languages.
I said all of those were reinventions (to a certain degree) of Lisp.
Your qualification there is all-important. Reinventing something "to a certain degree" but adding new functionality, like static typing, is not reinventing, it's building on what's come before, which is how nearly all technological and academic progress occurs. Java represents such progress, even over Lisp. No, it doesn't address every niche that Lisp addresses (which is why I use both Scheme and Java myself), but Lisp doesn't address every niche that Java addresses, either. Are you quite sure your reinvention meme isn't simply annoyed FUD, driven by a prejudice against the unfamiliar?
There's hardly an MS shop out there that hasn't felt some misgivings about Microsoft and specifically .NET over the past couple of years - whether because of Microsoft tightening the licensing screws, dumping support for Java, radically changing VB for .NET, or pushing a brand new language (C#) for Microsoft's own benefit, or simply all the information that's come out in court which makes it clear that Microsoft has always been more than willing to screw their customers to make a buck.
IOW, Microsoft has provided us with an enormous amount of FUD ammunition, all we have to do is load up and start firing. Don't be too in-your-face about it, though. Instead, start by asking questions:
Don't get overly emphatic about any of this, you're just asking questions. Once the target has had a chance to think about this - maybe over a period of days, weeks, or even months, depending on the degree to which their brains are set in Microsoft concrete - you can slowly start pointing out the benefits of open platforms.
For example, running Java means using any hardware and OS as your server, today. The WORA creed actually does apply to Java on the server side - we regularly run our server apps on Windows, Linux and Solaris, without changing a line of code. Linux server farms are a heck of a lot cheaper than Windows farms, because of licensing. And if you need a single box that's bigger than any PC-class server, you can't beat the Unix-based hardware that's out there.
Running Java means wide support from multiple vendors, some of them very large and reliable, like IBM and Sun. There's competition amongst vendors in the form of multiple implementations of application servers, JVMs, and Java compilers - you can pick what you need, from open source to expensive enterprise-oriented products. The equivalents on .NET are all single-sourced - no competition, no openness.
The lack of competition within .NET has important implications: Microsoft can't fill all niches, and it doesn't even try. Its offerings are usually skewed towards the most lucrative markets, the biggest enterprises, and as a result smaller businesses that don't need all the features have unnecessary stuff pushed on them. In the Java world, if you want something small and light, you can just download an application server like Jetty, a lightweight but powerful persistence solution like Hibernate, and you've got a kick-ass application development and deployment solution. Powerful open and extensible IDEs abound, with Eclipse being a top contender.
What it comes down to is that companies have to be on some weird kind of crack to think that it makes sense to commit their development to .NET. Microsoft has upped the stakes in platform commitment required from their customers, but it's not offering anything in return. Meanwhile, there's a widely used, widely supported, competitive, successful, open, multi-platform alternative that's available today. The choice here is a no-brainer, folks.
[P.S. for those who object to the Java-centricness of all this, I'm talking about commercial scenarios where Perl, Python etc. are just not considered options. But once companies begin using open solutions, they tend to become more open to other such solutions - I had one IT manager who switched from IIS/ASP to Java/JSP recently ask me where he could download Perl for Windows.]
I bet you haven't tried this. It performs fine, we use a Java XML-bound combo box in in-house web apps which replaced traditional two-tier GUI apps. Used by professional data entry operators who love it. It's not slow to load or use.
All the languages referenced in your links were not statically typed (Python, Perl, Lisp).
The dynamically-typed languages are very useful and powerful for individual programmers, smart programmers, and small, tightly-knit teams. But static typing is an important feature in the commercial world, where software has to be worked on by ever-changing teams of often mediocre people. Static typing provides an enormous safety net in these environments, and supports capabilities - such as automated refactoring and IDE hinting - which are nowhere near as powerful in dynamically typed languages.
The best way to understand the benefits of static typing is to ask the question "would it help if the computer had more information about the program it was running?" The answer, by many criteria - performance, safety, reliability, maintainability - is yes.
As for p-code, the last widely-used p-code based system that had static typing was probably USCD Pascal, which dates back to at least 1980 or so. Java is certainly an improvement over that. Java did in fact advance the state of the art, quite significantly. Considering that Guy Steele, coinventor of the awesome language Scheme, was on the original Java team, perhaps they got some things right which you haven't understood yet.
Finally, the "XML as flawed S-expressions" meme may have some truth to it, but it's also so misleading that it's valid to characterize it as simply wrong. The real benefit of S-expressions arises in "code is data" languages like Lisp. No-one has yet come up with a statically typed language that supports this model, so it's not valid to claim that Java+XML is a reinvention of Lisp+S-expressions; it's an evolution in a direction in which Lisp has typically been very weak.
If you're enough of an old-timer, you'll know that the .NET hackers will be face down in the dirt with large-caliber bullet holes in their backs soon enough - just as soon as Microsoft comes up with the next strategy du jour, just like all the poor VB programmers who were put out to pasture with VB.NET.
Dual CPU systems are a pretty ordinary item these days - any reputable vendor that sells them should be fine. There, you have a choice of AMD or Intel. As the submitter of this topic points out, though, if you're specifying parts yourself (even if someone else is building them for you), at the lower end you'll find the Intel solution can be quite a bit cheaper overall, because of the low cost and wide selection of dual CPU Intel motherboards.
So if you're looking for a low cost, high performance dual CPU setup, Intel is the answer. But if you must have AMD for whatever reason, find a vendor who'll sell you something similar to the Ars Technica God Box. The Tyan Tiger MPX motherboard is excellent.
The headline "All Sourceforge.net Being Blocked by SmartFilter" applies perfectly to your statement: if an individual company chooses to use SmartFilter to block certain categories, all of sourceforge.net will be blocked, thus "all Sourceforge.net is being blocked by SmartFilter".
Personally, I think it's an interesting story that's worth posting. Many companies use open source software for their own development - I work for one. We're using at least one Sourceforge project, in fact. OTOH, many other companies might really wish to restrict access to Sourceforge, for the usual perverse legalistic and fascistic reasons. If it's true that Sourceforge was added to the Smartfilter list for those kinds of reasons, I think that's worth discussing.