Java may actually lose ground in this "metric". Since the Java programmers are generally segregating in this recession to more seasoned programmers, fewer and fewer will utilize web resources for anything.
Because with Java - I generally do not need to search the web for the answer. However, take C# for instance, and depending on which OS I'm running on, I may have to run 20 or 30 searches for every single answer, because I thought I might have it - but won't know until I try it whether it works for 2.0, 3.0, 3.5, or 3.51....etc.
There's no such thing as 'better'. Given an specific task or application, one language may be better suited to it than another, but 'better' or 'best' language has no meaning when looking at all possible applications.
I think we can all agree COBOL sucks no matter the application.
If comcast could profit from bit torrent then they will be happy for it because, when done correctly, bit torrent more efficiently broadcasts across the edges of the network rather than the backbone.
The most efficient means of "broadcasting" anything across the internet or any network is to use multicasting. The biggest impediments to multicasting are:
The Microsoft implementation is completely broken, except maybe in the new network stack - haven't tested it yet
Many cheap routers don't support it
Even some older formerly high-end equipment doesn't fully support it
BitTorrent is merely a work-around to this lack of current functionality that has been in the IPv4 spec since the beginning, at least far as "broadcasting" goes. It's other purpose is distributed file sharing which is a different use case with different requirements.
Fortunately IPv6 requires full multi-cast support to be certified. We can only hope to get there sooner than later.
but if you'll actually read copyright law, it's not about downloading or copying it yourself, copyright is all about distribution. Which is the only thing they can really get you for. You can copy anything to your heart's content (with exceptions as per the DMCA) you just can not distribute.
Copyright was horribly misnamed, it should have been named DistributionRight.
Part (7) says countries can maintain their current length as of the signing date (for US 1987) So there's nothing preventing a roll back to the signing date for each respective country.
Part (8) In any case, the term shall be governed by the legislation of the country where protection is claimed; however, unless the legislation of that country otherwise provides, the term shall not exceed the term fixed in the country of origin of the work.
Is interesting as well.
What's also interesting is that the US adopted the UCC Geneva instead of the Berne in 1955 because the various clauses in the Berne Convention, such as the life of the author clause, were in direct contradiction with US law.
On the surface, it does seem that simple and the effects are certainly borne out by practice. However, there's more to it than that, and the source/type of calories does make a difference in how you feel and can have other side effects.
I look around at all the frameworks that have evolved to not do SQL (EJB-QL, Hibernate, etc) and I laugh. None of those languages come close to handling the same breath and width of problems that SQL can be used to solve. Whenever I see advocates of these frameworks all puff up with fervour, I feel like shaking them and say "Your emperor has no clothes!". The list of problems these frameworks can't solve is so huge that one wonders why anyone works with them at all.
Having had hibernate and JDO forced on me on three previous projects, I can fully support your assessment of these "helper" frameworks. They're functional in their extremely small niches, maybe. What I find humorous is that as soon as you deviate from their 1 or 2 tricks, you'll find hundreds or thousands of lines of code with half of it will being bad SQL to mimic what a simple 1 or 2 line well formed SQL query will give you had you not used said framework. (I'll pass this on: small JDO project - 35K lines of vendor specific DB code, very small hibernate project, 10K lines of code, also vendor specific, and finally, a rather sizable project using hibernate, somewhere in the neighborhood of 40+K lines of code and still counting, but this one's special as it's also infected with the Spring framework. I'll know more in a month or so after I've stripped out both as I need real access to the persistence layer to allow for an entire order of magnitude in scalability and functionality)
But I've never seen them [DBA priests] actually get the SQL working to the point that it can supplant the flat files. The parts that do work are always so slow that turning on the "useDB" switch makes it too sluggish to actually use. In some cases, I can get around this by writing "pre-pass" code to extract the common data sets from the DB and write it to flat files, which the interactive software can read through quickly... It's better to just develop stuff that works, and let the DB experts handle the task of porting it to the DB. That way, we developers can keep our hands clean of all the theology, and actually develop stuff that works.
You've just succinctly described why so many see DBs as slow and ponderous. No, it's not because they are, it's because the developer didn't do any DBA design nor understand the first thing about DBs to be able to design a decent architecture. Using flat files for your tasking reduces the DB to a pure full fetch model which flat files will usually be faster at for infrequent (ie, non-cached) requests.
You'd be much better served running your POC against mysql or postgresql than flat files. (depending on what flavor of DB you would be running against and the assumption that your "priests" wouldn't give you a copy of their actual DB to play with) At least this would force you into various considerations of data design and to utilize DB functionality.
This is something that has come on gone several times over the past couple of decades. You should have heard the uproar when drive makers first switched to standard SI descriptors. Honestly, it's about time that OSes did the right thing, either use the correct metric or the correct nomenclature.
I was actually considering an entirely different process that's relatively easy to implement which I've actually already used on other sites for a different purpose.
I know I know don't feed the trolls, especially the slow ones....
You're not making any sense. This is nonsensical. Assign a string to a List? Huh?
Yes, it's quite possible, through reflection. What's worse though in C# is that the incorrect object can then be passed all over the place as the "type" that it's not until you try to use it. How did you sum this up? Oh yeah: "Huh?".
Delegates? Please, just fancy syntactic sugar for the adapter pattern.
Right, the same way a "Class" is just fancy syntactic sugar for a pointer to a structure amirite? Shit, C does everything we need then, I guess. Ridiculous.
delegate->adapter/proxy method is like waffle -> sugar cone. Class-> pointer is like House -> stick.
But I'm sure those are just minor differences to a stellar intellect as yourself.
I'm getting the sneaking suspicion that you don't know what you're talking about, and that in addition you're defining anything not in Java as not being useful or good, which is a bit circular.
Well at least you have a suspicion of something.Too bad its misplaced.
Just because something might look good at first glance as making all those "hard things" go away by just using some pseudo code is really just a short cut that experience has shown will bite you in the ass later sooner or later.
I'm also solidly against hibernate, spring, and several other frameworks that purport to do similar things - removing all those "hard things' so I won't have to worry about them. They all suck royally, as you'll find out in phase 2 or 3 of the evolution of your product when gee, it just doesn't do this one little thing... and then it doesn't do that one little thing, rapidly snowballing into a bigger effort than the original work would have been.
Yep. Since Java's getting them, closures are OK, huh? Sweet logic.
I'm undecided actually, and don't know that depending on which of the three flavors they choose that it's going to make all that much difference other than stating "Java has closures" much in the same way many feel about generics. (And yes, generics suck too in some cases. Mostly they're helpful. And after my run ins with C#'s lack of runtime type checking, I'm willing to bet the same deficiencies with generics exist for them too)
Their collection classes are fine. Oh, and they have generic runtime collections. Does Java? Oh, it doesn't? As for the string index, that's truly idiotic. Going from index 1 to index two is (2-1), if you call subtracting two numbers in your head a computation I think you make have larger issues.
C# collection classes blow. I have to check before adding (and remove if found) or getting a value or it throws an exception? You're kidding, right?
As per the earlier statement - there are no runtime checks in C#. So it doesn't really matter whether they are runtime or not. And yes, if you want, you can create runtime generics or any code at runtime if you'd like, or even alter existing classes. (Not generally recommended, but it can be done)
So, care to show any other areas you're a little thin on? I can't wait to see a scintillating "Duh" or the like.
It was through reflection of a method call IIRC, and in this case the method returned an object that wasn't of the correct type. However, you don't get an error until you try to use said object, which was quite disturbing as it was passed through several methods (all typed) before attempting to be used.
That puts C# on an even less type safe platform than java. In Java, trying to assign such an object at runtime will immediately cause a ClassCastException. C# has no runtime type safety.
Well, explain then how I could assign a string to a List or a Dictionary to a string in C#? Yes, it's true - there's no runtime checking in the CLR. Those "real generics" are not what you think they are.
Delegates? Please, just fancy syntactic sugar for the adapter pattern.
LINQ? I'm not sure that's a thing I'd want in my codebase, ever. Just think of how much "great" SQL code is hopelessly broken and unmaintainable in current codebases.
So, out of all your statements, the only thing that holds water is Closures, which have been debated for a while and are already partially functionally available (anonymous inner classes) sound like they're headed for us in Java 7.
And then speaking of deficiences in C# - what on earth are those horrible collection classes? Those have to be about the worst and most rudimentary collections classes I've ever had the displeasure to use. And what about the string manipulations? You wind up practically having to do an extra computation on every call, because instead of going from index 1 to index 2, they want index 1 and a length....
tech books sales - 3/2008 - wasn't that around when.NET 3.0/3.5 came out? Java's been at v6 for years now. Change drives new book sales.
The rest are largely meaningless other than the pay, and from that you could conjecture a couple of things: either Java programmers are more scarce, or they're worth more to their corporations.
Having just spent the last several months coding in C#, I can fully state that C# is far inferior to Java, and provides even less type safety than Java.
I'd love to hear how and why you think that C# is more advanced and superior to Java, or any other language.
You need to understand it, but how often do you actually analyze non-trivial algorithms (one that require more than counting the number of loops and multiplying by known algorithm times)? In a 10 year career I don't think I've ever done more than that. Not saying more math hurts, and its interesting in and of itself. Unless you're doing 3D graphics (which require trig and linear algebra), you rarely use more than basic algebra and some discrete math concepts. I honestly say I've never used calculus or differential equations professionally.
At one job a little while ago - Multi-variable partial differential equations were used continuously. It's what happens when you're modeling high load rates on orthotropic non-linear strain rate sensitive materials.
Knowing linear algebra allows me to deal with large scale transforms efficiently between multiple array sets, especially when those arrays are multi-dimensional.
Having learned various optimization techniques and algorithms for large data sets sent me down the path of parallelism.
Having learned to think analytically through complex problems and with a few years (ahem) of coding experience allows me to analyze current codebases, follow the flow and optimize or redesign it to improve functionality and performance, or just to find out why that one time in a million, a particular "bad" result pops up.
Slashdot Mirror
Lisp are [sic] doomed
Spring sucks.
Give me one good thing it does that's necessary, done well, and not redundant.
Java may actually lose ground in this "metric". Since the Java programmers are generally segregating in this recession to more seasoned programmers, fewer and fewer will utilize web resources for anything.
Because with Java - I generally do not need to search the web for the answer. However, take C# for instance, and depending on which OS I'm running on, I may have to run 20 or 30 searches for every single answer, because I thought I might have it - but won't know until I try it whether it works for 2.0, 3.0, 3.5, or 3.51....etc.
There's no such thing as 'better'. Given an specific task or application, one language may be better suited to it than another, but 'better' or 'best' language has no meaning when looking at all possible applications.
I think we can all agree COBOL sucks no matter the application.
And nothing more nightmarish than bad assembly.
Have you seen a thorough Spring implementation?
If comcast could profit from bit torrent then they will be happy for it because, when done correctly, bit torrent more efficiently broadcasts across the edges of the network rather than the backbone.
The most efficient means of "broadcasting" anything across the internet or any network is to use multicasting. The biggest impediments to multicasting are:
BitTorrent is merely a work-around to this lack of current functionality that has been in the IPv4 spec since the beginning, at least far as "broadcasting" goes. It's other purpose is distributed file sharing which is a different use case with different requirements.
Fortunately IPv6 requires full multi-cast support to be certified. We can only hope to get there sooner than later.
Three months later? Exactly when was it paid?
but if you'll actually read copyright law, it's not about downloading or copying it yourself, copyright is all about distribution. Which is the only thing they can really get you for. You can copy anything to your heart's content (with exceptions as per the DMCA) you just can not distribute.
Copyright was horribly misnamed, it should have been named DistributionRight.
Apparently the patent in question, 5,825,352, has expired due to failure to pay maintenance fees as of Oct 20, 2006.
So if the patent is expired, what basis are they suing on?
Part (7) says countries can maintain their current length as of the signing date (for US 1987) So there's nothing preventing a roll back to the signing date for each respective country.
Part (8) In any case, the term shall be governed by the legislation of the country where protection is claimed; however, unless the legislation of that country otherwise provides, the term shall not exceed the term fixed in the country of origin of the work.
Is interesting as well.
What's also interesting is that the US adopted the UCC Geneva instead of the Berne in 1955 because the various clauses in the Berne Convention, such as the life of the author clause, were in direct contradiction with US law.
On the surface, it does seem that simple and the effects are certainly borne out by practice. However, there's more to it than that, and the source/type of calories does make a difference in how you feel and can have other side effects.
High fats aren't the problem - high carbs are, especially the kinds in corn syrup and sugar (starches are a little less bad, but still bad overall).
Note that you need some, but not as much as you get in some of these foods.
I look around at all the frameworks that have evolved to not do SQL (EJB-QL, Hibernate, etc) and I laugh. None of those languages come close to handling the same breath and width of problems that SQL can be used to solve. Whenever I see advocates of these frameworks all puff up with fervour, I feel like shaking them and say "Your emperor has no clothes!". The list of problems these frameworks can't solve is so huge that one wonders why anyone works with them at all.
Having had hibernate and JDO forced on me on three previous projects, I can fully support your assessment of these "helper" frameworks. They're functional in their extremely small niches, maybe. What I find humorous is that as soon as you deviate from their 1 or 2 tricks, you'll find hundreds or thousands of lines of code with half of it will being bad SQL to mimic what a simple 1 or 2 line well formed SQL query will give you had you not used said framework. (I'll pass this on: small JDO project - 35K lines of vendor specific DB code, very small hibernate project, 10K lines of code, also vendor specific, and finally, a rather sizable project using hibernate, somewhere in the neighborhood of 40+K lines of code and still counting, but this one's special as it's also infected with the Spring framework. I'll know more in a month or so after I've stripped out both as I need real access to the persistence layer to allow for an entire order of magnitude in scalability and functionality)
But I've never seen them [DBA priests] actually get the SQL working to the point that it can supplant the flat files. The parts that do work are always so slow that turning on the "useDB" switch makes it too sluggish to actually use. In some cases, I can get around this by writing "pre-pass" code to extract the common data sets from the DB and write it to flat files, which the interactive software can read through quickly ... It's better to just develop stuff that works, and let the DB experts handle the task of porting it to the DB. That way, we developers can keep our hands clean of all the theology, and actually develop stuff that works.
You've just succinctly described why so many see DBs as slow and ponderous. No, it's not because they are, it's because the developer didn't do any DBA design nor understand the first thing about DBs to be able to design a decent architecture. Using flat files for your tasking reduces the DB to a pure full fetch model which flat files will usually be faster at for infrequent (ie, non-cached) requests.
You'd be much better served running your POC against mysql or postgresql than flat files. (depending on what flavor of DB you would be running against and the assumption that your "priests" wouldn't give you a copy of their actual DB to play with) At least this would force you into various considerations of data design and to utilize DB functionality.
This is something that has come on gone several times over the past couple of decades. You should have heard the uproar when drive makers first switched to standard SI descriptors. Honestly, it's about time that OSes did the right thing, either use the correct metric or the correct nomenclature.
That's the currently used lame basic anti-blocker practices. Not very good at all if you were interested in stopping ad blockers.
I was actually considering an entirely different process that's relatively easy to implement which I've actually already used on other sites for a different purpose.
This is actually a pretty easy thing for the sites to prevent. They just haven't thought it through.
And no, I will not document how a few relatively simple steps could effectively kill all current generations of ad blockers.
I know I know don't feed the trolls, especially the slow ones....
You're not making any sense. This is nonsensical. Assign a string to a List? Huh?
Yes, it's quite possible, through reflection. What's worse though in C# is that the incorrect object can then be passed all over the place as the "type" that it's not until you try to use it. How did you sum this up? Oh yeah: "Huh?".
Delegates? Please, just fancy syntactic sugar for the adapter pattern.
Right, the same way a "Class" is just fancy syntactic sugar for a pointer to a structure amirite? Shit, C does everything we need then, I guess. Ridiculous.
delegate->adapter/proxy method is like waffle -> sugar cone.
Class-> pointer is like House -> stick.
But I'm sure those are just minor differences to a stellar intellect as yourself.
I'm getting the sneaking suspicion that you don't know what you're talking about, and that in addition you're defining anything not in Java as not being useful or good, which is a bit circular.
Well at least you have a suspicion of something.Too bad its misplaced.
Just because something might look good at first glance as making all those "hard things" go away by just using some pseudo code is really just a short cut that experience has shown will bite you in the ass later sooner or later.
I'm also solidly against hibernate, spring, and several other frameworks that purport to do similar things - removing all those "hard things' so I won't have to worry about them. They all suck royally, as you'll find out in phase 2 or 3 of the evolution of your product when gee, it just doesn't do this one little thing... and then it doesn't do that one little thing, rapidly snowballing into a bigger effort than the original work would have been.
Yep. Since Java's getting them, closures are OK, huh? Sweet logic.
I'm undecided actually, and don't know that depending on which of the three flavors they choose that it's going to make all that much difference other than stating "Java has closures" much in the same way many feel about generics. (And yes, generics suck too in some cases. Mostly they're helpful. And after my run ins with C#'s lack of runtime type checking, I'm willing to bet the same deficiencies with generics exist for them too)
Their collection classes are fine. Oh, and they have generic runtime collections. Does Java? Oh, it doesn't? As for the string index, that's truly idiotic. Going from index 1 to index two is (2-1), if you call subtracting two numbers in your head a computation I think you make have larger issues.
C# collection classes blow. I have to check before adding (and remove if found) or getting a value or it throws an exception? You're kidding, right?
As per the earlier statement - there are no runtime checks in C#. So it doesn't really matter whether they are runtime or not. And yes, if you want, you can create runtime generics or any code at runtime if you'd like, or even alter existing classes. (Not generally recommended, but it can be done)
So, care to show any other areas you're a little thin on? I can't wait to see a scintillating "Duh" or the like.
It was through reflection of a method call IIRC, and in this case the method returned an object that wasn't of the correct type. However, you don't get an error until you try to use said object, which was quite disturbing as it was passed through several methods (all typed) before attempting to be used.
That puts C# on an even less type safe platform than java. In Java, trying to assign such an object at runtime will immediately cause a ClassCastException. C# has no runtime type safety.
Well, explain then how I could assign a string to a List or a Dictionary to a string in C#? Yes, it's true - there's no runtime checking in the CLR. Those "real generics" are not what you think they are.
Delegates? Please, just fancy syntactic sugar for the adapter pattern.
LINQ? I'm not sure that's a thing I'd want in my codebase, ever. Just think of how much "great" SQL code is hopelessly broken and unmaintainable in current codebases.
So, out of all your statements, the only thing that holds water is Closures, which have been debated for a while and are already partially functionally available (anonymous inner classes) sound like they're headed for us in Java 7.
And then speaking of deficiences in C# - what on earth are those horrible collection classes? Those have to be about the worst and most rudimentary collections classes I've ever had the displeasure to use. And what about the string manipulations? You wind up practically having to do an extra computation on every call, because instead of going from index 1 to index 2, they want index 1 and a length....
tech books sales - 3/2008 - wasn't that around when .NET 3.0/3.5 came out? Java's been at v6 for years now. Change drives new book sales.
The rest are largely meaningless other than the pay, and from that you could conjecture a couple of things: either Java programmers are more scarce, or they're worth more to their corporations.
Having just spent the last several months coding in C#, I can fully state that C# is far inferior to Java, and provides even less type safety than Java.
I'd love to hear how and why you think that C# is more advanced and superior to Java, or any other language.
You need to understand it, but how often do you actually analyze non-trivial algorithms (one that require more than counting the number of loops and multiplying by known algorithm times)? In a 10 year career I don't think I've ever done more than that. Not saying more math hurts, and its interesting in and of itself. Unless you're doing 3D graphics (which require trig and linear algebra), you rarely use more than basic algebra and some discrete math concepts. I honestly say I've never used calculus or differential equations professionally.
At one job a little while ago - Multi-variable partial differential equations were used continuously. It's what happens when you're modeling high load rates on orthotropic non-linear strain rate sensitive materials.
Knowing linear algebra allows me to deal with large scale transforms efficiently between multiple array sets, especially when those arrays are multi-dimensional.
Having learned various optimization techniques and algorithms for large data sets sent me down the path of parallelism.
Having learned to think analytically through complex problems and with a few years (ahem) of coding experience allows me to analyze current codebases, follow the flow and optimize or redesign it to improve functionality and performance, or just to find out why that one time in a million, a particular "bad" result pops up.
So no, math is not important at all.