Having used BeOS for a little while. I would say definitely better. Superior might be too grand of a statement. The file system was rock solid and is exactly what MS has been trying to build for the last three years with longhorn. The graphics looked much better and had fewer color calibration issues. for example, the colors you see on the screen are much closer to what prints out. windows still has these problems, unless you go buy expensive calibration software/hardware. The SMP support was pervasive, meaning all application benefit from multiple CPU's without having a programmer go in and change the code. The pre-emptive multi-threading/tasking is much better than the current pre-emptive threading in windows 2K and XP. Give you an example, I could copy a huge 300Mb movie to the disk from a CD and still play a 200Mb movie from the hard drive. Try that with windows 2K or XP and tell me how well it handles that. Better than windows definitely.
no one will care, but the big
on
Java vs .NET
·
· Score: 2, Interesting
problem with.NET is Microsoft is still encouraging bad development habits. I can tell you first hand from reading ASP.NET code written in VB that it is horrendous. Most of the examples included with.NET do not use good OO practices for the C# examples. The worst part is it encourages the same lazy hard to read coding practices. Without fixing that, it won't make.NET any cheaper, it's just another trick to milk more money from customers.
say you have a farm of servers. If microsoft forces updates to all systems, it could potentially break the servers, since it's happened in the past. On a typical home users system it's fine, but corporate server should not get automatic updates. The system administrators and developers should go through regression testing on select boxes before a complex wide patch is applied.
is it fast enough to write a letter and surf the web? Will it mean fewer sales in China and the other Asian countries? Yup. Will it hurt AMD or Intel? Don't know, but I'm sure we'll all find out with time.
What are you talking about. when i used to work in the campus computer lab, we had 4-6 crashes a day on 50% of the systems with windows 3.1/3.11. With windows 95, that number dropped down to about 2-3 a day. The macs on the other crashed once a week or so with OS8. luckily both MacOSX and window 2K have gotten much better, but not perfect. perfect doesn't exist.
the big catch here is the percentage of good/great programmers remain the same regardless of where you go. Be it russia, US, India, China or some other country, there's only a limited number of good programmers. I see this as a growing trend in business and management school that consider human resource purely an issue of cost. Rather than see employees as the core of the business, many are taught the idea employees can be replaced.
Geeks may hate to admit it, but the majority of the managers hate programmers and despise the IT staff. It's very hard to find high level managers that really understand this fact. That's all fine, since they weed themselves out eventually. The more things change, the more it stays the same. There will always be someone ready to replace a failing company that is blinded by statistics and forget the value of the employee. Everything moves in cycles.
#3. I don't believe C# is going to be the "best tool for the job" -- and if you code stored procs in C# -- you are limitted the people you can hire to fix it. (Most be a DBA who knows C#)
I would disagree with this. What if you want to build an event driven architecture and want the ability to send out event messages with triggers, because the size of your database is terabytes. Here is a hypothetical situation.
transaction inserts several rows into table A
trigger kicks off some stored procedures, which results in inserts into table B
if data is inserted into Table B successfully, send a message to JMS server in a async fashion
Now obviously, you could do this with your data abstraction layer like jdbc/ejb/ado.NET or what ever you use. But what happens if you need some pretty sophisticated filtering, which is dynamic? What is the better option and which will scale better? That's a hard question to answer, since it is specific to the problem you want to solve.
I don't have the time to do it, but I would suggest creating a quick test to compare the relative performance of the DOM and XmlTextReader, or even XPathNavigator.
I've run benchmarks, in situations where the entire document is needed and used DOM can be better (depends on use case). Of course if you don't need DOM, then don't use it. The challenge from my perspective is this. If you have a consumer which uses objects and your webservice has to reason over that same object model, you'll probably have to use schema to convert the SOAP message to a C# objects. Once that is a requirement, you're choices are limited. To correctly create an object, you would have to traverse the entire message, instantiate the necessary objects and call the proper method. XmlTextReader is very efficient right, but a process like schema conversion is heavy weight. One option is to use.NET remoting, if the consumer is a VB client or some other.NET client. Read the article by Sosnoski about different parse techniques. He explains it much better than I can.
XmlTextReader is a pull parser right. Therefore it still wouldn't help in situations where the entire message is used by the application. Assuming of course the sender is not including un-necessary data in the message. I believe in those cases, XmlTextReader at best will be equal to DOM. Of course using a different method like.NET Remoting may be an option, if performance is really required and webservices is non-negotiable.
There's an interesting article that compares the different types of parser and their advantage at a fairly low level. Dennis Sosnoski's article on xml performance was included on IBM's site a while back. It's a worth while read.
I'd have to agree with people's assertion that performance intensive apps should use a custom protocol and preferably binary based or some kind of delayed stream parser that only accesses the XML node when the app calls for it. I believe Sun has an API in the works for XML stream parsing JSR 317. It's too bad the jsr is still in public review phase. I've written custom parser in the past using SAX and it can definitely improve performance if you convert it to an object model. The question is trade off between being generalized and performance.
In the case of a webservice that uses schema, it's going to be hard to get around the performance issue. An obvious solution in situations where XML is required is to send as little as possible and only get the nodes you need. In that respect XPP2 and XmlTextReader help, until you need the entire document and you use the whole document.
I fail to see how it is way superior. Different yes, but superior reveals your bias. You can extend the Control class right, but AC is right if API meant interface. My personal preference would be to have a base interface, which Control implements. This way I can use some other custom underlying widget, rather than the default look. And, lets remember that cold fusion probably is the first one to use tag-like syntax for server side controls. cold fusion had a terrible time scaling for heavy loads, but it was the first commercial product that integrated a webserver with tags.
video editing for 3D and animation classes. But now Final Cut Pro is the default standard for film schools and most animation courses. The thing is, Adode has seriously lagged the last couple of releases with Premiere. Adobe had a lead for a long time and simply let the advantage go. Nothing remains constant and innovation requires a sense of pressure and urgency. It looks like Adobe didn't have a sense of urgency until it was too late.
The report hardley takes down OSS or Apache. The report is reasonable and doesn't over extrapolate about quality. For me, the report is encouraging because MS has something like 80 programmers working on IIS and apache is made up of volunteers with far fewer resources, that is pretty darn impressive for alpha code. I haven't looked at the list of active committers lately, but I know it's no where near 80. Draw your own conclusions.
open a black hole and have the plane fly into some other dimension. oh wait, that's only in movies and on TV. what were they smoking when they thought up this dumb idea.
How damn fast does your CPU have to be for the computer to be usable? How many people are so damn impatient that they can't wait walk away from their CD ripping and have dinner while it writes the MP3.
furthermore C# has several useful notions ( delegates, boxed types, attribute annotations,assemblies etc ) not in Java.
Ok, sounds like you bought the whole PR pitch hook line and sinker. I can say from first hand experience C# is not all it's advertised to be. C# has some nice stuff like properties, but several important pieces are seriously hobbled for enterprise class server applications.
delegates - sounds great on the surface until you realize that writing a multi-threaded/thread-safe application means all calls have to go through delegate. this means for each call to a application running in a dedicated thread, two threads are used. One is used by the delegate. Not only that, for server applications, what you really want is to have direct access to that thread.
assemblies - well recently I experience the same old DLL hell with.NET 1.1 colliding with.NET 1.0. Guess what, there are other critical issues like dynamic loading which do not work as well as Java class loaders. In order to dynamically load/unload assemblies, they have to be loaded in a separate appDomain.
attribute annotation - is nice, but it's hardly critical. Not only that, if you work with a bunch of VB guys, they are so far from annotating their code that you'd have a better chance of getting an experience Java programmer to use attribute annotation correctly. I annotate my code aggressively to point out design decisions and their impact down the line. I also include suggestions and ways to modify the code should the functional requirements change.
thread management using the default threadpool class is weak. There was an article recently in.NET magazine that covered async request handling. The article showed that IIS 6.0 uses the stock ThreadPool, which means improving performance requires writing your own thread pool library.
the caching and default threadpool is really intended as an object cache and isn't well suited to complex multi-threaded applications that manage themselves.
currently there is no object persistence application or layer in.NET. At first glance it doesn't seem like a big deal until you need to handle concurrent access to shared data across multiple systems. Say you have 100 clients that need to access a webservice. The webservices is load balanced across n servers. If multiple users modify common data, how do you manage it? Do you lock the table and use pessimistic locking, or do you naively say we allow for delay and don't care? There are third parties providing object persistence layers for.NET.
stateful application server does not exist in.NET and MSDN states it doesn't plan on providing the support in the near future. For the next several releases the focus is on improving.NET CLR and performance.
session replication across n webservers is not supported natively by IIS. The way it's typically done in IIS is to use database sessions. Tomcat 5 will have session replication built in. There are numerous Java application servers and servlet containers that provide true clustering with fault tolerant sessions.
database clustering is not available as a stock option in Sql Server 2000 or Sql Server 64bit. Typically you have to setup Sql server in partitions and manage the data access with ADO.NET or DAL. Normally when Sql Server is setup in a cluster like TPC benchmarks, it's a custom embedded module. Ask any Sql Server DBA is real-time replication works reliably in Sql Server?
there is no enterprise class messaging server and won't be until Biztalk reaches it's second or third release. If you don't believe me, try to use MSMQ to handle thousands of message per second with tens of thousands of subscribers. It will take 5-8 years before Biztalk can even get close to IBM MQSeries.
.NET has it's advantage like the XmlTextReader. The default XML parser in Jav
You can get to 100 req/sec with some heavy duty hardware right. Look at TPC and HP's superdome. I looked at the numbers and it roughly translates to 184 transactions per second per CPU. In the case of the HP TPC results, the full disclosure showed they used embedded C module to crank up the performance of 64bit Sql Server. The server also isn't your typical dual or quad CPU box. The motherboard uses NGIO or something similar which uses switch architecture to share memory across 64 CPU's. I believe mainframes are still king when it comes to multi-CPU setups. The biggest mainframes are capable of supporting 128 CPU's, but you also pay through the nose for it.
There was an article recently on MSDN that talked about async request handling in IIS 6.0, which is supposed to use.NET thread pool instead of the I/O thread pool like IIS 4 and 5. I could be wrong and mis-quoting the facts from the article. The author of the article did use a custom thread pool library to improve async request handling, so there are limitations of the standard thread pool class.
and I've had no problems writing multithreaded listeners and the like
that's actually not uncommon. I'm sure plenty of people have written multi-threaded listeners for simple HTTP server and messaging systems. The hard task is making it handle 2-4K connections/requests per second:) . Having said that, getting any kind of server/NT service to perform at that level is hard. The hardest issues with scalability that I've come across are the result of processes that absolutely had to be sync-ed. Most things you can cheat with async handling, but there are some things like transactional integrity that absolutely need sync access. Of course, most things don't actually need 100% transactional integrity. AFAIK, only hardcore real-time trading systems require that level of synchronization using event driven architecture. trying to scale distributed transaction without a semi-intelligent event system is pretty darn difficult. Many trading systems that claim real-time processing actually have quite a bit of lag (ie, minutes or post-trade-processing) and aren't real-time in the strict technical sense. I've yet to find actual applications written in C# for.NET that comes close to sub-second real-time processing. That doesn't mean there isn't. Just that I'm not aware of them.
CLR has support for explicit threading (create thread, abort thread, rendezvous...) and also a highly efficient thread pool for async execution.
Not sure what AC was referring to, but sounds like it is the equivalent to a NT Service, which would qualify the process as a heavy weight thread. Most of the threading examples given in.NET threading books, MSDN and Technet are client centric, which are not daemons. An example to compare contrast might be a multi-threaded HTTP connection like C# webclient and a server within a server. A webclient sends the request and returns the result by providing sync internally. A server within a server sounds closer to AC's description. If that is the case, perhaps a third party solution for.NET would be better.
write one! anyone can go download JavaCC or any of the free compiler compilers out there to generate a macro language and distribute it freely. Quit your yapping and just do it already. My biased feeling is, prove it is worth including first and then show it's value with real-world examples. Look at the new expression language support in JSP2.0 spec. It came out of the need for an easy way to write simple dynamic pages. People can bitch all you want about how bad the JCP is, but Sun has generally been fair about adding specs and standards when there's a clear demand from the community.
Things that appear to be on the fringe, Sun ignores it. Is that bad? Ask yourself this "do I have time to follow every thought and request of my customers every minute?" The answer is probably going to be "no, I have limited time and resources."
Only thing whiners achieve is noise. Do something about it and become part of the JCP, write a reference implementation and get other developers to support it. What's so hard to understand about the process? It's call process because it takes time and effort, otherwise it would be called "java magic lamp" and anyone could just make a wish.
The parent post makes some good points, but other posts are seem to mis important differences. The windows system has a heavy client using COM+. The ibm system used BEA Tuxedo, which is server based queue. Using COM+ does not provide queue failover or replication. Using BEA Tuxedo on the other hand does provide clustering and fail over. Finding the right solution is what matters right, so using one technique over the over should be driven by the requirements. If your system has to handle that kind of load and not provide 100% failover, a COM+ solution is fine.
The question I keep asking myself is this. If your building a system that has to handle that kind of load, what's the likelihood 100% failover isn't a hard requirement? Obviously there are ways to make the system more manageable by sending high priority orders through a system that has real failover and send all low priority orders through one that isn't. Even with small trading systems, 100% is a hard requirement that is non-negotiable. Here's an excertp from HP's full disclosure.
The queuing mechanism used to defer the execution of the Delivery transaction must be disclosed.
The application creates a semaphore-based thread pool consisting of a user-specified number of threads, which open ODBC connections on the database. When a delivery transaction is posted, one of these threads makes the database call while the transactionâ(TM)s original thread returns control to the user. Upon completion, the delivery
thread writes an entry in the delivery log and returns to the thread pool.
For those who don't read the full disclosure, the IBM system had an average response time of 120ms. The HP system running SQL Server averaged 320ms. That's more than twice as slow. All of that is fine if your requirements say it's ok right. Another important difference is the HP setup used 2GB routers, whereas the IBM system used 100MB routers. If you replace the routers in the HP setup with 100MB, it would probably would loose to the IBM setup.
the guys leaving hi-jacked the source code. Oh wait, JBoss is open source, therefore absolutely no measurable damage to the quality or stability of the product. If anything, it means they have to work harder to prove themselves, which means they have to continue to actively contribute to JBoss, because forking JBoss and giving it a new name makes it harder for them. But in order to build a solid reputation, they have to shine within the JBoss developer community and work well with the others. The message on their home page was politically safe and doesn't criticize Jboss or the developers.
constitute a positive affirmation they currently do not hold the copyright or patent rights. That being the case, the suit should be thrown out, until such time that SCO obtains the rights. That would be like me suing some one for stealing a strangers car, when my brother is saying "I gave the car to the guy."
Slashdot Mirror
Having used BeOS for a little while. I would say definitely better. Superior might be too grand of a statement. The file system was rock solid and is exactly what MS has been trying to build for the last three years with longhorn. The graphics looked much better and had fewer color calibration issues. for example, the colors you see on the screen are much closer to what prints out. windows still has these problems, unless you go buy expensive calibration software/hardware. The SMP support was pervasive, meaning all application benefit from multiple CPU's without having a programmer go in and change the code. The pre-emptive multi-threading/tasking is much better than the current pre-emptive threading in windows 2K and XP. Give you an example, I could copy a huge 300Mb movie to the disk from a CD and still play a 200Mb movie from the hard drive. Try that with windows 2K or XP and tell me how well it handles that. Better than windows definitely.
problem with .NET is Microsoft is still encouraging bad development habits. I can tell you first hand from reading ASP.NET code written in VB that it is horrendous. Most of the examples included with .NET do not use good OO practices for the C# examples. The worst part is it encourages the same lazy hard to read coding practices. Without fixing that, it won't make .NET any cheaper, it's just another trick to milk more money from customers.
the parent post did say a "slapped on top" or wrapped around DCOM/COM. A wrapper could/should hide any ugliness underneath to put it another way.
say you have a farm of servers. If microsoft forces updates to all systems, it could potentially break the servers, since it's happened in the past. On a typical home users system it's fine, but corporate server should not get automatic updates. The system administrators and developers should go through regression testing on select boxes before a complex wide patch is applied.
is it fast enough to write a letter and surf the web? Will it mean fewer sales in China and the other Asian countries? Yup. Will it hurt AMD or Intel? Don't know, but I'm sure we'll all find out with time.
What are you talking about. when i used to work in the campus computer lab, we had 4-6 crashes a day on 50% of the systems with windows 3.1/3.11. With windows 95, that number dropped down to about 2-3 a day. The macs on the other crashed once a week or so with OS8. luckily both MacOSX and window 2K have gotten much better, but not perfect. perfect doesn't exist.
Geeks may hate to admit it, but the majority of the managers hate programmers and despise the IT staff. It's very hard to find high level managers that really understand this fact. That's all fine, since they weed themselves out eventually. The more things change, the more it stays the same. There will always be someone ready to replace a failing company that is blinded by statistics and forget the value of the employee. Everything moves in cycles.
even though this article from msdn is old, it might help answer some questions.
I would disagree with this. What if you want to build an event driven architecture and want the ability to send out event messages with triggers, because the size of your database is terabytes. Here is a hypothetical situation.
Now obviously, you could do this with your data abstraction layer like jdbc/ejb/ado.NET or what ever you use. But what happens if you need some pretty sophisticated filtering, which is dynamic? What is the better option and which will scale better? That's a hard question to answer, since it is specific to the problem you want to solve.
I've run benchmarks, in situations where the entire document is needed and used DOM can be better (depends on use case). Of course if you don't need DOM, then don't use it. The challenge from my perspective is this. If you have a consumer which uses objects and your webservice has to reason over that same object model, you'll probably have to use schema to convert the SOAP message to a C# objects. Once that is a requirement, you're choices are limited. To correctly create an object, you would have to traverse the entire message, instantiate the necessary objects and call the proper method. XmlTextReader is very efficient right, but a process like schema conversion is heavy weight. One option is to use .NET remoting, if the consumer is a VB client or some other .NET client. Read the article by Sosnoski about different parse techniques. He explains it much better than I can.
XmlTextReader is a pull parser right. Therefore it still wouldn't help in situations where the entire message is used by the application. Assuming of course the sender is not including un-necessary data in the message. I believe in those cases, XmlTextReader at best will be equal to DOM. Of course using a different method like .NET Remoting may be an option, if performance is really required and webservices is non-negotiable.
I'd have to agree with people's assertion that performance intensive apps should use a custom protocol and preferably binary based or some kind of delayed stream parser that only accesses the XML node when the app calls for it. I believe Sun has an API in the works for XML stream parsing JSR 317. It's too bad the jsr is still in public review phase. I've written custom parser in the past using SAX and it can definitely improve performance if you convert it to an object model. The question is trade off between being generalized and performance.
In the case of a webservice that uses schema, it's going to be hard to get around the performance issue. An obvious solution in situations where XML is required is to send as little as possible and only get the nodes you need. In that respect XPP2 and XmlTextReader help, until you need the entire document and you use the whole document.
I fail to see how it is way superior. Different yes, but superior reveals your bias. You can extend the Control class right, but AC is right if API meant interface. My personal preference would be to have a base interface, which Control implements. This way I can use some other custom underlying widget, rather than the default look. And, lets remember that cold fusion probably is the first one to use tag-like syntax for server side controls. cold fusion had a terrible time scaling for heavy loads, but it was the first commercial product that integrated a webserver with tags.
video editing for 3D and animation classes. But now Final Cut Pro is the default standard for film schools and most animation courses. The thing is, Adode has seriously lagged the last couple of releases with Premiere. Adobe had a lead for a long time and simply let the advantage go. Nothing remains constant and innovation requires a sense of pressure and urgency. It looks like Adobe didn't have a sense of urgency until it was too late.
The report hardley takes down OSS or Apache. The report is reasonable and doesn't over extrapolate about quality. For me, the report is encouraging because MS has something like 80 programmers working on IIS and apache is made up of volunteers with far fewer resources, that is pretty darn impressive for alpha code. I haven't looked at the list of active committers lately, but I know it's no where near 80. Draw your own conclusions.
open a black hole and have the plane fly into some other dimension. oh wait, that's only in movies and on TV. what were they smoking when they thought up this dumb idea.
How damn fast does your CPU have to be for the computer to be usable? How many people are so damn impatient that they can't wait walk away from their CD ripping and have dinner while it writes the MP3.
Ok, sounds like you bought the whole PR pitch hook line and sinker. I can say from first hand experience C# is not all it's advertised to be. C# has some nice stuff like properties, but several important pieces are seriously hobbled for enterprise class server applications.
There was an article recently on MSDN that talked about async request handling in IIS 6.0, which is supposed to use .NET thread pool instead of the I/O thread pool like IIS 4 and 5. I could be wrong and mis-quoting the facts from the article. The author of the article did use a custom thread pool library to improve async request handling, so there are limitations of the standard thread pool class.
that's actually not uncommon. I'm sure plenty of people have written multi-threaded listeners for simple HTTP server and messaging systems. The hard task is making it handle 2-4K connections/requests per second :) . Having said that, getting any kind of server/NT service to perform at that level is hard. The hardest issues with scalability that I've come across are the result of processes that absolutely had to be sync-ed. Most things you can cheat with async handling, but there are some things like transactional integrity that absolutely need sync access. Of course, most things don't actually need 100% transactional integrity. AFAIK, only hardcore real-time trading systems require that level of synchronization using event driven architecture. trying to scale distributed transaction without a semi-intelligent event system is pretty darn difficult. Many trading systems that claim real-time processing actually have quite a bit of lag (ie, minutes or post-trade-processing) and aren't real-time in the strict technical sense. I've yet to find actual applications written in C# for .NET that comes close to sub-second real-time processing. That doesn't mean there isn't. Just that I'm not aware of them.
Not sure what AC was referring to, but sounds like it is the equivalent to a NT Service, which would qualify the process as a heavy weight thread. Most of the threading examples given in .NET threading books, MSDN and Technet are client centric, which are not daemons. An example to compare contrast might be a multi-threaded HTTP connection like C# webclient and a server within a server. A webclient sends the request and returns the result by providing sync internally. A server within a server sounds closer to AC's description. If that is the case, perhaps a third party solution for .NET would be better.
Things that appear to be on the fringe, Sun ignores it. Is that bad? Ask yourself this "do I have time to follow every thought and request of my customers every minute?" The answer is probably going to be "no, I have limited time and resources."
Only thing whiners achieve is noise. Do something about it and become part of the JCP, write a reference implementation and get other developers to support it. What's so hard to understand about the process? It's call process because it takes time and effort, otherwise it would be called "java magic lamp" and anyone could just make a wish.
The question I keep asking myself is this. If your building a system that has to handle that kind of load, what's the likelihood 100% failover isn't a hard requirement? Obviously there are ways to make the system more manageable by sending high priority orders through a system that has real failover and send all low priority orders through one that isn't. Even with small trading systems, 100% is a hard requirement that is non-negotiable. Here's an excertp from HP's full disclosure.
The queuing mechanism used to defer the execution of the Delivery transaction must be disclosed.
The application creates a semaphore-based thread pool consisting of a user-specified number of threads, which open ODBC connections on the database. When a delivery transaction is posted, one of these threads makes the database call while the transactionâ(TM)s original thread returns control to the user. Upon completion, the delivery thread writes an entry in the delivery log and returns to the thread pool.
For those who don't read the full disclosure, the IBM system had an average response time of 120ms. The HP system running SQL Server averaged 320ms. That's more than twice as slow. All of that is fine if your requirements say it's ok right. Another important difference is the HP setup used 2GB routers, whereas the IBM system used 100MB routers. If you replace the routers in the HP setup with 100MB, it would probably would loose to the IBM setup.
nothing to see here. move on.
Or am I reading that wrong?