Depends on your application. Bandwidth is certainly one limitation, but there is plenty of stuff that is still processor bound.
For example, if your processor was fast enough you could do accurate physics modelling in real-time. The amount of data is quite small (not memory bound) but the number of equations you have to solve are enormous.
This would be fantastic for 3D games - objects would behave like like do in the real world rather then being forced to follow strict animated sequences. You could model chains, pulleys, swaying bridges, tumbling crates, bouncing balls, ramps etc.
Thanks to the GeForce and other high-end graphics cards we have the power to render scenes with this level of complexity, it's just a shame that we don't yet have the processor horsepower to accurately model them.
You may well be wrong about the functional languages.
It won't be long before the overheads of FP will be pretty negligible compared to the increased programmer productivity and software robustness. This advantage will gradually start to overcome inertia in the marketplace and start to make a real impact.
Also, with the incresing use of Virtual Machines as an execution platform it's going to get a lot easier to use functional languages and integrate them into larger projects. My bet is that something like Haskell will suddenly start to make headlines in the next couple of years on the.NET platform.
A compiler is basically a program which converts a program in a source language (A) to a target langage (B). The compiler itself is written in a language (C) which may or may not be equal to A or B.
Therefore lot of compilers can never compile themselves, since they are written in a langauage other than the one that they compile. I suspect, for example, that the Visual Basic compiler is written in C++, and therefore cannot self-compile.
In the case that A = C, the compiler can compile itself assuming that it supports a sufficiently large feature set from the language. This is the point that the Mono project has apparently reached. This is a decent achievement for a complex compiler, since it suggests that the project is getting near to being feature complete.
You could probably write a self-hosting toy compiler relatively quickly if that was your goal. Especially if you chose a "nice" target language, i.e. something like Scheme rather than x86 assembler.....
I have always thought of OOP as fundamentally a procedural programming technique but extended to give you better ability to organise and manage larger projects. C++ is a superset of C - you don't have to use the OOP features but they can help you enormously in the right situation.
OOP also encourages good programming practices like producing well-defined interfaces, implementation hiding and code re-use. I actually think these are crucial to the effectiveness of OOP. These are all good things, and I'm sufficienctly lazy that I would never write anything other than a trivial program in purely procedural style.
However, OOP is still best suited to particular domains. Modelling, GUIs, enterprise applications, games etc. are perfect because they all require the manipulation of discrete and readily identifiable "objects" that map onto the OOP model very well.
If you're writing network drivers, you could use OOP, but as other posters have been keen to point out the (very small) overhead of most OOP languages actually becomes a problem for very low-level code. Hence OOP isn't so well suited for OS kernel code, network protocols, hand optimised inner loops and embedded applications.
The difference between procedural and OOP is mainly a trade-off between low level control of the machine and having a semi-automated system to manage the complexity for you. Interestingly, for larger projects, good programmers in procedural langauages often end up having lots of function calls that take the "object to be acted on" as an argument and are therefore effecively emulating method calls. Once they start putting in switch statements in those functions to branch on the type of object encountered, they have effectively emulated virtual methods.
Your case is an interesting one. You are dealing with mathematical/engineering problems that are often tackled in a procedural style.
If you're feeling adventurous, I would actually suggest you head off to look at functional langauges. Reason is that these langauges are ideally suited for representing functions and other mathematical constructs, just as OOP is geared towards representing and manipulating "objects". Haskell would be my no.1 choice if you're looking for elegance and flexibility, O'Caml if you are more concerened about raw performance.
If these seem too radical a departure, then I still think that OOP could make sense for a major project. You probably wouldn't need inheritance, but implementation hiding can be very useful. Let's say you're modelling fluid dynamics, and do it procedural style with a big array. Works fine until you decide that in fact you want to store the data in an octree so that you can get a couple of orders of magnitude better resultion in the particular areas you are interested in. At that point you have to change everything that accesses the data structure, including the 100 or so simulation programs you've been developing. Not fun. If OTOH you had encapsulated it all in an object, you would just change the object's private implementation, keeping all accessor methods the same (e.g. getFluidVelocity(x,y,z), getPressure(x,y,z) or whatever, I'm not an engineer:-). In this case, all the code that used the object would remain the same, possibly saving you a load of work.
It's also often useful to have data represented as objects just so you can do useful things like pass the around, build larger data structures etc. Not that you can't do this in procedural style, but OOP takes away all the pain. I've lost track of the number of times I have taken advantage of all the useful features like object serialization in Java, which saves you all the hassle of having to write import/export functions to store your data structures on disk.
Ultimately, use what seems right for your application. But remember that OOP and other techniques such as functional programming aren't just fads, they are ways to solve problems that procedural style just isn't well suited for. If you find yourself spending too much time writing the "glue" to hold a big application together, then it's a good sign that you've actually picked the wrong tool.
Re:change the keyboard, change ASCII ...
on
The Euro
·
· Score: 2
Some of us who write code actually find those keys quite useful.....
Hmmm.... you're seriously underestimating the cost base in large companies.
A company with a sufficiently large number of returns has to set up a reverse supply chain. This can mean new computer systems, managers, re-packaging equipment, procedures, lawyers etc. It costs a fortune, and even worse can take up valuable senior management time which cuts down their ability to react in the marketplace.
Therefore most companies don't bother. They take the return as a loss and/or sell returned product at a mark-down price. Plus there's the additional store and supply chain staff needed to physically handle the returns and issue refunds.
Believe me, returns hurt the bottom line either way.
Example: One retailer I worked at reckoned they lost 40-50% of the sale price for every item returned. This was more than their margin, so they most certainly made a loss. I don't think this is untypical.
Basically, if retailers started seeing a significant number of return on copy-protected CDs, they would start to worry, and start to ask questions. Their buyers (the reccord companiesw customers, remember?) will most certainly take action if their boss tells them to "sort out this returns problem with Universal CDs".
Basically, I think the returns option could work if you manabged to add a few percentage points to the return rate. Difficult given the number of sheep out there, but if enough people were willing to put the effort in......
Big Blue was perhaps a monopoly, but it didn't have something called "barriers to entry". Hence lots of nible competitirs leapt in, cut prices, improved quality and gained market share. We ended up with a pretty competitive PC market. That's how markets *should* work.
I have not so far seen a shred of evidence that any commercial competitor is seriously challenging Microsoft on the desktop, and by extension, many related areas of computing. The barriers to entry are just too large. Hence I do not see anyone about to "stop buying Microsoft" because there isn't actually any choice.
If microsoft have less than 50% market share and credible competitors in all areas of the software business it might be different. But I don't see that happening anytime soon....
100% is bullshit. I've worked for Record Retailers before and can assure you that they make far less than that in Gross Margins, never mind after you've stripped out the store and distribution expenses. All a ballpark figure, gross margins might be 25-35%, 5-10% after costs.
Gross margins are low in music retail because the retail market is very competitive - It's relatively easy to sell CDs since they are standardised products and the purchasers are generally price sensitive and will shop around in their local area.
High prices in music are all about the *monopoly* power that record companies have. It's monopoly power because they manage to manufacture a "must have" status for their products and they are the only supplier. This means that they can get away with charging very high prices without losing custom. Neat trick, but a complete scam nonetheless.
British Telecom has nothing to do with the UK government. It's called British Telecom because it's a Telecom company and it's, er, British?
It is certainly a monopoly that stinks however. They have been single-handedly responsible for holding back the introduction of Broadband to the UK for years to protect their exiting high-margin ISDN services. Bastards....
Interesting viewpoint, but I could argue that the right of Privacy does not extend to business transactions.
Transparency in business is almost always a good thing, I don't think it's a coincidence that the world's richest countries tend to be the ones with the most open financial systems and strongest lwas against corruption/monopolistic practices/insider dealing.
Taken to it's extreme, you could even make the argument that a company should make public *all* of it's dealings. That would make for a far, far more competitive economomy if the only way you could get ahead was by providing better products and services at a lower price. Best practice would spread much faster, fraud and corruption would be much harder and the endless political wranglings in organisations would be tempered by the need to behave decently and operate with a much fairer distribution of information.
Maybe I'm just playing the Devil's Advocate here, but I think there are areas where privacy and the restriction of information flow can be a very bad thing. Business might just be one of them.
Hmmm.... slashdot still can't handle "greater than" and "less than" in plain text mode.
The last sentence of the penultimate paragraph should have read "Once the polygons start hitting less than 10 or so pixels in size, there probably isn't any visible advantage to using curves and we'll stop caring, rather like the way that we stopped bothering about greater than 16,777,216 colours."
Curves aren't impossible, but they're a complete pain to code and the maths involved requires way more computing power than we currently have.
Main problems vs. polygons are the fact that you need to do some nasty calculus to work out how the surface normal and lighting effects change *for every single pixel*. Also, when you render a polygon, the mapping from screen to polygon co-ordinates is trivial. For an arbitrary curved surface, it is very difficult, since a line from the camera could hit the curved surface at various points.
In general, it is much easier to render 100 simple polygons than one curved surface, so most games end up doing it that way. Any curved surface can be approximated to arbitrary accuracy by dividing it up into enough polygons.
This may change in the future, but we're still years off, and it may never happen becuase the power used to calculate curves could just be used to draw ever-smaller polygons. Once the polygons start hitting 16,777,216 colours.
Of course, curved surfaces are still commonplace in raytracing and CSG where accuracy counts and you don't have to draw the screen in 1/100th of a second....
Having used both Visual Studio and Delphi, I can honestly say that Borland is way aheead in the Visual development stakes. If anything, it has been MS playing catch up in terms of tool quality.
Borland lost out to Visual Studio because of that little thing called the OS monopoly. Companies wanted the assurance that their tools are very closely tied to the OS. Borland's products are still IMO much better, and given the much leveller playing field on Linux I really hope they can succeed.
Basically, if you haven't played with Delphi/Kylix before I seriously suggest you give it a shot. It's free to try, goddamit, and I'm sure most good coders can suspend their disdain for Pascal for long enough to realise that it's actually pretty damn good.
OTOH, I think that a fast compile time helps you a lot because it encourages testing. Compile early, compile often is my motto.
Thinking long and hard about a problem is great, but you can still miss something obvious that you would notice in a second if you just ran the damn thing and watched the garbage pour out.
Deplhi/Kylix was designed very much with a RAD/XP audience in mind so the fast test cycle is very important. If you're doing that properly, you should be putting lots of asserts and sanity checks in your code anyway.
When people were curious about Delphi, I would often just boot it up, and write a full GUI application with database access in about five minutes, and maybe ten lines of code. The same thing in C++ might take that long just to compile:-)
Actually, single pass compilation makes sod all difference. A pass to scan a parsed file for declarations might take 1% of your time if that. Putting all the declarations at the top is more of a Pascal convention for declaring your interfaces than anything else.
The main compilation-time advantages Pascal has over C/C++ are a simple, elegant langauge syntax, no complex preprocessor, general avoidance of header files, and the fact that modules ("units" in OP-speak) are almost always pre-compiled into a format that makes linking quick (these also double as pseudo-header files). Add to all that the fact that Borland are simply very good compiler writers.
Of course, you lose stuff from C++ that some people (including myself) use a lot such as macros, templates, multiple inheritance etc. Whether you actually need these is debatable, but their exclusion certainly makes for a clean language that is pretty beginner and maintainer friendly.
Last time I used Borland Pascal, it was also pretty good at stuff like dead-code elimination - not sure how GCC compares there.
IBM probably don't actually care much about the OS - they're much more interested in the cross-platform application servers like WebSphere, DB2 and such which is where the money is. They sell these for Windows, Linux, Solaris, whatever.
They mainly want to make sure Microsoft can't extend it's monopoly into these areas as well. That means establishing Linux as a credible alternative and commoditising the OS space, while building additional services around it.
Pretty sound strategy for them, Linux fans had better hope it works because right now it's the main chance Linux has ofd displacing Microsoft to any significant degree.
I will not ignore just because it comes from Microsoft. But I probably will end up ignoring it because Microsoft won't port the libraries properly.
Not much point being able to run the bytecode if it can't access the network, the GUI or the filesystem.
I will use and support.NET if and only if it results in *any*.NET program being portable to *any* system. That means no COM dependancies, no requirements for a Win32 OS, no MS-only protocols and properly open file formats. I'm not really expecting to see any of these. Are you?
Slashdot Mirror
True, although it is a fast Java compiler, which was what we were talking about. It's a bloody tool, so who cares what it's written in?
True, Scheme a great language. Haven't used it much apart from skimming through SICP though :-)
If I remember correctly, Scheme doesn't have types or lazy evaluation? They are the two main reasons I would go for Haskell right now.
Depends on your application. Bandwidth is certainly one limitation, but there is plenty of stuff that is still processor bound.
For example, if your processor was fast enough you could do accurate physics modelling in real-time. The amount of data is quite small (not memory bound) but the number of equations you have to solve are enormous.
This would be fantastic for 3D games - objects would behave like like do in the real world rather then being forced to follow strict animated sequences. You could model chains, pulleys, swaying bridges, tumbling crates, bouncing balls, ramps etc.
Thanks to the GeForce and other high-end graphics cards we have the power to render scenes with this level of complexity, it's just a shame that we don't yet have the processor horsepower to accurately model them.
You may well be wrong about the functional languages.
.NET platform.
It won't be long before the overheads of FP will be pretty negligible compared to the increased programmer productivity and software robustness. This advantage will gradually start to overcome inertia in the marketplace and start to make a real impact.
Also, with the incresing use of Virtual Machines as an execution platform it's going to get a lot easier to use functional languages and integrate them into larger projects. My bet is that something like Haskell will suddenly start to make headlines in the next couple of years on the
There are quite a few Java compiler implementations other than the Sun reference version.
The IBM Java compiler (Jikes) is much much faster than javac, for example, and does exactly the same job.
A compiler is basically a program which converts a program in a source language (A) to a target langage (B). The compiler itself is written in a language (C) which may or may not be equal to A or B.
Therefore lot of compilers can never compile themselves, since they are written in a langauage other than the one that they compile. I suspect, for example, that the Visual Basic compiler is written in C++, and therefore cannot self-compile.
In the case that A = C, the compiler can compile itself assuming that it supports a sufficiently large feature set from the language. This is the point that the Mono project has apparently reached. This is a decent achievement for a complex compiler, since it suggests that the project is getting near to being feature complete.
You could probably write a self-hosting toy compiler relatively quickly if that was your goal. Especially if you chose a "nice" target language, i.e. something like Scheme rather than x86 assembler.....
I have always thought of OOP as fundamentally a procedural programming technique but extended to give you better ability to organise and manage larger projects. C++ is a superset of C - you don't have to use the OOP features but they can help you enormously in the right situation.
:-). In this case, all the code that used the object would remain the same, possibly saving you a load of work.
OOP also encourages good programming practices like producing well-defined interfaces, implementation hiding and code re-use. I actually think these are crucial to the effectiveness of OOP. These are all good things, and I'm sufficienctly lazy that I would never write anything other than a trivial program in purely procedural style.
However, OOP is still best suited to particular domains. Modelling, GUIs, enterprise applications, games etc. are perfect because they all require the manipulation of discrete and readily identifiable "objects" that map onto the OOP model very well.
If you're writing network drivers, you could use OOP, but as other posters have been keen to point out the (very small) overhead of most OOP languages actually becomes a problem for very low-level code. Hence OOP isn't so well suited for OS kernel code, network protocols, hand optimised inner loops and embedded applications.
The difference between procedural and OOP is mainly a trade-off between low level control of the machine and having a semi-automated system to manage the complexity for you. Interestingly, for larger projects, good programmers in procedural langauages often end up having lots of function calls that take the "object to be acted on" as an argument and are therefore effecively emulating method calls. Once they start putting in switch statements in those functions to branch on the type of object encountered, they have effectively emulated virtual methods.
Your case is an interesting one. You are dealing with mathematical/engineering problems that are often tackled in a procedural style.
If you're feeling adventurous, I would actually suggest you head off to look at functional langauges. Reason is that these langauges are ideally suited for representing functions and other mathematical constructs, just as OOP is geared towards representing and manipulating "objects". Haskell would be my no.1 choice if you're looking for elegance and flexibility, O'Caml if you are more concerened about raw performance.
If these seem too radical a departure, then I still think that OOP could make sense for a major project. You probably wouldn't need inheritance, but implementation hiding can be very useful. Let's say you're modelling fluid dynamics, and do it procedural style with a big array. Works fine until you decide that in fact you want to store the data in an octree so that you can get a couple of orders of magnitude better resultion in the particular areas you are interested in. At that point you have to change everything that accesses the data structure, including the 100 or so simulation programs you've been developing. Not fun. If OTOH you had encapsulated it all in an object, you would just change the object's private implementation, keeping all accessor methods the same (e.g. getFluidVelocity(x,y,z), getPressure(x,y,z) or whatever, I'm not an engineer
It's also often useful to have data represented as objects just so you can do useful things like pass the around, build larger data structures etc. Not that you can't do this in procedural style, but OOP takes away all the pain. I've lost track of the number of times I have taken advantage of all the useful features like object serialization in Java, which saves you all the hassle of having to write import/export functions to store your data structures on disk.
Ultimately, use what seems right for your application. But remember that OOP and other techniques such as functional programming aren't just fads, they are ways to solve problems that procedural style just isn't well suited for. If you find yourself spending too much time writing the "glue" to hold a big application together, then it's a good sign that you've actually picked the wrong tool.
Some of us who write code actually find those keys quite useful.....
Hmmm.... you're seriously underestimating the cost base in large companies.
A company with a sufficiently large number of returns has to set up a reverse supply chain. This can mean new computer systems, managers, re-packaging equipment, procedures, lawyers etc. It costs a fortune, and even worse can take up valuable senior management time which cuts down their ability to react in the marketplace.
Therefore most companies don't bother. They take the return as a loss and/or sell returned product at a mark-down price. Plus there's the additional store and supply chain staff needed to physically handle the returns and issue refunds.
Believe me, returns hurt the bottom line either way.
Example: One retailer I worked at reckoned they lost 40-50% of the sale price for every item returned. This was more than their margin, so they most certainly made a loss. I don't think this is untypical.
Basically, if retailers started seeing a significant number of return on copy-protected CDs, they would start to worry, and start to ask questions. Their buyers (the reccord companiesw customers, remember?) will most certainly take action if their boss tells them to "sort out this returns problem with Universal CDs".
Basically, I think the returns option could work if you manabged to add a few percentage points to the return rate. Difficult given the number of sheep out there, but if enough people were willing to put the effort in......
Big Blue was perhaps a monopoly, but it didn't have something called "barriers to entry". Hence lots of nible competitirs leapt in, cut prices, improved quality and gained market share. We ended up with a pretty competitive PC market. That's how markets *should* work.
I have not so far seen a shred of evidence that any commercial competitor is seriously challenging Microsoft on the desktop, and by extension, many related areas of computing. The barriers to entry are just too large. Hence I do not see anyone about to "stop buying Microsoft" because there isn't actually any choice.
If microsoft have less than 50% market share and credible competitors in all areas of the software business it might be different. But I don't see that happening anytime soon....
100% is bullshit. I've worked for Record Retailers before and can assure you that they make far less than that in Gross Margins, never mind after you've stripped out the store and distribution expenses. All a ballpark figure, gross margins might be 25-35%, 5-10% after costs.
Gross margins are low in music retail because the retail market is very competitive - It's relatively easy to sell CDs since they are standardised products and the purchasers are generally price sensitive and will shop around in their local area.
High prices in music are all about the *monopoly* power that record companies have. It's monopoly power because they manage to manufacture a "must have" status for their products and they are the only supplier. This means that they can get away with charging very high prices without losing custom. Neat trick, but a complete scam nonetheless.
British Telecom has nothing to do with the UK government. It's called British Telecom because it's a Telecom company and it's, er, British?
It is certainly a monopoly that stinks however. They have been single-handedly responsible for holding back the introduction of Broadband to the UK for years to protect their exiting high-margin ISDN services. Bastards....
Interesting viewpoint, but I could argue that the right of Privacy does not extend to business transactions.
Transparency in business is almost always a good thing, I don't think it's a coincidence that the world's richest countries tend to be the ones with the most open financial systems and strongest lwas against corruption/monopolistic practices/insider dealing.
Taken to it's extreme, you could even make the argument that a company should make public *all* of it's dealings. That would make for a far, far more competitive economomy if the only way you could get ahead was by providing better products and services at a lower price. Best practice would spread much faster, fraud and corruption would be much harder and the endless political wranglings in organisations would be tempered by the need to behave decently and operate with a much fairer distribution of information.
Maybe I'm just playing the Devil's Advocate here, but I think there are areas where privacy and the restriction of information flow can be a very bad thing. Business might just be one of them.
Hmmm.... slashdot still can't handle "greater than" and "less than" in plain text mode.
The last sentence of the penultimate paragraph should have read "Once the polygons start hitting less than 10 or so pixels in size, there probably isn't any visible advantage to using curves and we'll stop caring, rather like the way that we stopped bothering about greater than 16,777,216 colours."
Curves aren't impossible, but they're a complete pain to code and the maths involved requires way more computing power than we currently have.
Main problems vs. polygons are the fact that you need to do some nasty calculus to work out how the surface normal and lighting effects change *for every single pixel*. Also, when you render a polygon, the mapping from screen to polygon co-ordinates is trivial. For an arbitrary curved surface, it is very difficult, since a line from the camera could hit the curved surface at various points.
In general, it is much easier to render 100 simple polygons than one curved surface, so most games end up doing it that way. Any curved surface can be approximated to arbitrary accuracy by dividing it up into enough polygons.
This may change in the future, but we're still years off, and it may never happen becuase the power used to calculate curves could just be used to draw ever-smaller polygons. Once the polygons start hitting 16,777,216 colours.
Of course, curved surfaces are still commonplace in raytracing and CSG where accuracy counts and you don't have to draw the screen in 1/100th of a second....
Fair enough. I don't mind either way, though it always seems to take a day or two to switch my mind from one convention to another.....
:-)
Still, my favourite langauges have to be the pure functional ones like Haskell. Type inference is a godsend, and who needs mutable variables anyway
Having used both Visual Studio and Delphi, I can honestly say that Borland is way aheead in the Visual development stakes. If anything, it has been MS playing catch up in terms of tool quality.
Borland lost out to Visual Studio because of that little thing called the OS monopoly. Companies wanted the assurance that their tools are very closely tied to the OS. Borland's products are still IMO much better, and given the much leveller playing field on Linux I really hope they can succeed.
Basically, if you haven't played with Delphi/Kylix before I seriously suggest you give it a shot. It's free to try, goddamit, and I'm sure most good coders can suspend their disdain for Pascal for long enough to realise that it's actually pretty damn good.
Just curious as to why you think the declarations are more logical one way than the other....
:-)
Is that just personal choice/comfort or a more fundamental difference?
a: integer;
int a;
dim a as Int
my $a (who cares about types anyway!
All seem to convey pretty much the same logic to me.
OTOH, I think that a fast compile time helps you a lot because it encourages testing. Compile early, compile often is my motto.
:-)
Thinking long and hard about a problem is great, but you can still miss something obvious that you would notice in a second if you just ran the damn thing and watched the garbage pour out.
Deplhi/Kylix was designed very much with a RAD/XP audience in mind so the fast test cycle is very important. If you're doing that properly, you should be putting lots of asserts and sanity checks in your code anyway.
When people were curious about Delphi, I would often just boot it up, and write a full GUI application with database access in about five minutes, and maybe ten lines of code. The same thing in C++ might take that long just to compile
Actually, single pass compilation makes sod all difference. A pass to scan a parsed file for declarations might take 1% of your time if that. Putting all the declarations at the top is more of a Pascal convention for declaring your interfaces than anything else.
The main compilation-time advantages Pascal has over C/C++ are a simple, elegant langauge syntax, no complex preprocessor, general avoidance of header files, and the fact that modules ("units" in OP-speak) are almost always pre-compiled into a format that makes linking quick (these also double as pseudo-header files). Add to all that the fact that Borland are simply very good compiler writers.
Of course, you lose stuff from C++ that some people (including myself) use a lot such as macros, templates, multiple inheritance etc. Whether you actually need these is debatable, but their exclusion certainly makes for a clean language that is pretty beginner and maintainer friendly.
Last time I used Borland Pascal, it was also pretty good at stuff like dead-code elimination - not sure how GCC compares there.
IBM probably don't actually care much about the OS - they're much more interested in the cross-platform application servers like WebSphere, DB2 and such which is where the money is. They sell these for Windows, Linux, Solaris, whatever.
They mainly want to make sure Microsoft can't extend it's monopoly into these areas as well. That means establishing Linux as a credible alternative and commoditising the OS space, while building additional services around it.
Pretty sound strategy for them, Linux fans had better hope it works because right now it's the main chance Linux has ofd displacing Microsoft to any significant degree.
Isn't locking people into windows kind of... er... the whole point of COM?
Remarkably good design considering it's objectives.
The fact that IBM are willing to bet a billion+ on the Java/Websphere/Linux combination has convinced me not to worry about the licensing too much.
You can bet that IBM's lawyers have done the worrying for you.....
Hope that's a typo and you're not really getting JSPs and JavaScript confused - they are two very different technologies with very different uses.
JSPs rock. Javascript is often useful but can be a PITA because you can never really trust client-side technologies.
I will not ignore just because it comes from Microsoft. But I probably will end up ignoring it because Microsoft won't port the libraries properly.
.NET if and only if it results in *any* .NET program being portable to *any* system. That means no COM dependancies, no requirements for a Win32 OS, no MS-only protocols and properly open file formats. I'm not really expecting to see any of these. Are you?
Not much point being able to run the bytecode if it can't access the network, the GUI or the filesystem.
I will use and support