Sadly, the sticker price of an Audi A8 4.2 TDI will buy you a colossal SUV and enough fuel that you have to drive 300,000 miles before the A8 is the cheaper option. That's not a useful sales pitch for most Americans.
http://www.ford.co.uk/Cars/Galaxy/SafetyandSecurity - the descriptive text says two rows of seats are covered by side curtain airbags. Since I don't consider the two children I seat in the third row of my present vehicles to be expendable, that eliminates the Galaxy from hypothetical consideration. (In the US market it rules out the Subaru Tribeca and Kia Sorento, among other vehicles.) Otherwise it's an impressive vehicle.
I don't see how desire to survive an auto accident is morally repugnant. The attitude, "I drive a big SUV so I can crush other motorists for fun" is morally repugnant. The attitude, "I drive a big SUV so I can send text messages and watch movies on my laptop while I drive, under the assumption that anything I hit by accident will not cause me injury" is morally repugnant. Desire for survival is simply normal.
And CAFE did push the US automotive market towards large SUVs. Compared to a Chevy Tahoe (or Nissan Armada, or Ford Expedition, or Toyota Sequoia, or Mercedes GL450), a large station wagon with 7-passenger seating and a powerful engine is more spacious, handles better because of the lower center of gravity, is easier to enter and exit, burns less fuel, is less prone to a rollover in collision, and is faster. But CAFE made it so that producing a station wagon that meets those requirements was very expensive for the automakers, while producing the SUVs was not.
However, that doesn't mean CAFE is inherently broken, just that the specific implementation was flawed and needs correction. In America, conservative = "all government intervention is inherently broken"; liberal = "some specific government interventions are broken". (I like my police, courts, FDA, FCC, fire department, EPA, FBI, Navy, Air Force, Army, Marines, Dept of Treasury, and teachers just fine... but somehow many Americans think that anything the government does is fucked up.)
4.2 liter V8, all wheel drive, and > 30 mpg US? Outside of the fuel economy that sounds like an Audi, but no Audi sold in the US with a V8 engine gets fuel economy that good.
And what true 7-seater do you have that does better than 40 mpg? The largest non-commercial passenger vehicles from Europe sold in the US would be the Mercedes R-class and Audi Q7, and even with little diesel 6-cylinder engines their fuel economy ratings are 18/24 and 17/25, respectively - and their third row seats aren't that comfortable. Contrast them to a Ford Flex - more room in all three rows, mileage 17/24 on gasoline, and half the price. Or even better, a Toyota Sienna or Honda Odyssey - gobs more room, mileage 18/24 or 18/27 on gasoline, and half the price.
The Flex, Sienna, or Odyssey are not as classy as their upper crust competition and do not drive as well, but for more space and keeping $30,000 in my pocket, I know what I would choose every time.
New end user features in software products can be demonstrated to managers and people outside the company immediately. Security protection against exploits can only be demonstrated to managers and people outside the company if the exploit has already been used. So often it's hard to sell time and resources spent on security concerns to the people holding the purse strings for the IT department.
Also, many small companies with proprietary software think they can get away with low emphasis on security because it's unlikely an outsider will take the time to attack them. At least, that's my experience from working at small firms.
I think it's even more optimistic than your view. Once it's good enough for my needs, I can in good faith promote it to more people. Maybe 1 in 5 of the people that try it stick with it, and 1 in 50 of those become a contributor. But they do become a contributor, which makes it better. Then more people can promote it, and more people try it, and more become contributors, and the cycle continues and open source keeps getting better and easier to promote and justify.
If any open source project brings completely newbies into the open source world, at least a few of those new end users will eventually become contributors, and that helps us all out. So any project that does a good job of making things easier for newbies - and that's what Ubuntu tries to be - is ultimately a huge long term benefit to open source as a whole. I might prefer Debian or Fedora, and I had high hopes for Foresight because I like conary, but I have nothing against Ubuntu.
So how did you learn your particular skills? I've been forced to develop some small proficiency with database queries and stored procedures because I work at a small company and if I couldn't fix the problem, it did not get fixed. I used a combination of information I got from web searches and trial and error, and while my latest solutions are better than the earlier ones, I suspect a skilled database user would still run screaming from either.
Are there books you read? Classes you took? Certifications?
I am not sure I follow what you mean. I assume you do not mean database connection pooling - we use that already, establishing 5-50 database connections and re-using them for database access so that time is not wasted opening and closing connections. Our old hand-rolled code that would open and close a connection with every database query was definitely 20 or more times slower than using a connection pool.
We also use Hibernate, the popular Java persistence layer. The learning curve is a pain and arguably not worth the effort, but it automatically batches all of your updates and inserts for you unless you explicitly call an API to make them happen one at a time. It does not batch selects because, of course, in many cases your code branches based upon the result of a select. I suppose I could redesign pieces of the application to pull everything I could conceivably need with the initial set of queries, so that no matter what branch was taken, subsequent selects were unnecessary.
Do you mean batching your selects for different client requests? I am assuming you can only batch your selects like that by either grouping queries that each hit the same table or view or stored procedure, or else you do not group queries and instead convert each query so that it casts each column result as a string, union the queries together, and then once you get your results back from the database you convert them from strings back to the expected data type. I guess that could be faster, I never tried it.
Most of our slowest stuff is just pulling information from many different tables. Even with proper indexes it's slow. When it becomes prohibitively slow (e.g. queries for displaying the next page consistently take a few seconds or more) we cache the query results in a view table and draw from that. It adds extra work, because now every time we update the source data we have to update the view table row. But the page response goes back into the sub 100 ms range.
Thanks for the education. (That was not sarcasm, I am serious.)
Then please permit me to revise my argument. While it's possible to get ACID with any data store solution if you implement it correctly, the advantage of a traditional RDBMS is that you get ACID right out of the box. You can still screw it up with poorly considered SQL statements, but I would guess that time to develop is a lot faster than building a full scalable NoSQL solution with ACID.
Maybe I'm wrong. I'm just looking at this from the very small company where I work. If we ever have a massive growth in product use - which, of course, is the ultimate goal - we will have to totally rewrite our persistence engine because with thousands of concurrent users Postgres (or any RDBMS) won't scale. But the company has been around for more than ten years, and with our current customer volume it works fine. If user volume increases by a factor of ten or more we can move from running Postgres on regular 7200 RPM SATA drives in a RAID 1 configuration to something like SAS on 10000 or 15000 RPM drives in RAID 5. It's only at some point beyond that threshold where we'll have problems. So moving to NoSQL now might be a fantastic move in terms of planning for the ideal future, but for the immediate present it will take our tiny development team away from implementing the features that might get us the big sales we want. And I suspect similar planning is the reason so many other companies use a regular RDBMS instead of NoSQL or a hand-rolled solution.
I didn't write the parent post, but as someone who just passed five years as a Java developer:
1. No tuples. If I have a function returning heterogeneous data, I either need to use global variables (yuck), put them into an array or collection of Objects and then type check them before pulling them out (yuck), or else create a class just to hold a few bits of data (yuck).
2. No multi-line strings. I know the feature can be abused, but I hate having to externalize strings like crazy or else do "something" + "something else" + "another thing" all over the source code.
3. No features like Ruby mixins or Scala traits, which are basically like an interface plus an implementation. If I have ten classes that each inherit from different parents and all implement a common interface, I have to put all of the interface methods into each class or compose in some class that handles the interface and then manually type in the delegation.
4. Totally inconsistent standard library APIs, with a host of deprecated stuff (like in Date) and places that use size or length. Arrays use "length", Collections use "size()", Strings use "length()". You would think, considering Java code conventions, that all three would use "getLength()".
5. Untyped collections. You can use generics, but then you only get compile-time checking. Better than nothing, but not exactly good. You can easily write your own implementation of the standard collections that do type-checking, but then you lost compatibility with some of the existing APIs and third party libraries. (e.g. Hibernate likes to manage its own collections internally and you have problems if you mess with them in some ways.)
6. You can't subclass classes in the standard library. I would like to add some convenience methods to String like a String that sorts in a case insensitive way or ArrayList so that it splits the contents into sets of arrays of a length I specify, and I have to put them into separate classes.
7. The inclusion of primitives and Objects might make sense from a performance perspective, but it makes tackling certain problems with the Reflection API and code generation much more difficult.
8. The Reflection API is awkward. Passing around methods and especially their parameters for invoking is extremely verbose.
9. Our code base has literally more than 10% of the lines of code wasted on the damn "getFoo()" and "setFoo(Type foo)" nonsense. In most of the cases, we do not override the default behavior with specific syntax. Considering how universal this convention is, a simpler means of expressing it should exist. I owe the Eclipse developers that created the Java "generate getters/setters" feature a beer - but using it five times a day to generate 50 lines of boilerplate code is absurd.
10. When I daisy-chain a series of method invocations, I should have some way to exit gracefully without throwing a null pointer exception, like a magic method stopIfNull(Object obj), where obj is returned if something in the chain is null. Object bar = object.stopIfNull(defaultResponse).getThis().getThat().getTheOther().getWhatever(). Instead, all over the code base we have if (object != null && object.getThis() != null && object.getThis().getThat() != null && object.getThis().getThat().getTheOther() != null && object.getThis().getThat().getTheOther().getWhatever() != null) bar = object.getThis().getThat().getTheOther().getWhatever(); else bar = defaultResponse;.
11. Starting a Java application should not involve starting the whole JVM and loading everything. As other people mentioned above, this was a design feature for Sun - you start the whole JVM with the free Java Runtime Environment, but if you want to use only what you care about with much lower resource requirements and faster start times, then you have to buy the Java Micro Edition. It sucks for end users, and if the open source Java world doesn't get this feature I hope Java is overcome by other similar languages that hav
I'm not really knowledgeable about map-reduce, but I think ACID (atomicity, consistency, isolation, durability) still make relational databases very useful. map-reduce dramatically speeds pulling data out of distributed data stores, but doesn't help with your data consistency - and for a very large class of applications, you can't sacrifice consistency for speed.
But in general, I agree with your point. Speed matters, and while Java runs pretty well after startup and after the JIT compiler has had time to optimize the code, there are huge classes of applications where the JVM startup and slow initial execution really hurt the end user experience.
Explicit memory management and use of pointer arithmetic add more lines of code and more possibility for error. Experienced, skilled C developers with a good set of build tools, automated testing, code reviews, and manual testing can solve a very large portion of those problems.
But no matter how you slice it, it slows down development speed. In many cases, the trade off is worthwhile. With embedded devices, cheap laptops, cell phones, and so forth, the developer can't afford to sacrifice a performance factor of 10 - let alone 20, 50, or 300 - to go from C to an easier language.
But in other circumstances, like web applications and desktop applications, the developer productivity you get from automatic memory management and removing pointer arithmetic is worth the performance loss. I work on a Java web app backed up by Postgres, a fantastic open source database written in C and C++. My Java code is never, ever the performance bottleneck. The bottleneck is Postgres reading data from the hard drives. So instead of using 30% of the processor while my application is running, written in C it might use 10%, or even 3%, or maybe 1% - but I'd still be working on features in C that I finished months ago in Java. Even if you're a genius C programmer and can develop C apps as fast or faster than I can develop equivalent (but slower) Java apps, if you were just as skilled in Java you would be even faster.
Now, if you want to make a more valid argument against Java, I think you need to compare it to other languages that also have automatic memory management and lack pointer arithmetic, and so also speed up developer productivity, but still accomplish the same kinds of task that Java accomplishes much better. For environments where developer productivity outweighs raw performance, arguably Ruby, Perl, Python, and PHP are all superior to Java. You lose static typing, but your developer speed is so substantially improved you can compensate with additional unit testing and still outpace typical Java development speeds.
I don't think any of the features in Perl 6 are new really. But I think it's more reasonable to argue that no other single programming language has all of Perl 6's features or even most of them.
I work in Java web development and have toyed with Perl, PHP, and Ruby. I have another guess as to why the interviews are different.
Java is a very verbose language and of course it has a compilation step from source code to the Java Virtual Machine byte code. If you manage the configuration of your Java library inside Java code, either in production or during development, it is a real hassle. In most cases when you have to modify the code - possibly a lot for a relatively small change - you have to recompile it, and restart your application or at least reload your application on the application server. To get around this language verbosity, lots of Java toolkits put configuration data in XML files and code annotations. Or in the case of JSP, they created a syntactically different markup language instead of using raw Java for displaying data in the page. For build tools, the popular ones like Ant and Maven also have their own XML syntax. Of course, once you're using XML and annotations and JSTL in your JSP you lose the use of a lot of the code-completion and method lookup tools that make developing code in plain Java easy. And the different Java libraries and frameworks don't use uniform configuration conventions or markup language syntax either.
By contrast, at least for web development the Perl, PHP, and Ruby toolkits I've seen manage their configuration in the source code and their build tools and page markup is very similar to the language itself. So if you're working on a Perl web application and you can read Perl, you can pretty quickly get up to speed on the CPAN modules in the application. If you're working on Ruby and you are familiar with Ruby, you can pretty quickly get up to speed on ActiveRecord or whatever. In many cases changes to the configuration are detected immediately and applied automatically. Even if they aren't, restarting your application is fast because there is no intermediate compilation step.
So I presume that an interviewer hiring a candidate for Ruby, PHP, Perl, or Python would focus most on general knowledge and expertise with the language itself. If you know the language well, learning a toolkit or page markup language or build tool or whatever is straightforward. By contrast, in the Java world high skill with Java itself does not automatically translate to expertise with Ant, Maven, JSP, Spring, Hibernate, JPA, Struts, Tapestry, Wicket, JSF, etc.... I inherited a Hibernate heavy application when I got my first Java job. Going from C++ to Java took me a few weeks. Learning Hibernate and how to configure it properly took me a lot longer.
The US gets half its electricity from coal and burns more than 2 trillion pounds of coal per year. We can store all of the nuclear waste we make for the next millennium in the space we clear mining coal in one year. Relatively speaking, the environmental damage of the nuclear waste is smaller.
Once you go from photovoltaic to solar thermal, you have to add the capacity to store heat in your heat reservoir and extract it. That increases costs significantly and blows cost parity with nuclear to hell. Also, the article says While the study includes subsidies for both solar and nuclear power, it estimates that if subsidies were removed from solar power, the crossover point would be delayed by a maximum of nine years. So they expect additional breakthroughs in the cost of photovoltaics to continue.
Today, anybody and everybody who knows how to write "Hello World" is considered a developer. Thus, the bar for entry, and the bar for success is much lower. Hence, code written today on a "modern" programming language is necessarily less efficient, because the language itself was written for an overall less capable group of people.
Sadly, while the barrier to entry might still be that low in other parts of the world, it's getting higher in the US. That's no problem if you're already experienced. But fresh graduates with computer science degrees and a genuine willingness to learn can't find work because it's cheaper to hire a newbie developer from India or China. I have nothing against people from other countries, but it's frustrating to see fresh graduates who should be writing code only finding work as tech support - if they can find work in IT at all.
I don't know if Perl6 will ever become that popular, but its object model does support encapsulation. It also keeps the Perl5 way of blessing objects with a package if you want to do that.
I think you're speaking more specifically from your own experience. I learned Perl first in a Microsoft environment, then moved to Unix, then started to learn awk, sed, and bash. I don't see how Perl is any worse than they are. Look at these two sed scripts:
sed = filename | sed 'N; s/^//; s/ *\(.\{6,\}\)\n/\1/'
sed -e:a -e '/\\$/N; s/\\\n//; ta'
Is that really any better than a complex line of Perl? sed and awk plus bash are better than Perl when you're already competent with sed, awk, and bash and you're new to Perl. Perl is better when you're competent with Perl and new to sed, awk, and bash. The more interesting question is which you would prefer if you were very competent with both sets of tools. I suspect the answer is usually Perl, but then I'm biased.
Also consider that Perl is more complicated than shell scripts because, of course, it supports a much more rich set of features. In that sense the comparison isn't really fair - Perl syntax would certainly be simpler if it could do far fewer things.
Well, for years a central mantra of the Perl community was "There is more than one way to do it." But Perl6 - which admittedly has been under development for ten years and is supposed to have its first major release from the Rakudo project tomorrow - is a pretty major change from Perl 5 and is supposed to simplify or remove a lot of the features that led to unintentionally obfuscated code.
At this point, I think the baggage associated with the name Perl might be enough to prevent Perl6 from ever becoming a highly popular programming language. But I like a lot of the features. http://perlgeek.de/en/article/5-to-6 I'm just a code-monkey of mediocre skills, but I'm hopeful that the optional strong typing is a really compelling feature for people - you can write strongly typed code that's easier to maintain, test, and refactor for your production applications and you can skip the explicit type signatures for simple scripts you use to manipulate text.
I don't use Groovy, but I understand it was originally built to satisfy your second requirement. It fits in the existing setup of Java servlets and the JVM, but is a scripting language. Using Groovy to cut out the need to recompile and reload your Java web application after most changes often speeds development time dramatically.
Over the past few years a few other methods for loading changes to your Java web app without reloading the entire application have appeared, and I don't see a need for Groovy. But I understand why it was created, and I think its existence probably helped other people to brainstorm cleaner ways to have their applications reload changes more quickly.
I work at a really small company and can have just about any title I want. Thanks for the idea, maybe tomorrow I'll ask the company president if I can be Batman.
Oh, I feel so much better about my messy home now. I'll just tell my mother-in-law the the tufts of dog hair, the dusty shelves, and the trail of mud and pine needles from the kids coming in and out is strictly maintained for the benefit of their health.
You're assuming the person has a choice of a career with good prospects and the time to get an education. That's not always the case.
My mortgage was a problem - but I was married with two kids. So simply selling the house and moving to a smaller place wasn't an easy option. Regardless, my point is that bad luck hits many people, and sometimes no amount of hard work can overcome it. And conversely, there are many, many people who succeed through sheer dumb luck and just a moderate amount of work.
Slashdot Mirror
Sadly, the sticker price of an Audi A8 4.2 TDI will buy you a colossal SUV and enough fuel that you have to drive 300,000 miles before the A8 is the cheaper option. That's not a useful sales pitch for most Americans.
http://www.ford.co.uk/Cars/Galaxy/SafetyandSecurity - the descriptive text says two rows of seats are covered by side curtain airbags. Since I don't consider the two children I seat in the third row of my present vehicles to be expendable, that eliminates the Galaxy from hypothetical consideration. (In the US market it rules out the Subaru Tribeca and Kia Sorento, among other vehicles.) Otherwise it's an impressive vehicle.
I don't see how desire to survive an auto accident is morally repugnant. The attitude, "I drive a big SUV so I can crush other motorists for fun" is morally repugnant. The attitude, "I drive a big SUV so I can send text messages and watch movies on my laptop while I drive, under the assumption that anything I hit by accident will not cause me injury" is morally repugnant. Desire for survival is simply normal.
And CAFE did push the US automotive market towards large SUVs. Compared to a Chevy Tahoe (or Nissan Armada, or Ford Expedition, or Toyota Sequoia, or Mercedes GL450), a large station wagon with 7-passenger seating and a powerful engine is more spacious, handles better because of the lower center of gravity, is easier to enter and exit, burns less fuel, is less prone to a rollover in collision, and is faster. But CAFE made it so that producing a station wagon that meets those requirements was very expensive for the automakers, while producing the SUVs was not.
However, that doesn't mean CAFE is inherently broken, just that the specific implementation was flawed and needs correction. In America, conservative = "all government intervention is inherently broken"; liberal = "some specific government interventions are broken". (I like my police, courts, FDA, FCC, fire department, EPA, FBI, Navy, Air Force, Army, Marines, Dept of Treasury, and teachers just fine... but somehow many Americans think that anything the government does is fucked up.)
4.2 liter V8, all wheel drive, and > 30 mpg US? Outside of the fuel economy that sounds like an Audi, but no Audi sold in the US with a V8 engine gets fuel economy that good. And what true 7-seater do you have that does better than 40 mpg? The largest non-commercial passenger vehicles from Europe sold in the US would be the Mercedes R-class and Audi Q7, and even with little diesel 6-cylinder engines their fuel economy ratings are 18/24 and 17/25, respectively - and their third row seats aren't that comfortable. Contrast them to a Ford Flex - more room in all three rows, mileage 17/24 on gasoline, and half the price. Or even better, a Toyota Sienna or Honda Odyssey - gobs more room, mileage 18/24 or 18/27 on gasoline, and half the price. The Flex, Sienna, or Odyssey are not as classy as their upper crust competition and do not drive as well, but for more space and keeping $30,000 in my pocket, I know what I would choose every time.
New end user features in software products can be demonstrated to managers and people outside the company immediately. Security protection against exploits can only be demonstrated to managers and people outside the company if the exploit has already been used. So often it's hard to sell time and resources spent on security concerns to the people holding the purse strings for the IT department.
Also, many small companies with proprietary software think they can get away with low emphasis on security because it's unlikely an outsider will take the time to attack them. At least, that's my experience from working at small firms.
Nice distillation of the situation.
But of course, if we couldn't sit around and whine about stuff all that would be left of the internet is pornography.
I think it's even more optimistic than your view. Once it's good enough for my needs, I can in good faith promote it to more people. Maybe 1 in 5 of the people that try it stick with it, and 1 in 50 of those become a contributor. But they do become a contributor, which makes it better. Then more people can promote it, and more people try it, and more become contributors, and the cycle continues and open source keeps getting better and easier to promote and justify.
If any open source project brings completely newbies into the open source world, at least a few of those new end users will eventually become contributors, and that helps us all out. So any project that does a good job of making things easier for newbies - and that's what Ubuntu tries to be - is ultimately a huge long term benefit to open source as a whole. I might prefer Debian or Fedora, and I had high hopes for Foresight because I like conary, but I have nothing against Ubuntu.
So how did you learn your particular skills? I've been forced to develop some small proficiency with database queries and stored procedures because I work at a small company and if I couldn't fix the problem, it did not get fixed. I used a combination of information I got from web searches and trial and error, and while my latest solutions are better than the earlier ones, I suspect a skilled database user would still run screaming from either.
Are there books you read? Classes you took? Certifications?
I am not sure I follow what you mean. I assume you do not mean database connection pooling - we use that already, establishing 5-50 database connections and re-using them for database access so that time is not wasted opening and closing connections. Our old hand-rolled code that would open and close a connection with every database query was definitely 20 or more times slower than using a connection pool.
We also use Hibernate, the popular Java persistence layer. The learning curve is a pain and arguably not worth the effort, but it automatically batches all of your updates and inserts for you unless you explicitly call an API to make them happen one at a time. It does not batch selects because, of course, in many cases your code branches based upon the result of a select. I suppose I could redesign pieces of the application to pull everything I could conceivably need with the initial set of queries, so that no matter what branch was taken, subsequent selects were unnecessary.
Do you mean batching your selects for different client requests? I am assuming you can only batch your selects like that by either grouping queries that each hit the same table or view or stored procedure, or else you do not group queries and instead convert each query so that it casts each column result as a string, union the queries together, and then once you get your results back from the database you convert them from strings back to the expected data type. I guess that could be faster, I never tried it.
Most of our slowest stuff is just pulling information from many different tables. Even with proper indexes it's slow. When it becomes prohibitively slow (e.g. queries for displaying the next page consistently take a few seconds or more) we cache the query results in a view table and draw from that. It adds extra work, because now every time we update the source data we have to update the view table row. But the page response goes back into the sub 100 ms range.
Thanks for the education. (That was not sarcasm, I am serious.)
Then please permit me to revise my argument. While it's possible to get ACID with any data store solution if you implement it correctly, the advantage of a traditional RDBMS is that you get ACID right out of the box. You can still screw it up with poorly considered SQL statements, but I would guess that time to develop is a lot faster than building a full scalable NoSQL solution with ACID.
Maybe I'm wrong. I'm just looking at this from the very small company where I work. If we ever have a massive growth in product use - which, of course, is the ultimate goal - we will have to totally rewrite our persistence engine because with thousands of concurrent users Postgres (or any RDBMS) won't scale. But the company has been around for more than ten years, and with our current customer volume it works fine. If user volume increases by a factor of ten or more we can move from running Postgres on regular 7200 RPM SATA drives in a RAID 1 configuration to something like SAS on 10000 or 15000 RPM drives in RAID 5. It's only at some point beyond that threshold where we'll have problems. So moving to NoSQL now might be a fantastic move in terms of planning for the ideal future, but for the immediate present it will take our tiny development team away from implementing the features that might get us the big sales we want. And I suspect similar planning is the reason so many other companies use a regular RDBMS instead of NoSQL or a hand-rolled solution.
I didn't write the parent post, but as someone who just passed five years as a Java developer:
1. No tuples. If I have a function returning heterogeneous data, I either need to use global variables (yuck), put them into an array or collection of Objects and then type check them before pulling them out (yuck), or else create a class just to hold a few bits of data (yuck).
2. No multi-line strings. I know the feature can be abused, but I hate having to externalize strings like crazy or else do "something" + "something else" + "another thing" all over the source code.
3. No features like Ruby mixins or Scala traits, which are basically like an interface plus an implementation. If I have ten classes that each inherit from different parents and all implement a common interface, I have to put all of the interface methods into each class or compose in some class that handles the interface and then manually type in the delegation.
4. Totally inconsistent standard library APIs, with a host of deprecated stuff (like in Date) and places that use size or length. Arrays use "length", Collections use "size()", Strings use "length()". You would think, considering Java code conventions, that all three would use "getLength()".
5. Untyped collections. You can use generics, but then you only get compile-time checking. Better than nothing, but not exactly good. You can easily write your own implementation of the standard collections that do type-checking, but then you lost compatibility with some of the existing APIs and third party libraries. (e.g. Hibernate likes to manage its own collections internally and you have problems if you mess with them in some ways.)
6. You can't subclass classes in the standard library. I would like to add some convenience methods to String like a String that sorts in a case insensitive way or ArrayList so that it splits the contents into sets of arrays of a length I specify, and I have to put them into separate classes.
7. The inclusion of primitives and Objects might make sense from a performance perspective, but it makes tackling certain problems with the Reflection API and code generation much more difficult.
8. The Reflection API is awkward. Passing around methods and especially their parameters for invoking is extremely verbose.
9. Our code base has literally more than 10% of the lines of code wasted on the damn "getFoo()" and "setFoo(Type foo)" nonsense. In most of the cases, we do not override the default behavior with specific syntax. Considering how universal this convention is, a simpler means of expressing it should exist. I owe the Eclipse developers that created the Java "generate getters/setters" feature a beer - but using it five times a day to generate 50 lines of boilerplate code is absurd.
10. When I daisy-chain a series of method invocations, I should have some way to exit gracefully without throwing a null pointer exception, like a magic method stopIfNull(Object obj), where obj is returned if something in the chain is null. Object bar = object.stopIfNull(defaultResponse).getThis().getThat().getTheOther().getWhatever(). Instead, all over the code base we have if (object != null && object.getThis() != null && object.getThis().getThat() != null && object.getThis().getThat().getTheOther() != null && object.getThis().getThat().getTheOther().getWhatever() != null) bar = object.getThis().getThat().getTheOther().getWhatever(); else bar = defaultResponse;.
11. Starting a Java application should not involve starting the whole JVM and loading everything. As other people mentioned above, this was a design feature for Sun - you start the whole JVM with the free Java Runtime Environment, but if you want to use only what you care about with much lower resource requirements and faster start times, then you have to buy the Java Micro Edition. It sucks for end users, and if the open source Java world doesn't get this feature I hope Java is overcome by other similar languages that hav
I'm not really knowledgeable about map-reduce, but I think ACID (atomicity, consistency, isolation, durability) still make relational databases very useful. map-reduce dramatically speeds pulling data out of distributed data stores, but doesn't help with your data consistency - and for a very large class of applications, you can't sacrifice consistency for speed.
But in general, I agree with your point. Speed matters, and while Java runs pretty well after startup and after the JIT compiler has had time to optimize the code, there are huge classes of applications where the JVM startup and slow initial execution really hurt the end user experience.
Explicit memory management and use of pointer arithmetic add more lines of code and more possibility for error. Experienced, skilled C developers with a good set of build tools, automated testing, code reviews, and manual testing can solve a very large portion of those problems.
But no matter how you slice it, it slows down development speed. In many cases, the trade off is worthwhile. With embedded devices, cheap laptops, cell phones, and so forth, the developer can't afford to sacrifice a performance factor of 10 - let alone 20, 50, or 300 - to go from C to an easier language.
But in other circumstances, like web applications and desktop applications, the developer productivity you get from automatic memory management and removing pointer arithmetic is worth the performance loss. I work on a Java web app backed up by Postgres, a fantastic open source database written in C and C++. My Java code is never, ever the performance bottleneck. The bottleneck is Postgres reading data from the hard drives. So instead of using 30% of the processor while my application is running, written in C it might use 10%, or even 3%, or maybe 1% - but I'd still be working on features in C that I finished months ago in Java. Even if you're a genius C programmer and can develop C apps as fast or faster than I can develop equivalent (but slower) Java apps, if you were just as skilled in Java you would be even faster.
Now, if you want to make a more valid argument against Java, I think you need to compare it to other languages that also have automatic memory management and lack pointer arithmetic, and so also speed up developer productivity, but still accomplish the same kinds of task that Java accomplishes much better. For environments where developer productivity outweighs raw performance, arguably Ruby, Perl, Python, and PHP are all superior to Java. You lose static typing, but your developer speed is so substantially improved you can compensate with additional unit testing and still outpace typical Java development speeds.
I don't think any of the features in Perl 6 are new really. But I think it's more reasonable to argue that no other single programming language has all of Perl 6's features or even most of them.
I work in Java web development and have toyed with Perl, PHP, and Ruby. I have another guess as to why the interviews are different.
Java is a very verbose language and of course it has a compilation step from source code to the Java Virtual Machine byte code. If you manage the configuration of your Java library inside Java code, either in production or during development, it is a real hassle. In most cases when you have to modify the code - possibly a lot for a relatively small change - you have to recompile it, and restart your application or at least reload your application on the application server. To get around this language verbosity, lots of Java toolkits put configuration data in XML files and code annotations. Or in the case of JSP, they created a syntactically different markup language instead of using raw Java for displaying data in the page. For build tools, the popular ones like Ant and Maven also have their own XML syntax. Of course, once you're using XML and annotations and JSTL in your JSP you lose the use of a lot of the code-completion and method lookup tools that make developing code in plain Java easy. And the different Java libraries and frameworks don't use uniform configuration conventions or markup language syntax either.
By contrast, at least for web development the Perl, PHP, and Ruby toolkits I've seen manage their configuration in the source code and their build tools and page markup is very similar to the language itself. So if you're working on a Perl web application and you can read Perl, you can pretty quickly get up to speed on the CPAN modules in the application. If you're working on Ruby and you are familiar with Ruby, you can pretty quickly get up to speed on ActiveRecord or whatever. In many cases changes to the configuration are detected immediately and applied automatically. Even if they aren't, restarting your application is fast because there is no intermediate compilation step.
So I presume that an interviewer hiring a candidate for Ruby, PHP, Perl, or Python would focus most on general knowledge and expertise with the language itself. If you know the language well, learning a toolkit or page markup language or build tool or whatever is straightforward. By contrast, in the Java world high skill with Java itself does not automatically translate to expertise with Ant, Maven, JSP, Spring, Hibernate, JPA, Struts, Tapestry, Wicket, JSF, etc.... I inherited a Hibernate heavy application when I got my first Java job. Going from C++ to Java took me a few weeks. Learning Hibernate and how to configure it properly took me a lot longer.
The US gets half its electricity from coal and burns more than 2 trillion pounds of coal per year. We can store all of the nuclear waste we make for the next millennium in the space we clear mining coal in one year. Relatively speaking, the environmental damage of the nuclear waste is smaller.
Once you go from photovoltaic to solar thermal, you have to add the capacity to store heat in your heat reservoir and extract it. That increases costs significantly and blows cost parity with nuclear to hell. Also, the article says While the study includes subsidies for both solar and nuclear power, it estimates that if subsidies were removed from solar power, the crossover point would be delayed by a maximum of nine years. So they expect additional breakthroughs in the cost of photovoltaics to continue.
Today, anybody and everybody who knows how to write "Hello World" is considered a developer. Thus, the bar for entry, and the bar for success is much lower. Hence, code written today on a "modern" programming language is necessarily less efficient, because the language itself was written for an overall less capable group of people.
Sadly, while the barrier to entry might still be that low in other parts of the world, it's getting higher in the US. That's no problem if you're already experienced. But fresh graduates with computer science degrees and a genuine willingness to learn can't find work because it's cheaper to hire a newbie developer from India or China. I have nothing against people from other countries, but it's frustrating to see fresh graduates who should be writing code only finding work as tech support - if they can find work in IT at all.
I don't know if Perl6 will ever become that popular, but its object model does support encapsulation. It also keeps the Perl5 way of blessing objects with a package if you want to do that.
I think you're speaking more specifically from your own experience. I learned Perl first in a Microsoft environment, then moved to Unix, then started to learn awk, sed, and bash. I don't see how Perl is any worse than they are. Look at these two sed scripts: /; s/ *\(.\{6,\}\)\n/\1 /' :a -e '/\\$/N; s/\\\n//; ta'
sed = filename | sed 'N; s/^/
sed -e
Is that really any better than a complex line of Perl? sed and awk plus bash are better than Perl when you're already competent with sed, awk, and bash and you're new to Perl. Perl is better when you're competent with Perl and new to sed, awk, and bash. The more interesting question is which you would prefer if you were very competent with both sets of tools. I suspect the answer is usually Perl, but then I'm biased.
Also consider that Perl is more complicated than shell scripts because, of course, it supports a much more rich set of features. In that sense the comparison isn't really fair - Perl syntax would certainly be simpler if it could do far fewer things.
Well, for years a central mantra of the Perl community was "There is more than one way to do it." But Perl6 - which admittedly has been under development for ten years and is supposed to have its first major release from the Rakudo project tomorrow - is a pretty major change from Perl 5 and is supposed to simplify or remove a lot of the features that led to unintentionally obfuscated code.
At this point, I think the baggage associated with the name Perl might be enough to prevent Perl6 from ever becoming a highly popular programming language. But I like a lot of the features. http://perlgeek.de/en/article/5-to-6 I'm just a code-monkey of mediocre skills, but I'm hopeful that the optional strong typing is a really compelling feature for people - you can write strongly typed code that's easier to maintain, test, and refactor for your production applications and you can skip the explicit type signatures for simple scripts you use to manipulate text.
I don't use Groovy, but I understand it was originally built to satisfy your second requirement. It fits in the existing setup of Java servlets and the JVM, but is a scripting language. Using Groovy to cut out the need to recompile and reload your Java web application after most changes often speeds development time dramatically.
Over the past few years a few other methods for loading changes to your Java web app without reloading the entire application have appeared, and I don't see a need for Groovy. But I understand why it was created, and I think its existence probably helped other people to brainstorm cleaner ways to have their applications reload changes more quickly.
Knowing how to refactor a large production database and getting permission and the resources you need to pull it off are two different things.
I work at a really small company and can have just about any title I want. Thanks for the idea, maybe tomorrow I'll ask the company president if I can be Batman.
Oh, I feel so much better about my messy home now. I'll just tell my mother-in-law the the tufts of dog hair, the dusty shelves, and the trail of mud and pine needles from the kids coming in and out is strictly maintained for the benefit of their health.
You're assuming the person has a choice of a career with good prospects and the time to get an education. That's not always the case.
My mortgage was a problem - but I was married with two kids. So simply selling the house and moving to a smaller place wasn't an easy option. Regardless, my point is that bad luck hits many people, and sometimes no amount of hard work can overcome it. And conversely, there are many, many people who succeed through sheer dumb luck and just a moderate amount of work.