Hasn't anyone noticed their Terms of Use, where they say:
If you submit material to A9.com, and unless we indicate otherwise, you grant A9.com and its affiliates a nonexclusive, royalty-free, perpetual, irrevocable, and fully sublicensable right to use, reproduce, modify, adapt, publish, translate, create derivative works from, distribute, and display such content throughout the world in any media. You grant A9.com and its affiliates and sublicensees the right to use the name that you submit in connection with such content, if they choose.
You certainly won't catch me submitting anything to them (once the option is presumably available)
The worst website server-side-scripting language ever invented. It reads like it was designed by a drunken incompetent programmer on a boring weekend. Every WebHub function looks something like this: %=G|thisText|thatText|%=D|blah=%=% That's a _simple_ example. If you put whitespace in the wrong place, it probably won't work. It requires delphi modules to do nearly anything (including basic arithmetic). Oh, and pages aren't related to files. The files all have to be.html, but each file can contain multiple pages, each of which starts with something like: <h1>-Pagename,,,,title-</h1>
Nothing so interesting - I was reading a document on an algorithm that allows you to order the text such that it can be restored to it's original order - however, having it more sorted increases compression ratios dramatically. It occurred to me "hey, you could to this by hand", and it got me thinking on secure encryption by hand...
> 1.) Java lacks "real" socket classes. Java's threading classes stink, compared to CLR as well.
True that Java doesn't support the lowest level of sockets, but that's because it has to be platform independant.
What stinks about Java's threading?
>3.) Java doesn't let you pass things by reference.
All objects are passed by reference. Primitives are passed by value, but that is easily remedied by assigning it to a local primitive and working with that.
>5.) Java is not truly object oriented... ie primitives are not objects and niether are literals. In CLR, everything is an object. Even primitives and literals.
'True' OO as you refer to it is overrated. Forcing everything to be an object simply adds extra, unneeded overhead. Besides, if you really want to, you could do everything with Java's object wrappers for primitives.
>10.) I really hate how you have to declare that your methods throws something, and be forced at compile time to catch them. Any developer worth their beans will already be aware of exceptions and how to deal with them. When you force developers to catch everything, too many people get lazy and catch an exception, just to throw it away, which is truly heinous. And CLR's System.Diagnostic classes are very nice;)
That's up to you, but IMHO it's a point in Java's favor - the gentleman said he wanted good error handling. The way Java deals with it, you should be aware of any and all errors that you will need to handle.
The worst website server-side-scripting language ever invented. It reads like it was designed by a drunken incompetent programmer on a boring weekend. Every WebHub function looks something like this: .html, but each file can contain multiple pages, each of which starts with something like:
%=G|thisText|thatText|%=D|blah=%=%
That's a _simple_ example. If you put whitespace in the wrong place, it probably won't work. It requires delphi modules to do nearly anything (including basic arithmetic). Oh, and pages aren't related to files. The files all have to be
<h1>-Pagename,,,,title-</h1>
And it only gets worse from there...
Nothing so interesting - I was reading a document on an algorithm that allows you to order the text such that it can be restored to it's original order - however, having it more sorted increases compression ratios dramatically. It occurred to me "hey, you could to this by hand", and it got me thinking on secure encryption by hand...
Ugh. My apologies to all reading the parent message for my lack of consideration in not hitting [Preview] first!
> 1.) Java lacks "real" socket classes. Java's threading classes stink, compared to CLR as well. True that Java doesn't support the lowest level of sockets, but that's because it has to be platform independant. What stinks about Java's threading? >3.) Java doesn't let you pass things by reference. All objects are passed by reference. Primitives are passed by value, but that is easily remedied by assigning it to a local primitive and working with that. >5.) Java is not truly object oriented... ie primitives are not objects and niether are literals. In CLR, everything is an object. Even primitives and literals. 'True' OO as you refer to it is overrated. Forcing everything to be an object simply adds extra, unneeded overhead. Besides, if you really want to, you could do everything with Java's object wrappers for primitives. >10.) I really hate how you have to declare that your methods throws something, and be forced at compile time to catch them. Any developer worth their beans will already be aware of exceptions and how to deal with them. When you force developers to catch everything, too many people get lazy and catch an exception, just to throw it away, which is truly heinous. And CLR's System.Diagnostic classes are very nice ;)
That's up to you, but IMHO it's a point in Java's favor - the gentleman said he wanted good error handling. The way Java deals with it, you should be aware of any and all errors that you will need to handle.