I noticed the exact same thing.
The reason why we bother is probably because nearly 8 years later it's still the highest quality you can buy, and it was miles better than any streaming format when blu-ray just came out. Even if in 6 years streaming will be in 50Mbit/s with better or comparable quality, then it still means we have had some 14 years where blu-ray was the best thing out there.
I also found blu-rays to be often cheaper than digital offerings (e.g. many TV shows are cheaper on blu-ray than they are on iTunes).
Further more, for a lot of countries (e.g. The Netherlands) download options for TV shows are incredibly limited. It's often impossible for those countries to stream from places like iTunes, Amazon or the Sony store. The number of shows offered on blu-ray is much larger and while blu-rays unfortunately can be region protected there are still more options to import.
He means geolocate by the IP and not by what the client says.
Indeed. It doesn't matter much where the data is stored, since the original number originates from the client anyway. If the client wouldn't store the geolocation, someone could still send any location they like to the server.
Either way, having 10 images of a guy who's head is a pixel block will not help you recreate his face.
Actually it could help improve the image. If those 10 images are part of a movement, then it's theoretically possible to reconstruct more detail. The original image moved along the scan-lines of a camera, and every successive shot might have captured a slightly different part of this original image. Understand the scan-lines and the movement, and there's more possible than you might think.
In any fully compliant Java EE 6 application server(*), there is no configuration required at all. Just annotate a simple class in any package with @Path and @Produces. Then add a method that you annotate with @GET and you have a rest resource that can be invoked via the URL path specified in the annotations.
Zero XML and you literally have this running in under a minute.
*) Currently only Glassfish V3.x, but although not certified for the full Java EE 6 spec, JBoss AS 6 works too.
I hear you, but that wasn't what I meant really. When I don't want to handle exceptions because I simply can't handle them, I don't mean I want to swallow them.
In my personal experience, it seems that in a lot of cases the only sensible course of action is to let the exception bubble up right to some top handler that does 'handle' the exception by simply aborting the operating.
In a request/response Java EE situation, this simply means aborting the request and displaying a general error page. Runtime exceptions let you do exactly this without all the boiler plate code and verbosity, which can introduce its own bugs simply by means of obfuscating the real code in your system to your programmers.
No, you should declare an own exception, and wrap the exception of the dependencies in that new exception.
Indeed, this is a reasonable approach, but one that does lead to very deep levels of chained exceptions. Now if the exception is really exceptional this might not be the end of the world, but constantly applying the wrap-retrow pattern can still add a lot of mental overhead to your code. Sometimes this is justified, but in a lot of cases all you want is the exception to be handled by the top level exception handler. You're then creating lots of specific exceptions, lots of specific try/catch code, but it's never really used since it's only the first exception in the chain that counts and nothing is ever done with the intermediate ones.
I do agree that checked exceptions are a great way to force people to document what exceptions a method is expected to throw, which is indeed a benefit.
Anyway, I didn't really start the move away from checked exceptions, just observing that this seems to be happening;)
... To really make this work elegantly, closures are needed, which were on and off the radar for the Java SE 7 release. Because of that, parallel array has somehow stalled. Now that closures are back, so might parallel array be, but I haven't heard anything about it for a while to be honest...
Elegance? Closures? Now you have me scared. Really scared.
Don't be afraid for the unknown my brother. For these kinds of libraries closures actually are very elegant. Apple added a similar thing to C for their GCD library.
And about generics, they are definitely not a useless and dangerous disaster. Yes, you can go overboard with them, but when used in moderation (i.e. 'typing containers'), they work perfectly fine. Much better than having to downcast Object all the time to some type I think might be inserted into the collection.
No, it is actually worse to have only RuntimeExceptions and handle none..
Checked vs unchecked is and endless debate in Java, but to add my 2 cents:
If you only have RunTimeExceptions, then at run time the error actually will surface if you don't explicitly handle them. This means your unit tests and integration tests (you do have those, don't you?) will most likely catch them.
Checked exceptions are only useful if you can handle them, but 99 out of 100 times you can't. If there's a SQLException being thrown, seriously, what can your code do about it? In practice what we see is that either exceptions get wrapped and wrapped and wrapped... up till 10 levels or more deep. Alternatively, your code can declare the exceptions being thrown by its dependencies, but then you end up with dependencies bleeding into layers where they have no business.
Java checked exceptions do absolutely nothing to help when you're working with dynamically-loaded code, for instance.
That's only partially true. If the language would only have checked exceptions and you would be coding against interfaces (often still the case with dynamically-loaded code), then checked exceptions would still work, whether the code implementing said interfaces was dynamically loaded or not.
Now the problem here is that there are also unchecked exceptions which the code might throw, but this is really unrelated to the dynamic loading. One thing that could break things though, is if you not only dynamically load the code, but also execute said code via reflection. Then indeed checked exceptions might not do anything...
People need to remember that if something is really open, then it also means it is open to someone doing their own thing with it.
Right, and so many companies actually did with Java. Only with one 'minor' difference: they didn't call it "Java SE".
The problem with MS was not that it was extending Java, but that it was luring programmers into thinking they were coding for the Java SE standard. If you were at a MS platform and only checked your code with Visual Studio, then you as a programmer wouldn't know. Until your users tried to run your Java app on their Linux or Solaris boxes, and found out it didn't work at all.
A very simple solution for MS would have been to provide flags in their environment for "standard compliance Java development" and "non-standard compliance Java development". If my memory serves me well, they had such flags for C++ in their compiler.
Java, while widely used is on the down slide. There really hasn't been any new revolutionary additions to the language in about 7 years. In another 10 years, it will become like COBOL is to IBM.
The only thing that has remained the same in about 7 years are the posts about "Java is dead", meanwhile Java is still the most widely used language and in those 7 years additions have been made to the language (generics, annotations, type safe enums, etc) and soon we'll have some extra goodies like closures and automatic resource management. Maybe those are not revolutionary, but enough IMHO to keep the language with the times.
Meanwhile, there is a lot of innovation going on in the platform, especially with Java EE and how it uses annotations for things other languages might use keywords for (e.g. annotations to make methods transactional).
Is Java doomed to get stuck behind in the single processor world
Far from it actually... of course Java has had the absolute low level concurrency primitives from the very beginning (Threads, synchronized blocks, wait/notify). More than half a decade ago, the java.concurrent library was added to the platform, which added tons of goodies for concurrent/parallel programming like concurrent maps, blocking queues, thread pools and executor services, cyclic barriers, programmatic locks with timeouts (which actually performed better than the build-in locks based on the synchronized keyword) etc.
Now Java 7 will be extended with the join/fork framework, which is essentially a thread pool and support code for (recursively) computational intensive operations and supports advanced features like work stealing. The join/fork framework has been specifically designed to scale into the many, many multi-core range. Not just quad, hex or oct cores but well beyond that.
Parallel array is another topic on the agenda, which allows you to express in an almost declarative style operations on arrays, which the library will then execute for you in parallel. To really make this work elegantly, closures are needed, which were on and off the radar for the Java SE 7 release. Because of that, parallel array has somehow stalled. Now that closures are back, so might parallel array be, but I haven't heard anything about it for a while to be honest.
>Does Java still have checked exceptions in common use?
No, I'm sorry for you. The standard platform is moving away from them and is resorting to run time exceptions being mentioned in Java doc. E.g. an excerpt from the platform standard class EntityManager:
public interface EntityManager { /** * Make an entity instance managed and persistent. * * @param entity * @throws EntityExistsException if the entity already exists. * (The EntityExistsException may be thrown when the persist * operation is invoked, or the EntityExistsException or * another PersistenceException may be thrown at commit * time.) * @throws IllegalStateException if this EntityManager has been closed. * @throws IllegalArgumentException if not an entity * @throws TransactionRequiredException if invoked on a * container-managed entity manager of type * PersistenceContextType.TRANSACTION and there is * no transaction. */ public void persist(Object entity);
India and China are cranking out about 600,000 engineers a years, and each of those countries has 4X the US population. And wages in those countries are tiny fraction of wages in the US or UK.
Newsweek has an interesting series of articles on that this week. Turns out there actually is a limit to the Chinese success story. I've read the article "Smart, Young, and Broke" with much interest, which is about a Chinese software developer who's in the same boat as the UK graduates. Graduated with excellent results, yet unable to find a decent job.
Another factor is that the outsourcing of IT jobs assume these IT workers don't want to consume any of the IT goods themselves. I'm not sure this is going to be true indefinitely. If you're working in IT, and you produce for €1 that product people in 'the west' are selling for €100, what do you do when you want that product yourself?
You can't possible buy it for the price it's been sold for, since that's about a 100x more than you get payed. But wait... you know it's actually manufactured for €1, so why not convince people to sell it locally for say €2? Then you can buy it, and those people in the West can also still buy it for €100 and everybody is happy, right?
But then some clever kid will realize that especially software can travel just as easy the other way around, so if you can buy it locally for €2 and those crazy Western people are willing to pay €100, why not sell it to them for say €20? This clever kid will instantly make €18, which would be a lot of money for them, and the Western buyer would still feel he has gotten the product dirt cheap! Win-Win, right?
Eventually this will not work of course. Producing low and selling high will only work as long as the kids producing stuff don't also want to consume, don't want to improve their standards of living. In manufacturing this is maybe possible to uphold, but in IT we're talking about highly educated persons, who have the Internet at their fingertips. They also DO want that iPhone and they DO want this 40" hi-def LCD and they are tired of those crappy low-quality VCDs and prefer those shiny new Blu-rays.
Simultaneously, you have opposite forces working in the West. If you want to sell something for €100, then people you want to buy that product also have to make a €100 at the least. With manufacturing this worked, since the lowly payed jobs were outsourced and the local population was trained for higher payed/highly educated jobs. With IT outsourcing this seems to be the other way around; the highly educated jobs are outsourced and the local population is supposed to take on lower payed jobs?
So the Eastern guy producing the stuff we outsource is going to demand more, thereby increasing the average salary there, while the Western guy is going to have to demand less, thereby decreasing the average income there. Soon, "produce for €1 sell for €100" may not work anymore, since Honghui is going to demand €25 for his work and John will have no more than €30 to spare.
I don't quite agree with your ranting against CS. For starters, I don't really see you mentioning the fact that CS typically has different tracks.
At my university we had two main tracks, applied computer science and theoretical computer science, with the first being further sub-dived in "computer systems" and "software engineering" and the theoretical track being sub-dived in "algorithmic" and "foundational computer science".
The software engineering track will give you subjects about requirements engineering, software engineering (obviously) and teach you diverse stuff like UML diagrams, development cycles, design patterns, etc.
The algorithms track on its turn invited me to look at a diverse range of algorithms (obviously again), but also to datastructures (how does something like a hashmap works internally, what kinds of trees do we have, what variations on linked lists are there, etc).
The foundational track then let me look at stuff like turing machines, grammars, finite state machines, theory of computation etc. This is the stuff few 'programmers' would study by themselves if not told they should.
Finally, knowledge of several tracks was combined for the subject compiler construction, where you had to write in C a Pascal to MIPS compiler. For this course you needed to have (C) programming skills, enough skills to understand a language you might not know yet (Pascal), understand how a machine works at the low level (registers, assembly, etc) and have some idea about context free grammars.
Now all of this is in the bachelor, meaning all the subjects are basically introductions to their respective fields. You're not a scientist yet if you have completed them. In the Master phase, you choose a specific track to specialize in but you can still take subjects from the other tracks if you want. In my case I choose the computer systems track and learned some additional stuff about grids, parallel computing, software architecture, etc. Now the thing is, you can't really say that CS educates you to become a scientist or not or that CS skills have no practical value if you don't take into consideration the track chosen by the student. Obviously an applied computer science track has more practical value for the average company than the theoretical track, but it depends on what you want to do really.
Most of all I don't agree with your point that CS somehow tried to cram knowledge in the heads of dumb students. Far from it... the way I experienced CS was a period of my life where I was simply allotted time and opportunity to directly dedicate on bettering myself. Classes weren't there to teach me stuff, but to *support* me in learning. Basically what the CS program does is compiling a lis
The Netherlands are the most environmentally unfriendly country in the world.
Yeah, all that cycling around instead of riding cars is really bad for the environment. And those windmills they historically used to keep the land (polders) dry... oh man, that really must have dealt some blows to the environment...
Think about what you're asking. From almost every other dynamic languages, you don't get true primitives - you have an object handle that contains the primitive bytes or an object like Integer.
Well, I wasn't really asking anything to be honest. It's true that the default collections in Java can not store primitives directly, and thus by extension their generic versions can't either.
Java and primitives have a rather debatable relationship with each other. Some say Java would be cleaner if there weren't any primitives and only their Object versions. Like bit-shifting operators and native arrays, they were included in the Java language for the class of algorithms where simple and direct memory manipulation offers huge performance gains. But Java is not really used a lot for these kinds of niches (C and C++ shine here) so most of the time they feel a little out of place and they often bleed into business code where they have no place really.
(or worse, a polymorphic object which is very heavy weight and slow for things like ++)
Well, in Java the primitive wrapper types are final (can't be sub classed) and immutable, so that takes care of a whole slew of problems. However, incrementing a primitive wrapper type may seem heavy weight, since it would always require unboxing of the wrapper, evaluating the increment expression and then creating a new instance (and discarding the previous instance). In the end though, all that matters is what instructions are eventually generated for the CPU. Because of the strong run-time optimizations being done by the VM, the actual code that gets generated may in fact not at all do this and may actually be optimized into a simple register allocated value that gets incremented, instead of the entire Object manipulation with all the complicated stuff around that.
At the end of the day, the generics don't change how you code, they just replace your references to Object with a token. Thus if your algorithm requires storage as per-object, you get NOTHING by storing the primitive.
I agree that the current state of generics in Java won't give you any advantage even if it was possible to declare say a List<int> But just to be sure, let's not confuse that with generics in general (for Object types), which actually do make your code more type safe.
Right, the "Java is needed for advanced stuff" argument. Fact: If your web application is "too advanced for PHP" you are doing it wrong and should simplify your design.
For the love of god, wake up man. Not every web application is Joe's Burgers. Not every web application is essentially a web site with some dynamics. Some web applications are simply enterprise applications where the front-end happens to be rendered via HTML accessible via a web browser. They do heavy computations, processing, reporting, run simulations and yes, they DO NEED concurrency, and yes they DO NEED transactions.
If a web application is "too advanced for PHP" then mark my words "it's too advanced for PHP". The model of fetching parameters from the request at the top of the page, feed them into an SQL query, and iterate over the result set while spitting out some HTML is fine for those 4 page web sites, and maybe even the 20 page ones, but it does not fit every possible application out there.
Are you the same kind of person who walks up to a civil engineer designing that bridge over a large river telling him al his or her schooling and techniques are wrong, and the design needs to be simplified, and that it all can be done in an afternoon instead of 3 years, since that 16 year old kid just threw an old shelf over a ditch and he had a bridge?
And I'm not sure how many times I have to explain this, but there is nothing complicated about USING some of this 'advanced' stuff. Yes, it's quite complicated to implement this under the hood, but guess what, the guys who bring us Java EE implementations have already figured out the hard stuff. I can simply use it, and with 'simply' I really mean 'simply.
But okay, Mr Einstein, let me play along a little. Tell me how 'simplifying' my design magically gives me transactional semantics for non trivial operations.
Any web app will be IO bound anyway.
Good one. Take an app, ANY app. Slap a web interface on top of it, and any part of the app that was CPU bound suddenly becomes IO bound. Really?
Dependency injection is a kludge you only need because Java is static and not dynamic.
Dependency injection is about separation of concerns mister, and has very little to nothing to do with typing.
Transactions should be handled by the framework
Which is precisely how it is done in Java, via the very stable and mature Java Transaction API, that one can either use programmatically or declaratively via enterprise bean. Your point again?
the transaction decorators always been misused by overzealous developers creating huge transactions slowing the application down to a crawl.
Maybe you're referring to some home grown 'transaction decorator' as may typically attempted to be made in PHP by programmers who have a basic understanding of stuff, yet overestimate their abilities and think they can just build transparent transactions themselves. I mean, what could possible go wrong, right? If you're referring to the default declarative transaction support in Java EE, then really this is rarely a problem. If you don't know your stuff and simply do too much work in a transactional method, then you're simply doing too much work. That would have been a problem regardless of using a transactional method or not. Like so many other things, it's a professional tool that's utterly simple to use, but you do have to know what you're doing. Just as you should not blindly make each and every method asynchronous or each and every method synchronized etc.
It proves that you are one of those Java only developers too stupid to learn new languages.
I think it actually proves you are someone who jumps a little too fast to a conclusion. For the record, I started programming when I was 6 in C64 BASIC, quickly moved on to assembly, then C on an Amiga and later Apple, C++ on an SGI
Agreed. If you have the second most popularwebsite in the world serving over 400 billion dynamically generated page views per month from a backend of over 30,000 servers, you absolutely do not want to rely on PHP to serve those pages for you.
This is the same old argument over and over again. Facebook and a couple of other large sites building on PHP don't work the way they do because of PHP, but despite being build on PHP. There's a lot of engineering effort put into those sites, with a not unimportant share of that devoted to things having nothing to do with what PHP handles. With such engineering effort being poured in, Facebook could have been developed in assembly or COBOL, neither of which would have been prove that they are inherently suited for such environments.
Also, don't forget that Facebook is migrating to their C++ based hiphop toolchain and have build their own internal framework, a framework that resembles the Java EE stack in a couple of ways and is NOT available to the general public. The kind of PHP that Facebook does is NOT your typical 'phpfreakz' kind of PHP that is most commonly practiced.
I've also personally talked to the lead developer of Hyves -- the Dutch version of Facebook with some 12 million users -- and he said 'PHP is a little shit language' (PHP is een kut taaltje). I understand that out of context this may not mean much, but he did said that. Additionally, Hyves, Tweakers (a Dutch news site) and a couple of other companies I know that use PHP professionally, some of which I know people working there, almost all seem to agree on that it's very difficult to find really skilled PHP programmers. There is an abundance of programmers that are of the Joe's Burgers variety and have hacked on some PHP script, but that's a completely different category really and not at all what a professional organization is looking for.
So, even though a select few companies are using PHP very professionally, the norm in the PHP market is that it's used by people who barely know the difference between a while loop and an if statement, let alone that they know anything at all about data structures, algorithms, or efficiently structuring their code.
Does PHP offers anything like that? Does the standard PHP library already comes with an MVC framework? Is unicode already natively supported? Is there any name spacing support? Is there..
Those aren't real problems unless they are actively preventing you from developing your website, which is probably only the case about 2% of the time. The other 98% of the time you never need consider them.
And that's precisely where it all goes wrong. We don't need no education anymore, we don't need no knowledge about CS theory, we don't need no transactions, we don't need no unicode, we don't need no MVC... PHP is so easy... a baby can now program any web site..... Until it all comes falling down.
It's the typical Visual Basic kind of mindset. A mindset about which you can read everyday on thedailywtf. Sure, idiots can produce crap in any language, but for some reason both PHP and VB seem to produce a disproportionate amount of that.
You sound like you did very well in school, and maybe even graduated at the top of you CS class. You also sound like you may have little real world experience.
I did okay in school and CS went well too, thank you. I'm currently the lead developer of a 12 person strong development team I've worked with for about 7 years. We're building an enterprise application consisting of several 100k LOC and every day have to deal with an infuriating amo
Its perhaps the midset that says you need something more complex and featured to do the tasks that are required that is Java's problem.
I'm sorry, but I think you're making the exact same mistake, but the other way around; thinking that because Joe's Burgers 4 web page website doesn't need transactions and asynchronicity, no application needs it. That's equally false. Quite a lot of (web) applications actually DO need that, and especially parallel and asynchronous execution is going to be a lot more important now that e.g. the top tier of commodity hardware can give you no less than 32 cores, while cheap entry level servers already feature 8 cores. In general you're not going to keep those cores busy just by means of letting each request go to a core. At some point you have to start dividing the work that needs to be done for each request. Java is ready for this, PHP hasn't even started with the absolute basics.
Think about all the web apps you've ever seen. They're not that complex (except the crap one that are), all they need to do is manipulate data via a GUI (ie html page) and shove it into a DB.
For starters, there is a LOT more server side software running in this world than just all those crappy CRUD-style websites. More importantly perhaps, you somehow equate 'advanced' stuff like transactions with complexity. But nothing could be further from the truth. Do you know what it takes in Java to make the methods of a class transactional? 1 annotation. You annotate the class with @Stateless, and its methods are transactional. Now you tell me, where is the complexity there?
Furthermore, even simple web apps that manipulate data via a GUI could easily benefit from transactions. If I operate a simple web app that lets my customer say order stuff, I won't really be happy if I have an order in my DB, but nobody to bill. Simple does not necessarily needs to be the same as simplistic. I can build a very simple CRUD style app, but still take advantage of parallel execution and transactions in my persistence methods. If a simple page needs to execute 3 distinct queries in order to get the data it needs to display, why not execute those queries in parallel? It's not the complexity you have to be afraid of, just apply the @Asynchronous annotation to a method and it will execute asynchronously, giving you a very simple yet super powerful way to exploit those cores in your machine.
especially when its so difficult to install glassfish/Tomcat/JREs/etc.
Excuse me??? Difficult to install Tomcat??? It's a freaking unzip of the archive you downloaded and it's fully operational. Same goes for Glassfish and JBoss AS. You download something, unzip it, and it's there. Or you use your package manager and execute a simple sudo apt-get install tomcat. If that's already difficult for you, you probably shouldn't be in programming really.
Don't knock those PHP apps, they're doing stuff right - despite being written in PHP! Look to them to see where your Java apps are going wrong.
My Java apps are not going wrong at all. They're humming along nicely thank you. Now have you ever tried to maintain a PHP app of any non trivial size? I mean, have you really had to? If you had, you'd known about the typical unreadable spaghetti mess that most PHP code so quickly deteriorates to. People may occasionally curse at Java's request life-cycle, backing beans and enterprise beans, but at least my view code, validators, converters, view logic and business logic are neatly in a default location. With PHP, the sky is the limit. It's basically an assembly kind of web language. There is no pre-defined structure, no guide lines, no nothing. Want to dump that critical business logic between the tr and td tag in your view code? PHP happily lets you and worse of all, your peers and the whole community even seem to push you in doing that, or at the very least turn a blind eye or just simply don't care.
If that's the kind of community you want to live in, have fun! But it's not my kind of fun.
Believe it or not, but the latest is that they're actually going to release it this year. Not that there's a JSR yet, but don't let that destroy our hopes;)
And guess what, in C#, C++, Python, Ruby, Javascript, Haskell, Ocaml etc. you do _not_ need an interface here. Using an interface in this case is just wrong, necessary in Java, but essentially wrong.
It's true that Java doesn't has a direct syntax to do that, which indeed may be a shame. But it's also not absolutely necessary. In the UI layer for example and increasingly in other parts of the code, Java uses an expression language (typically abbreviated as EL).
With EL in Java, I basically do precisely that. E.g.
T getFoo() { return foo; }
And then in the view definition e.g.
<h:outputText value="#{myBean.foo.some_call()}"/>
Because of the usefulness of this, there are various efforts going on to support EL in more parts of Java than just the UI.
Then again, Java generics are an ugly hack that applies unnecessary type erasure
Sadly this is true, and an unfortunate consequence from the fact that Java added generic support relatively late in its life cycle. This opens the door to some very awkward corner cases.
That said, the benefits of such a sub-optimal generics implementation for me still far outweigh the disadvantage of not having any generics at all.
Also, don't forget that C++ templates not only are a whole different beast, but they actually have issues too. Not in the least that they function more or less as type factories, that produce different types for a different T, that are in no way related to each other. Maybe the situation has improved lately, but I remember that the compiler would generate a complete new list definition for each T I used it for. Ouch!
I've seen buggy code come from well dress nice looking people who just didn't know what the hell they're doing. I've seen great code come from long haired weirdo's who are thoughtful and would be extremely offended if you called them an "engineer".
Sure, and I've seen long haired tattooed weirdos not knowing the first thing about correctness, stability or consistency of their code, and where basically every other class of theirs has a different layout and does similar things in a different way. You know, the kind of code where they store an image in the root folder as/tmp.png with the excuse that 'it's very unlikely that 2 people upload an image exactly at the same time'. Yes, I've heard those 'cool kids' uttering stuff like that.
Just because you are a 'cool kid' does not necessarily make you an intelligent, well thinking developer.
The point being, trying to find some set of outward properties for good software developers doesn't really work. You have to be smart, but even smart doesn't make a good developer. You have to be smart enough to know you're dumb (an exceedingly important quality).
Slashdot Mirror
I also found blu-rays to be often cheaper than digital offerings (e.g. many TV shows are cheaper on blu-ray than they are on iTunes).
Further more, for a lot of countries (e.g. The Netherlands) download options for TV shows are incredibly limited. It's often impossible for those countries to stream from places like iTunes, Amazon or the Sony store. The number of shows offered on blu-ray is much larger and while blu-rays unfortunately can be region protected there are still more options to import.
He means geolocate by the IP and not by what the client says.
Indeed. It doesn't matter much where the data is stored, since the original number originates from the client anyway. If the client wouldn't store the geolocation, someone could still send any location they like to the server.
Either way, having 10 images of a guy who's head is a pixel block will not help you recreate his face.
Actually it could help improve the image. If those 10 images are part of a movement, then it's theoretically possible to reconstruct more detail. The original image moved along the scan-lines of a camera, and every successive shot might have captured a slightly different part of this original image. Understand the scan-lines and the movement, and there's more possible than you might think.
In any fully compliant Java EE 6 application server(*), there is no configuration required at all. Just annotate a simple class in any package with @Path and @Produces. Then add a method that you annotate with @GET and you have a rest resource that can be invoked via the URL path specified in the annotations.
Zero XML and you literally have this running in under a minute.
*) Currently only Glassfish V3.x, but although not certified for the full Java EE 6 spec, JBoss AS 6 works too.
In the early 90's, the Neo Geo box art looked amazing too and guess what, the actual graphics were pretty decent as well (even to today's standard).
Then you just don't handle them!
I hear you, but that wasn't what I meant really. When I don't want to handle exceptions because I simply can't handle them, I don't mean I want to swallow them.
In my personal experience, it seems that in a lot of cases the only sensible course of action is to let the exception bubble up right to some top handler that does 'handle' the exception by simply aborting the operating.
In a request/response Java EE situation, this simply means aborting the request and displaying a general error page. Runtime exceptions let you do exactly this without all the boiler plate code and verbosity, which can introduce its own bugs simply by means of obfuscating the real code in your system to your programmers.
No, you should declare an own exception, and wrap the exception of the dependencies in that new exception.
Indeed, this is a reasonable approach, but one that does lead to very deep levels of chained exceptions. Now if the exception is really exceptional this might not be the end of the world, but constantly applying the wrap-retrow pattern can still add a lot of mental overhead to your code. Sometimes this is justified, but in a lot of cases all you want is the exception to be handled by the top level exception handler. You're then creating lots of specific exceptions, lots of specific try/catch code, but it's never really used since it's only the first exception in the chain that counts and nothing is ever done with the intermediate ones.
I do agree that checked exceptions are a great way to force people to document what exceptions a method is expected to throw, which is indeed a benefit.
Anyway, I didn't really start the move away from checked exceptions, just observing that this seems to be happening ;)
Elegance? Closures? Now you have me scared. Really scared.
Don't be afraid for the unknown my brother. For these kinds of libraries closures actually are very elegant. Apple added a similar thing to C for their GCD library.
And about generics, they are definitely not a useless and dangerous disaster. Yes, you can go overboard with them, but when used in moderation (i.e. 'typing containers'), they work perfectly fine. Much better than having to downcast Object all the time to some type I think might be inserted into the collection.
No, it is actually worse to have only RuntimeExceptions and handle none..
Checked vs unchecked is and endless debate in Java, but to add my 2 cents:
If you only have RunTimeExceptions, then at run time the error actually will surface if you don't explicitly handle them. This means your unit tests and integration tests (you do have those, don't you?) will most likely catch them.
Checked exceptions are only useful if you can handle them, but 99 out of 100 times you can't. If there's a SQLException being thrown, seriously, what can your code do about it? In practice what we see is that either exceptions get wrapped and wrapped and wrapped... up till 10 levels or more deep. Alternatively, your code can declare the exceptions being thrown by its dependencies, but then you end up with dependencies bleeding into layers where they have no business.
Java checked exceptions do absolutely nothing to help when you're working with dynamically-loaded code, for instance.
That's only partially true. If the language would only have checked exceptions and you would be coding against interfaces (often still the case with dynamically-loaded code), then checked exceptions would still work, whether the code implementing said interfaces was dynamically loaded or not.
Now the problem here is that there are also unchecked exceptions which the code might throw, but this is really unrelated to the dynamic loading. One thing that could break things though, is if you not only dynamically load the code, but also execute said code via reflection. Then indeed checked exceptions might not do anything...
People need to remember that if something is really open, then it also means it is open to someone doing their own thing with it.
Right, and so many companies actually did with Java. Only with one 'minor' difference: they didn't call it "Java SE".
The problem with MS was not that it was extending Java, but that it was luring programmers into thinking they were coding for the Java SE standard. If you were at a MS platform and only checked your code with Visual Studio, then you as a programmer wouldn't know. Until your users tried to run your Java app on their Linux or Solaris boxes, and found out it didn't work at all.
A very simple solution for MS would have been to provide flags in their environment for "standard compliance Java development" and "non-standard compliance Java development". If my memory serves me well, they had such flags for C++ in their compiler.
Java, while widely used is on the down slide. There really hasn't been any new revolutionary additions to the language in about 7 years. In another 10 years, it will become like COBOL is to IBM.
The only thing that has remained the same in about 7 years are the posts about "Java is dead", meanwhile Java is still the most widely used language and in those 7 years additions have been made to the language (generics, annotations, type safe enums, etc) and soon we'll have some extra goodies like closures and automatic resource management. Maybe those are not revolutionary, but enough IMHO to keep the language with the times.
Meanwhile, there is a lot of innovation going on in the platform, especially with Java EE and how it uses annotations for things other languages might use keywords for (e.g. annotations to make methods transactional).
Is Java doomed to get stuck behind in the single processor world
Far from it actually... of course Java has had the absolute low level concurrency primitives from the very beginning (Threads, synchronized blocks, wait/notify). More than half a decade ago, the java.concurrent library was added to the platform, which added tons of goodies for concurrent/parallel programming like concurrent maps, blocking queues, thread pools and executor services, cyclic barriers, programmatic locks with timeouts (which actually performed better than the build-in locks based on the synchronized keyword) etc.
Now Java 7 will be extended with the join/fork framework, which is essentially a thread pool and support code for (recursively) computational intensive operations and supports advanced features like work stealing. The join/fork framework has been specifically designed to scale into the many, many multi-core range. Not just quad, hex or oct cores but well beyond that.
Parallel array is another topic on the agenda, which allows you to express in an almost declarative style operations on arrays, which the library will then execute for you in parallel. To really make this work elegantly, closures are needed, which were on and off the radar for the Java SE 7 release. Because of that, parallel array has somehow stalled. Now that closures are back, so might parallel array be, but I haven't heard anything about it for a while to be honest.
This blog post has a nice summary about some of the added concurrency items in Java 7: http://www.baptiste-wicht.com/2010/04/java-7-more-concurrency/
>Does Java still have checked exceptions in common use?
/**
No, I'm sorry for you. The standard platform is moving away from them and is resorting to run time exceptions being mentioned in Java doc. E.g. an excerpt from the platform standard class EntityManager:
public interface EntityManager {
* Make an entity instance managed and persistent.
*
* @param entity
* @throws EntityExistsException if the entity already exists.
* (The EntityExistsException may be thrown when the persist
* operation is invoked, or the EntityExistsException or
* another PersistenceException may be thrown at commit
* time.)
* @throws IllegalStateException if this EntityManager has been closed.
* @throws IllegalArgumentException if not an entity
* @throws TransactionRequiredException if invoked on a
* container-managed entity manager of type
* PersistenceContextType.TRANSACTION and there is
* no transaction.
*/
public void persist(Object entity);
India and China are cranking out about 600,000 engineers a years, and each of those countries has 4X the US population. And wages in those countries are tiny fraction of wages in the US or UK.
Newsweek has an interesting series of articles on that this week. Turns out there actually is a limit to the Chinese success story. I've read the article "Smart, Young, and Broke" with much interest, which is about a Chinese software developer who's in the same boat as the UK graduates. Graduated with excellent results, yet unable to find a decent job.
Another factor is that the outsourcing of IT jobs assume these IT workers don't want to consume any of the IT goods themselves. I'm not sure this is going to be true indefinitely. If you're working in IT, and you produce for €1 that product people in 'the west' are selling for €100, what do you do when you want that product yourself?
You can't possible buy it for the price it's been sold for, since that's about a 100x more than you get payed. But wait... you know it's actually manufactured for €1, so why not convince people to sell it locally for say €2? Then you can buy it, and those people in the West can also still buy it for €100 and everybody is happy, right?
But then some clever kid will realize that especially software can travel just as easy the other way around, so if you can buy it locally for €2 and those crazy Western people are willing to pay €100, why not sell it to them for say €20? This clever kid will instantly make €18, which would be a lot of money for them, and the Western buyer would still feel he has gotten the product dirt cheap! Win-Win, right?
Eventually this will not work of course. Producing low and selling high will only work as long as the kids producing stuff don't also want to consume, don't want to improve their standards of living. In manufacturing this is maybe possible to uphold, but in IT we're talking about highly educated persons, who have the Internet at their fingertips. They also DO want that iPhone and they DO want this 40" hi-def LCD and they are tired of those crappy low-quality VCDs and prefer those shiny new Blu-rays.
Simultaneously, you have opposite forces working in the West. If you want to sell something for €100, then people you want to buy that product also have to make a €100 at the least. With manufacturing this worked, since the lowly payed jobs were outsourced and the local population was trained for higher payed/highly educated jobs. With IT outsourcing this seems to be the other way around; the highly educated jobs are outsourced and the local population is supposed to take on lower payed jobs?
So the Eastern guy producing the stuff we outsource is going to demand more, thereby increasing the average salary there, while the Western guy is going to have to demand less, thereby decreasing the average income there. Soon, "produce for €1 sell for €100" may not work anymore, since Honghui is going to demand €25 for his work and John will have no more than €30 to spare.
I don't quite agree with your ranting against CS. For starters, I don't really see you mentioning the fact that CS typically has different tracks.
At my university we had two main tracks, applied computer science and theoretical computer science, with the first being further sub-dived in "computer systems" and "software engineering" and the theoretical track being sub-dived in "algorithmic" and "foundational computer science".
In the bachelor part of the education (3 years), you get a mix of subjects from all tracks. The computer systems track will give you courses like computer architecture ,which allows you to read this particular nice book: http://www.amazon.com/Computer-Architecture-Quantitative-Approach-4th/dp/0123704901 and where you write your own CPU emulator. It will also give you the subject operating systems, which gives you time to read this book http://www.amazon.co.uk/Operating-System-Concepts-Abraham-Silberschatz/dp/0470233990/ref=sr_1_1?ie=UTF8&s=books&qid=1278151357&sr=8-1 or this one http://www.amazon.co.uk/Modern-Operating-Systems-International-Version/dp/0138134596/ref=sr_1_3?ie=UTF8&s=books&qid=1278151357&sr=8-3 and typically gives you assignments where you write some kernel module like an IO scheduler or memory manager.
The software engineering track will give you subjects about requirements engineering, software engineering (obviously) and teach you diverse stuff like UML diagrams, development cycles, design patterns, etc.
The algorithms track on its turn invited me to look at a diverse range of algorithms (obviously again), but also to datastructures (how does something like a hashmap works internally, what kinds of trees do we have, what variations on linked lists are there, etc).
The foundational track then let me look at stuff like turing machines, grammars, finite state machines, theory of computation etc. This is the stuff few 'programmers' would study by themselves if not told they should.
Finally, knowledge of several tracks was combined for the subject compiler construction, where you had to write in C a Pascal to MIPS compiler. For this course you needed to have (C) programming skills, enough skills to understand a language you might not know yet (Pascal), understand how a machine works at the low level (registers, assembly, etc) and have some idea about context free grammars.
Now all of this is in the bachelor, meaning all the subjects are basically introductions to their respective fields. You're not a scientist yet if you have completed them. In the Master phase, you choose a specific track to specialize in but you can still take subjects from the other tracks if you want. In my case I choose the computer systems track and learned some additional stuff about grids, parallel computing, software architecture, etc. Now the thing is, you can't really say that CS educates you to become a scientist or not or that CS skills have no practical value if you don't take into consideration the track chosen by the student. Obviously an applied computer science track has more practical value for the average company than the theoretical track, but it depends on what you want to do really.
Most of all I don't agree with your point that CS somehow tried to cram knowledge in the heads of dumb students. Far from it... the way I experienced CS was a period of my life where I was simply allotted time and opportunity to directly dedicate on bettering myself. Classes weren't there to teach me stuff, but to *support* me in learning. Basically what the CS program does is compiling a lis
The Netherlands are the most environmentally unfriendly country in the world.
Yeah, all that cycling around instead of riding cars is really bad for the environment. And those windmills they historically used to keep the land (polders) dry... oh man, that really must have dealt some blows to the environment...
Ever seen a Dutch woman? The average ones aren't really small and certainly not girly. The Dutch dykes were build to last :P
Think about what you're asking. From almost every other dynamic languages, you don't get true primitives - you have an object handle that contains the primitive bytes or an object like Integer .
Well, I wasn't really asking anything to be honest. It's true that the default collections in Java can not store primitives directly, and thus by extension their generic versions can't either.
Java and primitives have a rather debatable relationship with each other. Some say Java would be cleaner if there weren't any primitives and only their Object versions. Like bit-shifting operators and native arrays, they were included in the Java language for the class of algorithms where simple and direct memory manipulation offers huge performance gains. But Java is not really used a lot for these kinds of niches (C and C++ shine here) so most of the time they feel a little out of place and they often bleed into business code where they have no place really.
(or worse, a polymorphic object which is very heavy weight and slow for things like ++)
Well, in Java the primitive wrapper types are final (can't be sub classed) and immutable, so that takes care of a whole slew of problems. However, incrementing a primitive wrapper type may seem heavy weight, since it would always require unboxing of the wrapper, evaluating the increment expression and then creating a new instance (and discarding the previous instance). In the end though, all that matters is what instructions are eventually generated for the CPU. Because of the strong run-time optimizations being done by the VM, the actual code that gets generated may in fact not at all do this and may actually be optimized into a simple register allocated value that gets incremented, instead of the entire Object manipulation with all the complicated stuff around that.
At the end of the day, the generics don't change how you code, they just replace your references to Object with a token. Thus if your algorithm requires storage as per-object, you get NOTHING by storing the primitive.
I agree that the current state of generics in Java won't give you any advantage even if it was possible to declare say a List<int> But just to be sure, let's not confuse that with generics in general (for Object types), which actually do make your code more type safe.
Right, the "Java is needed for advanced stuff" argument. Fact: If your web application is "too advanced for PHP" you are doing it wrong and should simplify your design.
For the love of god, wake up man. Not every web application is Joe's Burgers. Not every web application is essentially a web site with some dynamics. Some web applications are simply enterprise applications where the front-end happens to be rendered via HTML accessible via a web browser. They do heavy computations, processing, reporting, run simulations and yes, they DO NEED concurrency, and yes they DO NEED transactions.
If a web application is "too advanced for PHP" then mark my words "it's too advanced for PHP". The model of fetching parameters from the request at the top of the page, feed them into an SQL query, and iterate over the result set while spitting out some HTML is fine for those 4 page web sites, and maybe even the 20 page ones, but it does not fit every possible application out there.
Are you the same kind of person who walks up to a civil engineer designing that bridge over a large river telling him al his or her schooling and techniques are wrong, and the design needs to be simplified, and that it all can be done in an afternoon instead of 3 years, since that 16 year old kid just threw an old shelf over a ditch and he had a bridge?
And I'm not sure how many times I have to explain this, but there is nothing complicated about USING some of this 'advanced' stuff. Yes, it's quite complicated to implement this under the hood, but guess what, the guys who bring us Java EE implementations have already figured out the hard stuff. I can simply use it, and with 'simply' I really mean 'simply.
But okay, Mr Einstein, let me play along a little. Tell me how 'simplifying' my design magically gives me transactional semantics for non trivial operations.
Any web app will be IO bound anyway.
Good one. Take an app, ANY app. Slap a web interface on top of it, and any part of the app that was CPU bound suddenly becomes IO bound. Really?
Dependency injection is a kludge you only need because Java is static and not dynamic.
Dependency injection is about separation of concerns mister, and has very little to nothing to do with typing.
Transactions should be handled by the framework
Which is precisely how it is done in Java, via the very stable and mature Java Transaction API, that one can either use programmatically or declaratively via enterprise bean. Your point again?
the transaction decorators always been misused by overzealous developers creating huge transactions slowing the application down to a crawl.
Maybe you're referring to some home grown 'transaction decorator' as may typically attempted to be made in PHP by programmers who have a basic understanding of stuff, yet overestimate their abilities and think they can just build transparent transactions themselves. I mean, what could possible go wrong, right? If you're referring to the default declarative transaction support in Java EE, then really this is rarely a problem. If you don't know your stuff and simply do too much work in a transactional method, then you're simply doing too much work. That would have been a problem regardless of using a transactional method or not. Like so many other things, it's a professional tool that's utterly simple to use, but you do have to know what you're doing. Just as you should not blindly make each and every method asynchronous or each and every method synchronized etc.
It proves that you are one of those Java only developers too stupid to learn new languages.
I think it actually proves you are someone who jumps a little too fast to a conclusion. For the record, I started programming when I was 6 in C64 BASIC, quickly moved on to assembly, then C on an Amiga and later Apple, C++ on an SGI
Agreed. If you have the second most popular website in the world serving over 400 billion dynamically generated page views per month from a backend of over 30,000 servers, you absolutely do not want to rely on PHP to serve those pages for you.
This is the same old argument over and over again. Facebook and a couple of other large sites building on PHP don't work the way they do because of PHP, but despite being build on PHP. There's a lot of engineering effort put into those sites, with a not unimportant share of that devoted to things having nothing to do with what PHP handles. With such engineering effort being poured in, Facebook could have been developed in assembly or COBOL, neither of which would have been prove that they are inherently suited for such environments.
Also, don't forget that Facebook is migrating to their C++ based hiphop toolchain and have build their own internal framework, a framework that resembles the Java EE stack in a couple of ways and is NOT available to the general public. The kind of PHP that Facebook does is NOT your typical 'phpfreakz' kind of PHP that is most commonly practiced.
I've also personally talked to the lead developer of Hyves -- the Dutch version of Facebook with some 12 million users -- and he said 'PHP is a little shit language' (PHP is een kut taaltje). I understand that out of context this may not mean much, but he did said that. Additionally, Hyves, Tweakers (a Dutch news site) and a couple of other companies I know that use PHP professionally, some of which I know people working there, almost all seem to agree on that it's very difficult to find really skilled PHP programmers. There is an abundance of programmers that are of the Joe's Burgers variety and have hacked on some PHP script, but that's a completely different category really and not at all what a professional organization is looking for.
So, even though a select few companies are using PHP very professionally, the norm in the PHP market is that it's used by people who barely know the difference between a while loop and an if statement, let alone that they know anything at all about data structures, algorithms, or efficiently structuring their code.
Those aren't real problems unless they are actively preventing you from developing your website, which is probably only the case about 2% of the time. The other 98% of the time you never need consider them.
And that's precisely where it all goes wrong. We don't need no education anymore, we don't need no knowledge about CS theory, we don't need no transactions, we don't need no unicode, we don't need no MVC... PHP is so easy... a baby can now program any web site. .... Until it all comes falling down.
It's the typical Visual Basic kind of mindset. A mindset about which you can read everyday on thedailywtf. Sure, idiots can produce crap in any language, but for some reason both PHP and VB seem to produce a disproportionate amount of that.
You sound like you did very well in school, and maybe even graduated at the top of you CS class. You also sound like you may have little real world experience.
I did okay in school and CS went well too, thank you. I'm currently the lead developer of a 12 person strong development team I've worked with for about 7 years. We're building an enterprise application consisting of several 100k LOC and every day have to deal with an infuriating amo
Its perhaps the midset that says you need something more complex and featured to do the tasks that are required that is Java's problem.
I'm sorry, but I think you're making the exact same mistake, but the other way around; thinking that because Joe's Burgers 4 web page website doesn't need transactions and asynchronicity, no application needs it. That's equally false. Quite a lot of (web) applications actually DO need that, and especially parallel and asynchronous execution is going to be a lot more important now that e.g. the top tier of commodity hardware can give you no less than 32 cores, while cheap entry level servers already feature 8 cores. In general you're not going to keep those cores busy just by means of letting each request go to a core. At some point you have to start dividing the work that needs to be done for each request. Java is ready for this, PHP hasn't even started with the absolute basics.
Think about all the web apps you've ever seen. They're not that complex (except the crap one that are), all they need to do is manipulate data via a GUI (ie html page) and shove it into a DB.
For starters, there is a LOT more server side software running in this world than just all those crappy CRUD-style websites. More importantly perhaps, you somehow equate 'advanced' stuff like transactions with complexity. But nothing could be further from the truth. Do you know what it takes in Java to make the methods of a class transactional? 1 annotation. You annotate the class with @Stateless, and its methods are transactional. Now you tell me, where is the complexity there?
Furthermore, even simple web apps that manipulate data via a GUI could easily benefit from transactions. If I operate a simple web app that lets my customer say order stuff, I won't really be happy if I have an order in my DB, but nobody to bill. Simple does not necessarily needs to be the same as simplistic. I can build a very simple CRUD style app, but still take advantage of parallel execution and transactions in my persistence methods. If a simple page needs to execute 3 distinct queries in order to get the data it needs to display, why not execute those queries in parallel? It's not the complexity you have to be afraid of, just apply the @Asynchronous annotation to a method and it will execute asynchronously, giving you a very simple yet super powerful way to exploit those cores in your machine.
especially when its so difficult to install glassfish/Tomcat/JREs/etc.
Excuse me??? Difficult to install Tomcat??? It's a freaking unzip of the archive you downloaded and it's fully operational. Same goes for Glassfish and JBoss AS. You download something, unzip it, and it's there. Or you use your package manager and execute a simple sudo apt-get install tomcat. If that's already difficult for you, you probably shouldn't be in programming really.
Don't knock those PHP apps, they're doing stuff right - despite being written in PHP! Look to them to see where your Java apps are going wrong.
My Java apps are not going wrong at all. They're humming along nicely thank you. Now have you ever tried to maintain a PHP app of any non trivial size? I mean, have you really had to? If you had, you'd known about the typical unreadable spaghetti mess that most PHP code so quickly deteriorates to. People may occasionally curse at Java's request life-cycle, backing beans and enterprise beans, but at least my view code, validators, converters, view logic and business logic are neatly in a default location. With PHP, the sky is the limit. It's basically an assembly kind of web language. There is no pre-defined structure, no guide lines, no nothing. Want to dump that critical business logic between the tr and td tag in your view code? PHP happily lets you and worse of all, your peers and the whole community even seem to push you in doing that, or at the very least turn a blind eye or just simply don't care.
If that's the kind of community you want to live in, have fun! But it's not my kind of fun.
Believe it or not, but the latest is that they're actually going to release it this year. Not that there's a JSR yet, but don't let that destroy our hopes ;)
And guess what, in C#, C++, Python, Ruby, Javascript, Haskell, Ocaml etc. you do _not_ need an interface here. Using an interface in this case is just wrong, necessary in Java, but essentially wrong.
It's true that Java doesn't has a direct syntax to do that, which indeed may be a shame. But it's also not absolutely necessary. In the UI layer for example and increasingly in other parts of the code, Java uses an expression language (typically abbreviated as EL).
With EL in Java, I basically do precisely that. E.g.
T getFoo() { return foo; }
And then in the view definition e.g.
<h:outputText value="#{myBean.foo.some_call()}" />
Because of the usefulness of this, there are various efforts going on to support EL in more parts of Java than just the UI.
Then again, Java generics are an ugly hack that applies unnecessary type erasure
Sadly this is true, and an unfortunate consequence from the fact that Java added generic support relatively late in its life cycle. This opens the door to some very awkward corner cases.
That said, the benefits of such a sub-optimal generics implementation for me still far outweigh the disadvantage of not having any generics at all.
Also, don't forget that C++ templates not only are a whole different beast, but they actually have issues too. Not in the least that they function more or less as type factories, that produce different types for a different T, that are in no way related to each other. Maybe the situation has improved lately, but I remember that the compiler would generate a complete new list definition for each T I used it for. Ouch!
I've seen buggy code come from well dress nice looking people who just didn't know what the hell they're doing. I've seen great code come from long haired weirdo's who are thoughtful and would be extremely offended if you called them an "engineer".
Sure, and I've seen long haired tattooed weirdos not knowing the first thing about correctness, stability or consistency of their code, and where basically every other class of theirs has a different layout and does similar things in a different way. You know, the kind of code where they store an image in the root folder as /tmp.png with the excuse that 'it's very unlikely that 2 people upload an image exactly at the same time'. Yes, I've heard those 'cool kids' uttering stuff like that.
Just because you are a 'cool kid' does not necessarily make you an intelligent, well thinking developer.
The point being, trying to find some set of outward properties for good software developers doesn't really work. You have to be smart, but even smart doesn't make a good developer. You have to be smart enough to know you're dumb (an exceedingly important quality).
Exactly ;)