Patent?
Similar technology is present in 50% of todays telephony (e.g. POTS, GSM, WCDMA) servers.
PLEX & emergency corrections in executive side have enabled this since around the late 1980:ies.
http://en.wikipedia.org/wiki/AXE_telephone_exchange
Yes, AXE nodes *usually* is patched by updating the hot-standby side while separated from executive side - but if you really want to live on the wild side...;-)
"Yeah, and because there are no successful office suits written in java that means java are slower than C/C++?" "So, can you show me any office suits written in assembly or machine code that are used successfully on todays computers, or do you mean that micro code is slower than C/C++?" "Have you stopped beating your wife?" Notice the similarity in the questions above?:)
MUUUUU! (logic error)
And yes, I still claim java not to be slower by a *wide margin* than C on most stuff that are programmed in an object oriented notion (micro-benchmarks/1000line wonder + virtual machine = all bets are off...) - the bigger and more object oriented code, the better java performs (or any virtual machine based platform which can dynamically optimize hot spots) whereas C/C++ is just the opposite:)
This is also one of the reason java is used a lot on the server side - that's where performance, ease of use, maintainability and scalability is really important.
Notice that I'm not saying that java is generally faster. Just that it's not generally slower by a *wide margin* which is a BIG difference.
(i.e. if you do a straight port of a procedural architected C program to java you can have a laugh at "how sloooow java is" - but then I would call any person doing that stupid in the first place, "use what works", if C/C++ is ok - then why not use it:)
But I have seen more than one article by a Java advocate making the strange claim that Java is faster than C.
Well, maybe because it's a valid claim: in almost every case I've seen of fft implementations in java and c - java is faster (since 1.3.1). Thus, if you're only interested in that case java is actaully faster;)
yes, in the majority of cases c is faster - but not by a very wide margin (depending on the actual case of course) and then you have the occasional situation where the java vm is faster.
No difference - the vm just cares about bytecode, what language the code came from doesn't really matter (except that maybe not all of the JIT optimizations developed for the java language might work as good on bytecodes from other languages... Which is the same problem the CLR have with getting, for example, python performing good enough - java implementation of python is easier because of java haven't got.net's inherent problem with *unloading* bytecode)
I.e. in theory the java vm knows nothing about java the language (as above, in practise some optimizations in the vm jitter of course know common patterns of bytecode that represents common java code patterns - casts,for loops, etc).
Well, just guessing here, maybe because the majority of java developers aren't even aware that it exists and if they are believe that it's not needed:)
"Innovative"-right... languages for the java vm:
on
Essential .NET, Volume I
·
· Score: 2, Informative
Everything you write in Java has to be written in Java. I know there are Java purists out there who may think that rocks, but it could be beneficial to be able to pick and choose languages for the task at hand. The multi-language innovation is really neat to me. Some languages make string processing a snap, some don't.
Sorry to bring you the news, but you really should get out more:)
And how exactly did Java(tm) address versioning?
Well,
http://java.sun.com/j2se/1.4.2/docs/guide/versioni ng/spec/versioningTOC.html
Package based versioning - biggest problem is that most open-source (I don't really care about other commercial projects as I don't use them;) projects don't use this:(
One big problem is getting it to work on the existing JSP architecture, though, as JSP still has no server-side component model.
The above make no sense to me?
1, java server faces are orthogonal to jsps...
2, "still has no server-side component model" Not that I understand what you're talking about here - sure looks like jsps have been doing great without "no server-side component model"? Are you talking about servlets, javabean models implementing state or what (javascript runat server maybe...)?:)
IMHO the biggest problem with.net webforms compared to say java server faces or tapestry (use google if you need information on any of those - java got good documentation;) is the inherent problem with the way webforms are developed.
You can't (well, not without serious trouble - you can't use those nifty "wizards" of VS.NET - there you lost the "productivity" buzzword) easily use the common model 2 web development paradigm.
The problem is that in webforms you're supposed to be using a "page" with code-behing technology as entrance (thus coupling the view with the controller). Put another way: the code-behind belongs to the page - Controller belongs to the View != MVC where each are seperate (making large projects harder to develop and maintain due to those hard bindings).
I.e. there is no similarity to as in java where you have a front servlet (a.k.a. Controllor) and a java bean (Model) and a jsp/html page (View) with no hard bindings (you can, if you want, specify th bindings in the web.xml file for the controller servlet). There are a lot of MVC architectures available for J2EE developers. So far I've only heard of one for.net and that's a port of Struts.
And yes, Sun's jvm have been doing that since (pre?) 1.4.
You know, it's a lot of money involved in all those high-end application servers that runs with 99.9999+ % uptime - the same money that sun get's a share of from j2ee licensing fees. A large part of that money is applied on making java faster on the server (take care of the hand that's feeding you approach). Which probably also is the reason that java -server usually does a better job at optimizing code than client (even though server takes more memory and longer start-up times.)
Basic explanation of adapting jitting is that it's compiling code to native form and later realizing that some branches are never touched/new constraints are found/etc - tadá, recompile and see if it works better/correctly - if not. tadá..., you get the picture:)
Some imp. stuff that I believe is missing, or?
on
Qt On DirectFB
·
· Score: 1
I guess some obvious things coming from a windows gaming/game developer person (ok, "stone him";) are:
1, ability to go into "true fullscreen" - not just a window covering all of the screen. "Stop the rest of the world" approach (ya, if you're using your linux system as some kind of server in the background this is nothing for you - but I said I was interested in gaming;)
2, related to 1 - ability to change bpp and "screen size" dynamically, without requiring a restart of the X server.
Are any of this available or not? To my knowledge no, will it be available soon(tm)?
I guess the above two points should be taken care of a.s.a.p - then linux will truly be a better gaming platform than windows (imagine games written in java/"other platform indenpendent code" + opengl + openal running better on linux than the same game on windows! This could become a reality real soon with the new preemptible 2.5-6 kernel and some X server improvements:)
Probably, better question is how much do you need?
on
Can .NET Really Scale?
·
· Score: 3, Insightful
1, Buy *a lot* of memory for the box 2, Cache as much as you can of the dynamic content 3, try to stay away from bloated protocols
1: Java,.NET is the same but different - they both require a hefty amount of ram to operate at best performance (and atleast java just gets better the more memory that is available on the server;)
2: Maybe doesn't help much with scalability, performance will go up though - and maybe you might get good enough scalability too. Database access is always slower than a hashmap lookup (if said hashmap can stay in ram ofcourse)
3: Web-services etc etc are maybe good in theory but at the moment those technologies are a duck in a pond when it comes to scalability and performance. Use a highperformance.net remoting implementation instead - you can probably find a few with a quick google search (IIOP comes to mind, good way to make future interfacing with other technologies available just a easy as with webservices/soap and gaining better performance in the bargain).
Also investigate how much you can make your site use asynchronous notifications, more is better - even if ms messaging client is too bad, you can write your own asynchronous "protocol".
The problem with java and any other non-static linking language is that you *can't* "link" (in the *static* way that lgpl require?) with a lgpl library due to java's dynamic binding *sigh*
Please explain this to me and every other java developer that now, for instance, can't use jboss as a application server. This by the "new" definition of lgpl that seems to imply that all applications deployed on jboss also become "infected" (in lack of a better word, english isn't my native language... sorry).
If they indeed are writing an emulation layer for the upcomming playstation 3 - the step to providing support for virtual machine based platforms becomes a lot easier...
I guess some companies are quite happy with this (as they have bet a lot on this virtual machine architecture), and one company which probably won't get their virtual machine platform supported (but that company got their own gaming console anyway;).
Before/At this years JavaOne Sun created a Java Gaming Group aiming at making java the best language/platform for writing (including AAA style) games. Doing this will be by supporting the old java3d (win32 and linux scenegraph + opengl/direct3d functionality) and java2d (all java platforms, most hardware accelerated on win32 atm though). And, here comes the big news, by the release of the open source java opengl api - a java binding to opengl which is as fast as any c native binding thanks to the use of java nio buffers (read: native read/write memory access, the difference between java and c bindings should be unnoticable in any game). IMHO This news with java's superior networking api's will make java the nr 1 language/platform to write the next generation of game titles on.
Also, maybe look for news concerning java and playstation in the next year or so (this is just a rumour that's been going for a couple of months/year at www.javagaming.org/cgi-bin/JGNetForums/YaBB.cgi)...
So my advise to you is to cover the basics of how to write efficient, first class, high performance games with java.
Suggested api's to cover (all or subsets/overview): games-core.dev.java.net (sun sponsored java gaming community site) JoGL: 3d hardware accelerated graphics (opengl) JoAL: 3d sound - EAX and others (openal) JInput: high performance input framework - pullable keyboard/mouse, force-feedback gamepads, joysticks etc etc.
and also (the thing that got all above started, by making people understand java can be used to write great games): LWJGL (a package of opengl, openal, high performance vector math package, jxinput into one small library ~ 500kb) Another, different, version of the above, with the only exception that earlier mentioned JoGL is a more "broad" approach to 3d - whereas LWJGL is *only* targeted at gaming.
Related links: http://community.java.net/games/ http://w ww.lwjgl.org pre-release 0.7 available now! http://www.puppygames.net
The other feature that.Net has is superior native execution, it was designed to be translated to native code. The.net virtual machine is better defined than the JVM is. But I agree that on whole, the tradeoff is not worthwhile.
Mod parent up as overrated...
The java virtual machine was designed to be *both* interpreted and just in time (JIT) compiled to native form as this is the best performer.
You maybe don't believe it - but most of the time methods only used one or two times during an applications life time they are actuallay faster *not* to compile to native form (insert long CS hardware and virtual machine explanation and proof here).
The.NET CLI have the problem that it was *not* designed to be efficiently interpreted - thus any dynamic language will perform very bad on it (i.e. compare benchmarks of python.net python on java (jython))
There's C#, VB.Net and an architecture that has allow Python.net, Perl.net, Fortran.net, Cobol.net and others. The multitude of languages comes into its own when you realise that objects written in one language are easily used in every other language, so you can have 1 developer using Perl, another using C#. Try that in Java. Try any cross language development in Java.
Yes, I usually use java and python (www.jython.org) - both which run excellent on the java platform.
The.NET languages have some problems though - the only one actually working as it should is C#...
Cross platform languages is a red herring (even more so than cross platform virtual machines) as the important part is the API's! What good is python.net to python programmers if they can't use their own api's?
Microsoft did not include rmi (remote method invocation framework), instead they used a, incompatible , framework based on com(+)
Microsoft did not include jni (native code access), instead they choose a, windows only, framework
And, what they mostly lost the case on, they changed and included stuff under the java. namespace.
Other companies, well apple, have included their, incompatible, stuff under com.apple namespace - no problem (and, of course, sun has their incompatible stuff under com.sun and ibm... etc etc)!
Microsoft had their own namespace (strangly enough com.ms, you would have thought they would use com.microsoft? well whatever) but instead choose to deliberatly make java bound to windows by making microsoft java developed programs (those that used microsofts "extended" java. namespace classes - many of them - unclear which at a casual glimpse at the api...) incompatible with original java.
Just note that tomcat is NOT a *complete* j2ee server (i.e. it's "just" a webserver - more or less).
Then whether you actually need a complete j2ee server is a different matter.
C# is a *super-set* of Java, meaning it has more features.
C# versus Jave (the language)
more features != better language (IMHO it's actually the opposite - less features => better language, yes I like Smalltalk and Common Lisp;)
.NET versus Java (the platform)
If you count available third party libraries and tools you probably see his point...
Also, C# is far more standardised than Java will ever be, even though pundits have attempted to get a proper Java specification in the works lots of times.
This is clearly just marketing bullsh*t, who *beep* cares if the "syntax" is standardised - do you even now what that means? The important api's are NOT standardised in.NET in any way whatsoever.
Java atleast got standardised *API's* by www.jcp.org (it's a STANDARD).
It's just that C# exceeds the performance and functionality of Java in most cases,
And you know this how? Have you actually tried a.NET application - perhaps something involving a GUI (hint: GDI is not a great performer in.NET... check your favourite Newsgroup for sources on that:)
now on the Win32 platform, and other implementations are rapidly catching up - mainly due to Microsoft's surprisingly open standards.
C# gives you far more control over the dynamic reloading of classes, as well as increased security through what.NET calls 'AppDomains'. This is a very powerful feature.
Mod parent up as troll or atleast overrated *sigh*
related links:
(let me give you a small tip:
The performance of the C# version (regex example) is related to.NET's "far more control over reloading of classes" - maybe you should check your facts about reloading classes - pay extra attention to sections labeled "unloading" if you can find any... - in the java vm and.NET spec.;)
PS: Don't take that article too seriously, it was just thrown together to humiliate a MS clown known as Rolf Trollerud - just gotta love that name, shift some characters around;) - residing in theserverside.com
A couple of years ago a friend and I wrote a simple RTS engine in C++.
It was a tile based 2D game. Now, we weren't experts at writing super speedy display code, but we did preload all the images into memory, double buffer the frames, and crop areas of the map which would not be shown before displaying them.
It got a whopping 8 frames a second. With 1 moving unit on the screen. Needless to say we quickly abandoned the project.
Machines have gotten faster. The C++ compilers is undoubtedly slightly improved. My guess is its still got a long way to go.
I don't get it:
"The whole goal of this book was to explain how to do things the right way.".
By this you mean that mod_perl (OUCH!!!)/cgi (OUCH!!!)/persistent database connections (OUCH!!!) are "doing things the right way"?
Well, if you're implying that then I agree that the title of the book is way off - it should be "developing web pages for dummies" instead.
# Scalability
cgi - no way
perl - probaly not, prove me wrong
persistent database connections - hmm, a though one - depends entirely on implementation and judging from how deply this subject is covered I would definetely say NO WAY!
# Caching
Very important to cache correctly if you want scalability and/or performance
+ cluster wide cache (very hard stuff for beginners)
http://www.tangosol.com/ / http://www.jboss.org -> cluster etc
# Database Independent Libraries
yep, very good to have!
# Connection Pooling
this should probably be handled by an application server anyway
jboss, orion etc (or the 20 or so other java app. servers)
zope - python?
# Code/HTML Separation: Templates
YES!!! no code in your view (remember MVC?)
# Web security techniques
# User Authentication methodologies
well...
# Sessions and cookies
Sessions: yes
cookies: well, if you *just* (e.g. no major persistence of state) need cookies it's probably a bad idea anyway...
Sure, the book is probably ok if it's intended for a the niché of common visual basic asp/php hackers (mind you, I know there exists qualty php code out there too - even though all these bulletinboards is suggesting "hacking")
but trying to justify that it also cover the previous mentioned areas is just plain shortsighted!
Slashdot Mirror
Patent? Similar technology is present in 50% of todays telephony (e.g. POTS, GSM, WCDMA) servers. PLEX & emergency corrections in executive side have enabled this since around the late 1980:ies. http://en.wikipedia.org/wiki/AXE_telephone_exchange Yes, AXE nodes *usually* is patched by updating the hot-standby side while separated from executive side - but if you really want to live on the wild side... ;-)
Java 2D (the graphics backend, also used by swing) has been hardware accelerated on windows since ~1.4 by use of directx.
Now it seems that java 1.5 will use opengl on linux to achieve the same (or even better...;) graphics performance as seen on windows.
i.e.: http://www.javagaming.org/cgi-bin/JGNetForums/YaBB .cgi?action=display;board=jogl;num=1060784520;star t=0#6
"Yeah, and because there are no successful office suits written in java that means java are slower than C/C++?" :)
:)
:)
"So, can you show me any office suits written in assembly or machine code that are used successfully on todays computers, or do you mean that micro code is slower than C/C++?"
"Have you stopped beating your wife?"
Notice the similarity in the questions above?
MUUUUU! (logic error)
And yes, I still claim java not to be slower by a *wide margin* than C on most stuff that are programmed in an object oriented notion (micro-benchmarks/1000line wonder + virtual machine = all bets are off...) - the bigger and more object oriented code, the better java performs (or any virtual machine based platform which can dynamically optimize hot spots) whereas C/C++ is just the opposite
This is also one of the reason java is used a lot on the server side - that's where performance, ease of use, maintainability and scalability is really important.
Notice that I'm not saying that java is generally faster. Just that it's not generally slower by a *wide margin* which is a BIG difference.
(i.e. if you do a straight port of a procedural architected C program to java you can have a laugh at "how sloooow java is" - but then I would call any person doing that stupid in the first place, "use what works", if C/C++ is ok - then why not use it
But I have seen more than one article by a Java advocate making the strange claim that Java is faster than C. Well, maybe because it's a valid claim: in almost every case I've seen of fft implementations in java and c - java is faster (since 1.3.1). Thus, if you're only interested in that case java is actaully faster ;)
yes, in the majority of cases c is faster - but not by a very wide margin (depending on the actual case of course) and then you have the occasional situation where the java vm is faster.
No difference - the vm just cares about bytecode, what language the code came from doesn't really matter (except that maybe not all of the JIT optimizations developed for the java language might work as good on bytecodes from other languages... Which is the same problem the CLR have with getting, for example, python performing good enough - java implementation of python is easier because of java haven't got .net's inherent problem with *unloading* bytecode)
I.e. in theory the java vm knows nothing about java the language (as above, in practise some optimizations in the vm jitter of course know common patterns of bytecode that represents common java code patterns - casts,for loops, etc).
Well, just guessing here, maybe because the majority of java developers aren't even aware that it exists and if they are believe that it's not needed :)
Sorry to bring you the news, but you really should get out more
http://grunge.cs.tu-berlin.de/~tolk/vmlanguages.h
Among the most interesting of those you find
- jython (python running on the java vm - the fastest python implementation?)
- eiffel
- smalltalk
- nice (indeed a very nice
;) language - a little bloated syntax though)
- sather
- ada
- ruby
- javascript (rhino)
- aspectj (first AOP language)
- forth
- fortran and last but not least a very promising language called
- Kava
http://www.research.ibm.com/people/d/dfb/papers.h
t ml#Bacon01Kava
So, again, your point aboutAnd how exactly did Java(tm) address versioning? Well, http://java.sun.com/j2se/1.4.2/docs/guide/versioni ng/spec/versioningTOC.html
Package based versioning - biggest problem is that most open-source (I don't really care about other commercial projects as I don't use them ;) projects don't use this :(
One big problem is getting it to work on the existing JSP architecture, though, as JSP still has no server-side component model. :)
The above make no sense to me?
1, java server faces are orthogonal to jsps...
2, "still has no server-side component model" Not that I understand what you're talking about here - sure looks like jsps have been doing great without "no server-side component model"? Are you talking about servlets, javabean models implementing state or what (javascript runat server maybe...)?
IMHO the biggest problem with .net webforms compared to say java server faces or tapestry (use google if you need information on any of those - java got good documentation ;) is the inherent problem with the way webforms are developed.
.net and that's a port of Struts.
You can't (well, not without serious trouble - you can't use those nifty "wizards" of VS.NET - there you lost the "productivity" buzzword) easily use the common model 2 web development paradigm.
The problem is that in webforms you're supposed to be using a "page" with code-behing technology as entrance (thus coupling the view with the controller). Put another way: the code-behind belongs to the page - Controller belongs to the View != MVC where each are seperate (making large projects harder to develop and maintain due to those hard bindings).
I.e. there is no similarity to as in java where you have a front servlet (a.k.a. Controllor) and a java bean (Model) and a jsp/html page (View) with no hard bindings (you can, if you want, specify th bindings in the web.xml file for the controller servlet). There are a lot of MVC architectures available for J2EE developers. So far I've only heard of one for
And yes, Sun's jvm have been doing that since (pre?) 1.4. You know, it's a lot of money involved in all those high-end application servers that runs with 99.9999+ % uptime - the same money that sun get's a share of from j2ee licensing fees. A large part of that money is applied on making java faster on the server (take care of the hand that's feeding you approach). Which probably also is the reason that java -server usually does a better job at optimizing code than client (even though server takes more memory and longer start-up times.) Basic explanation of adapting jitting is that it's compiling code to native form and later realizing that some branches are never touched/new constraints are found/etc - tadá, recompile and see if it works better/correctly - if not. tadá..., you get the picture :)
I guess some obvious things coming from a windows gaming/game developer person (ok, "stone him" ;) are:
;)
:)
1, ability to go into "true fullscreen" - not just a window covering all of the screen. "Stop the rest of the world" approach (ya, if you're using your linux system as some kind of server in the background this is nothing for you - but I said I was interested in gaming
2, related to 1 - ability to change bpp and "screen size" dynamically, without requiring a restart of the X server.
Are any of this available or not? To my knowledge no, will it be available soon(tm)?
I guess the above two points should be taken care of a.s.a.p - then linux will truly be a better gaming platform than windows (imagine games written in java/"other platform indenpendent code" + opengl + openal running better on linux than the same game on windows! This could become a reality real soon with the new preemptible 2.5-6 kernel and some X server improvements
1, Buy *a lot* of memory for the box
.NET is the same but different - they both require a hefty amount of ram to operate at best performance (and atleast java just gets better the more memory that is available on the server ;)
.net remoting implementation instead - you can probably find a few with a quick google search (IIOP comes to mind, good way to make future interfacing with other technologies available just a easy as with webservices/soap and gaining better performance in the bargain).
2, Cache as much as you can of the dynamic content
3, try to stay away from bloated protocols
1: Java,
2: Maybe doesn't help much with scalability, performance will go up though - and maybe you might get good enough scalability too. Database access is always slower than a hashmap lookup (if said hashmap can stay in ram ofcourse)
3: Web-services etc etc are maybe good in theory but at the moment those technologies are a duck in a pond when it comes to scalability and performance. Use a highperformance
Also investigate how much you can make your site use asynchronous notifications, more is better - even if ms messaging client is too bad, you can write your own asynchronous "protocol".
The problem with java and any other non-static linking language is that you *can't* "link" (in the *static* way that lgpl require?) with a lgpl library due to java's dynamic binding *sigh* Please explain this to me and every other java developer that now, for instance, can't use jboss as a application server. This by the "new" definition of lgpl that seems to imply that all applications deployed on jboss also become "infected" (in lack of a better word, english isn't my native language... sorry).
From the "what if?" department:
;).
If they indeed are writing an emulation layer for the upcomming playstation 3 - the step to providing support for virtual machine based platforms becomes a lot easier...
I guess some companies are quite happy with this (as they have bet a lot on this virtual machine architecture), and one company which probably won't get their virtual machine platform supported (but that company got their own gaming console anyway
Before/At this years JavaOne Sun created a Java Gaming Group aiming at making java the best language/platform for writing (including AAA style) games. Doing this will be by supporting the old java3d (win32 and linux scenegraph + opengl/direct3d functionality) and java2d (all java platforms, most hardware accelerated on win32 atm though). And, here comes the big news, by the release of the open source java opengl api - a java binding to opengl which is as fast as any c native binding thanks to the use of java nio buffers (read: native read/write memory access, the difference between java and c bindings should be unnoticable in any game). IMHO This news with java's superior networking api's will make java the nr 1 language/platform to write the next generation of game titles on.
. .
w ww.lwjgl.org pre-release 0.7 available now!
Also, maybe look for news concerning java and playstation in the next year or so (this is just a rumour that's been going for a couple of months/year at www.javagaming.org/cgi-bin/JGNetForums/YaBB.cgi).
So my advise to you is to cover the basics of how to write efficient, first class, high performance games with java.
Suggested api's to cover (all or subsets/overview):
games-core.dev.java.net (sun sponsored java gaming community site)
JoGL: 3d hardware accelerated graphics (opengl)
JoAL: 3d sound - EAX and others (openal)
JInput: high performance input framework - pullable keyboard/mouse, force-feedback gamepads, joysticks etc etc.
and also (the thing that got all above started, by making people understand java can be used to write great games):
LWJGL (a package of opengl, openal, high performance vector math package, jxinput into one small library ~ 500kb)
Another, different, version of the above, with the only exception that earlier mentioned JoGL is a more "broad" approach to 3d - whereas LWJGL is *only* targeted at gaming.
Related links:
http://community.java.net/games/
http://
http://www.puppygames.net
instead they used a, incompatible , framework based on com(+)
Other companies, well apple, have included their, incompatible, stuff under com.apple namespace - no problem (and, of course, sun has their incompatible stuff under com.sun and ibm... etc etc)!
Microsoft had their own namespace (strangly enough com.ms, you would have thought they would use com.microsoft? well whatever) but instead choose to deliberatly make java bound to windows by making microsoft java developed programs (those that used microsofts "extended" java. namespace classes - many of them - unclear which at a casual glimpse at the api...) incompatible with original java.
Just note that tomcat is NOT a *complete* j2ee server (i.e. it's "just" a webserver - more or less). Then whether you actually need a complete j2ee server is a different matter.
C# versus Jave (the language)
;)
more features != better language (IMHO it's actually the opposite - less features => better language, yes I like Smalltalk and Common Lisp
If you count available third party libraries and tools you probably see his point...
This is clearly just marketing bullsh*t, who *beep* cares if the "syntax" is standardised - do you even now what that means? The important api's are NOT standardised in .NET in any way whatsoever.
Java atleast got standardised *API's* by www.jcp.org (it's a STANDARD).
And you know this how? Have you actually tried a .NET application - perhaps something involving a GUI (hint: GDI is not a great performer in .NET ... check your favourite Newsgroup for sources on that :)
Open Standards: *sigh*
related links:
http://www.freeroller.net/page/ceperez/20030520#p
http://roller.anthonyeden.com/page/ceperez/200212
(let me give you a small tip:
The performance of the C# version (regex example) is related to
PS: Don't take that article too seriously, it was just thrown together to humiliate a MS clown known as Rolf Trollerud - just gotta love that name, shift some characters around
A couple of years ago a friend and I wrote a simple RTS engine in C++.
It was a tile based 2D game. Now, we weren't experts at writing super speedy display code, but we did preload all the images into memory, double buffer the frames, and crop areas of the map which would not be shown before displaying them.
It got a whopping 8 frames a second. With 1 moving unit on the screen. Needless to say we quickly abandoned the project.
Machines have gotten faster. The C++ compilers is undoubtedly slightly improved. My guess is its still got a long way to go.
Dumb*ss
I've tried both - and yes, .NET runtime is slower (not that it really matters as both .NET and java are plenty fast on even my old machine)
I don't get it: "The whole goal of this book was to explain how to do things the right way.".
;)
By this you mean that mod_perl (OUCH!!!)/cgi (OUCH!!!)/persistent database connections (OUCH!!!) are "doing things the right way"?
Well, if you're implying that then I agree that the title of the book is way off - it should be "developing web pages for dummies" instead.
# Scalability
cgi - no way
perl - probaly not, prove me wrong
persistent database connections - hmm, a though one - depends entirely on implementation and judging from how deply this subject is covered I would definetely say NO WAY!
# Caching
Very important to cache correctly if you want scalability and/or performance + cluster wide cache (very hard stuff for beginners)
http://www.tangosol.com/ / http://www.jboss.org -> cluster etc
# Database Independent Libraries
yep, very good to have!
# Connection Pooling
this should probably be handled by an application server anyway jboss, orion etc (or the 20 or so other java app. servers) zope - python?
# Code/HTML Separation: Templates
YES!!! no code in your view (remember MVC?)
# Modular programming & Libraries
YEP, aspected and object oriented components too.
# Web security techniques
# User Authentication methodologies
well...
# Sessions and cookies
Sessions: yes
cookies: well, if you *just* (e.g. no major persistence of state) need cookies it's probably a bad idea anyway...
Sure, the book is probably ok if it's intended for a the niché of common visual basic asp/php hackers (mind you, I know there exists qualty php code out there too - even though all these bulletinboards is suggesting "hacking")
but trying to justify that it also cover the previous mentioned areas is just plain shortsighted!
All of the above is of course IMHO