Hate Java? You’re fighting the wrong battle.
javacodegeeks.com
javacodegeeks.com
- the usage of XML (or now: annotations) to configure all of the tiny parameters that nobody really cares about
- a class hierarchy in which you have to jump to 20 levels of inheritance to get to where you want to go
- that a lot of Java developers aren't able to compile their application outside of Eclipse
- that people build in "flexibility" in form of factory methods but at the same time only have the factory only build the same thing over and over again
- that setting up java projects is usually an unpleasant experience with way to much work if you only want the basic functionality because there are no sane defaults
- that there is no proper package management for libraries (similar to something like 'gems' in Ruby)
- that all of the concepts that the language is missing was 'patched' in using reflection, injection and annotations
- that the language just seems stuck (for how long did the Java community talk about Lambdas by now?)
- that most Java libraries don't seem to be able to provide a simple example (compare to ruby, examples on the front page: nokogiri.org, sinatrarb.com)
As for your points in here. Most of them I can respond with "don't do that".
I'm not very familiar with the others, but Lucene is really an example of great software. In a few lines, it makes you feel as if you can build a Google by yourself !
Hadoop is an abstraction over a distributed file system, that allows programmers to crunch large amounts of data using map reduce.
It leaks in the sense that you have to think about implementation details of the job tracker or you will crash it. That's a leak, right?
The problem is if you are writing Java, you are probably working with people who do do that.
I just feel like there are better choices for most projects.
But there are two things I can't let slide:
1) Maven fixes a lot of the project-setup, build configuration, and package management issues. It's not perfect, but it makes a lot of things much, much easier.
2) "That most Java libraries don't seem to be able to provide a simple example." Oh, please. Sinatra and some of the other gems do have amazing examples. But half of Ruby's stdlib has no documentation at all. Hell, things like rss use so much fanciness that there aren't even methods!
Either you care about the future and prestige of your platform, or you don't (COBOL).
If you do care about the prestige of the JVM, the future is still definitely awesome. Scala, Clojure, JRuby and all of the other wonderful languages provide a common base for interoperability. That's pretty sweet.
Java the language, as a secure place to get a job is entirely separate from that. Making bank (ha) off of other people's past poor technology choices isn't a future for your tools. It may be an economic opportunity, but it's not a future.
And if all you care about is having a job and writing lines of code, sure, legacy code base work is fine. But some of us care about more.
I started my career working on 'serious' software, then switched to web applications for a few years, and have recently settled into building multi-faceted, research-oriented systems -- and throughout the entire experience, I have consistently found myself having to apologize for the hype and hyperbole surrounding the many of the more modern technologies that I've wanted to work with.
Have a look at the HDF5 libraries... notice the Fortran support? That is a Huge positive for me, even though I hope to never write another line of Fortran in my life. Sometimes there is no 'selling' new tech to a CIO; it just needs to both appear and actually be absolutely solid (for lack of a better word).
Incidentally, I don't think this is a poorly titled article at all -- the author was being ironic, and will probably be rewarded with a 10x spike in traffic from people looking for talking points to take to their next Rails meetup... that's actually pretty funny.
Cargo-culting is never a good idea. But to say that new and better techniques have not come out of (or been popularized by) new movements in software and business is simply false.
The stodginess and perhaps arrogance of academic and deeper research posts are just as obnoxious and hobbling as novelty-chasing unprincipled startup entrepreneur.
We should pick technologies because they're the right choice for the tasks we're trying to accomplish. Sometimes that requires reaching for tried and true technologies (POSIX ftw after all), but sometimes new technologies really do change the world, and we should do our best to encourage that.
Lastly, it's really just not true that all press is good press. You can gloss over occasional bad press with a much larger weight of good press, or converting a lot of bad press into good press with a small group of people (Palin's "Lamestream Media"), but bad press is just bad press.
Being known for starting flamewars w/o additional contributions to the community pretty quickly marks you as a troll.
I am genuinely disappointed with the present state of affairs, and therefore more willing to wade through an ocean of arrogance to find some intellectual merit.
There's so much to do...
I've just said that i believe that we should be using technology based on its merits. I think that is a separate issue from either whether new technology is always good/better than existing technologies, or whether we need to continue to support and encourage the development of new technologies (meh to the former, a definite yes to the latter).
Established industries on the other hand, need to get over themselves and actually track how new technologies can change and improve their businesses or fields, and I think that, yes, there's a danger of them getting snookered by glad-handing shysters just looking to sell them the hot new thing, but again, this is why it's so critical to have a solid understanding of technological change.
you don't have to wade through an ocean of crap technologies, if you have more finely honed crap detection skills. For example, Coffeescript is a solid and well thought out technology built on top of existing javascript semantics. I can tell almost immediately that it's a sensible and minimalist technology, developed with solid principles, and robust community support. Technologies like Objective-J/Cappuccino on the other hand, do not give me that sense. Sproutcore, up until recently, also seemed like a bloated technology, with a good core idea, but which had become overgrown and lost in it's subsequent iterations.
I am not a long-time Javascript developer, but, i have tastes and aesthetics about what i think is important in a development platform, and the sorts of qualities good ones should have. And the further I develop my javascript chops, the more confident i feel in my assessment.
Anyway, while your examples are instructive (I hadn't even heard of the latter three), they get right to the heart of my complaint: I simply don't worry about how to write individual web applications (though I wish some people would think about it a bit more... cough - quora - cough).
My immediate response to something like coffeescript, though, is to wonder what about how the grammar is defined. Could they do the same thing with antlr or xtext? are they already? how about python-lepl? and, finally, what are the core heuristics that all developers can take from a discussion of the above? I'm not at all interested in thinking about their 'square' function example - I'm sure it's plenty useful in some context.
Worry about what cognitively-tiny (that's not a pejorative - mk is powerful because it's tiny) framework to adopt, and reinforcement of one's choice through pervasive 'messaging' within the developer community, seem to go hand-in-hand. Conversely, since I don't worry about the former, I don't generally take part in the latter.
...
By the way - all this has started to sound overly stern to me - I'm really just sitting on my porch, doing a little good natured ranting about things I can't control.
Cheers :)
I should note that i think what's being done with Sproutcore now is pretty awesome. People like Yehuda Katz have done a good job of turning Sproutcore into a tech that has a solid conceptual foundation, and is aiming for ease of use for developing non-trivial javascript apps.
So, what do you worry about (and i mean that in a non-stern, genuinely curious way)? Web applications really are going to be the solid basis upon which a lot of future technology is built. A lot of pretty complex technology is going to be written in javascript (or things that compile to javascript). It really is a necessary step to see how to make javascript development more efficient and principled, so that there is a common basis for getting stuff done.
I suppose I do worry about a few detail-ish things: the future of the disco/ddfs project now that Nokia is on the ropes... how to more closely integrate CLIPS rules with redis... if it is ok to let webmachine sit between nginx and an osgi process, or if I need to back-burner erlang for a while...
Don't get me wrong, I've written plenty of JS and expect to write plenty more, with or without node. But I'm also curious if I could ship a native component for chrome that dynamically loads a Xen vm that contains a 'heavy' application, with the UI written in whatever, that renders through an HTML5 canvas (check out the gnome3 html5 demo). I don't worry about it happening though: that's going to take care of itself. I just hope there are no patents or licenses to buy that would prevent me from shipping apps that way.
If it leads you to discover the underlying principles, then it is. This happens often in music.
Just using a NoSQL store, because it's a NoSQL store is a bad idea, and can lead to all sorts of dangerous consequences.
His list of four reasons people hate Java completely misses the point. The real reasons people hate Java are something like this:
1. It's verbose, providing lots of unnecessary opportunities to add bugs, and because it's verbose, reading code written in it is slow, so modifying it is slow. These are constant-factor problems, though, not order-of-growth problems.
2. It's early-bound in some important ways, so you're faced with a constant dilemma between adding even more verbosity, making the code harder to modify, and losing flexibility, making the code harder to modify.
3. Although it's quite CPU-efficient, it's very wasteful of memory. (You'd think a COBOL programmer would appreciate this.)
4. The tooling around the language imposes enormous overhead. The JVM takes a second-plus to start; Eclipse uses hundreds of megabytes of memory, if you can get it to work at all; you usually want to run your servlet container behind a reverse proxy; building and deploying a .war file is just orders of magnitude more pain than hitting "reload" after you update your PHP script.
There's another missing-the-point viewpoint shift here, too. This guy seems to think that the point of programming is to enable big businesses to continue to function, like bookkeeping, factory machinery maintenance, and executive team retreats at fancy hotels. Well, programming does do that. But it's also a medium of expression, and a competitive advantage for companies doing new things.
Bookkeeping relies on arithmetic, and factory machinery maintenance relies on paint, but that doesn't mean that Erdos and Picasso were "fighting the wrong battle" because they failed to apply their talents to helping out poor GM.
Java is mostly-ubiquitous and is "good enough" for a number of common tasks, and has good enough structure for mediocre programmers working on important-but-uninteresting problems. As a result (and the blog author says this), there is enough hate-worthy Java code there, just as there used to be enough hate-worthy C and C++ code around, and there probably is enough hate-worthy COBOL and Ada code around, if you know where to look.
It's worth noting that the relationship between C++ and Java switched around in the last 12 years or so - before, C++ was the method of choice to write segfaulting bug-ridden Windows applications (MFC anyone?), whereas Java was a rather slow (as in, non-JIT-ted) language that was up and coming and was interesting because it combined familiar C-like syntax with garbage collection.
Fast forward, and we have not only smart pointers (which ease many headaches of non-garbage-collected C++) but also template metaprogramming which really took off and makes C++ much more palatable to the one-man-army approach (i.e., one smart guy who does work that would take several mediocre programmers otherwise). Java has also evolved - Java 1.2's List/Map/Set are much nicer than the old collections, and Java 1.5's generics help avoid much of the old ugliness - but it carefully avoids any constructs that would make it more useful for one-man-army stuff - where Rubyists and Pythonistas are monkey-patching metaclass decorators, the Java world has one or two libraries that do bytecode generation to do something useful, but nothing more magic.
People who hate Java are really out against the programmer-as-a-fungible-resource way of living where programming is treated like shoveling dirt instead of a creative activity. Programming is both - perspiration and inspiration - and some people will be allowed to chose their tools (Java or not) whereas other people are not or have to fight for it.
Not using Java. Not hiring people that will only program Java. Not tolerating "enterprise grade design" when a two line Perl script will do the job more quickly and more correctly.
I assume that's where the complaint comes from. The author of the blog post is mad that people hate Java and are using that hate to make themselves better tools that are not Java.
When I actually used Java in one of my first personal projects, i found it very fun to use. But when I had to use it in my first job, my interest and enthusiasm waned.
This association happens because the wrong people are defining which technologies will be used. When a manager makes manager-ish decisions, Java is what you get. Or Windows and .NET.
> I bet if corporations started using Python, more and more people would hate Python
Won't happen because
a) Python is actually good b) The same people who make manager-ish decisions won't pick Python.
> When I actually used Java in one of my first personal projects,
I too had a more optimistic opinion of Java when I started playing with it. But then I remembered how it felt to program with Smalltalk (I learned OOP with it, later played with Actor on Windows). Then I met Python, and Zope and realized web development doesn't need to suck.
The company I work for maintains several Java applications and a couple PHP and Django ones. The difference of productivity from the Java projects and the Django ones is absolutely shocking.
Oracle will.
... for some values of "you", apparently ;) Lucene, Hadoop, Cassandra, Hudson/Jenkins, RapidMiner, GWT and a gazillion other best of breed open source projects have selected Java, for better or for worse.
If I was taking this votes/points/karma thing seriously I would be rather pissed, now I'm just laughing at the rabid fanboyism.
I hate Java, and this is one of the main reasons I also hate Ruby and Python.
The opposite of the Java-bureaucracy is not necessarily "features" that are a few times over too clever for their own good.
If there is only one thing Java ever got right for example is to avoid multiple-inheritance and operator overloading.
Also the Java vs. C++ dichotomy you present is not shared by many Java hatters, just take a look at all the quotes here that mention C++: http://harmful.cat-v.org/software/java
In the enterprise, you need a language that can support - multi-million line code bases - a development team of dozens or even hundreds of programmers - a software project that lasts years - a team that changes over time - a team that isn't just rockstar programmers (try hiring dozens of rockstar programmers at once if you are not google, facebook, and you aren't doing something perceived to be 'sexy')
I think java and C# are the best languages that meet those criteria today (and if you don't want to be married to MS, then you are left with Java).
I think dynamically typed languages are not appropriateness for such a scenario.
However, HN is a startup-oriented site, and those certainly are not the criteria you need to meet in a startup.
Edit: I hate Java as much as the next guy, but this thread is missing the article's interesting point, which is that the real legacy technology is the mainframes which still power the large-scale economy. Shouldn't we consider why? Isn't it meaningful that the technologies we prefer haven't yielded anything capable of disrupting these entrenched systems?
Measuring just one variable in just a few anecdotes is unlikely to give you a representative measure of a language.
COBOL is a language designed in an era where syntax was thought to be the difficult part of programming.
This is a very striking comment and one that reshapes my criticism of languages in general. Often one says that COBOL "feels old" but it's difficult to pinpoint why; I think your comment gets to the heart of the matter and explains why languages such as lisp or smalltalk retain influence today. The problem they attempt to tackle is still difficult in modern programming environments, but the problem COBOL was designed to remedy has paled in comparison. Thus, it's similar to how AOL used to be the main method people used to access the internet -- e-mail, IRC, and the general web was difficult enough for a novice to master that a service like AOL was needed. Now the web has matured enough that the problem AOL was trying to solve has disappeared -- leaving it outdated by substance rather than outdated by style.
Nowadays there are other languages and toolkits out there that bring me better joy on a daily basis. C-based languages are not the issue here (I love Objective-C), it's the frameworks and patterns that soured my interest in Java. IoC, dependency injection, xml config this, facade that - for today's speed of 'innovation' and time to market, the Java universe for development can be too big and slow.
Most of the people I've run into post-'06 don't use Java anymore. These are usually small startups (as I don't do enterprise anymore) and the names that always come out are Python, Php, Ruby/Rails, Obj-C, JS, and even Scala. In my mind this is telling of where things are going, just like the early days of Java when people still used Perl and C++ for web. I think Java's continual evolution (or at least usage of the JVM) into things like Scala and Clojure are good things. But it's glory days being at the forefront of web development are behind it.
Ultimately I think this as fine as every dog has its day. Someone will come up with the next greatest thing that everyone will flock to. But like all the other names I've mentioned, Java will be around in many shapes and forms because, like Cobol, some businesses and users will still need it.
I'm sorry that just don't cut it for me, and I'm capable to dislike both COBOL and Java.
edit: I gave up on the whole thing when I had to use comments to configure part of a build process. (xdoclet & jboss? ... I can't quite remember)
I see the same problems in Ruby sometimes: metaprogramming used without a compelling need. Luckily it isn't as much of a PITA because nobody thinks its OK to program via XML files anymore.
But I think it goes beyond pattern soup, and beyond what's available in the language. It's almost a neurosis specific to the Java ecosystem that every design must be maximally flexible...perhaps to show off how object-oriented the code is? It's like the devs are reluctant to hardcode anything, instead abstracting over every design decision they made. This wishy-washy design is then played up as 'flexibility,' rather than a design failure.
Suppose I'm looking for a JSON serialization library. Do I really need to be able to configure the JSON parser used? What percentage of people need to do that? The people with the thorny problems (such as deserializing 100MB of JSON as fast as possible) probably won't be able to use it due to the scope of their problem. But, the option is there, as it could happen.
I haven't done Java stuff within the past few years, but it would appear they're getting better about it. It seems like it may have taken something like Rails in order to show the world that 'enterprise' is usually a euphemism for 'lacking in taste.'
And you know someone is going to use [awful library] to solve [big problem] and it will "work".
Maybe the reason you hate some feature of a language because you've never been exposed to a problem domain where that feature would be required.
I mean how many of us can honestly say that we are experts in more than one or maybe two domains: i.e. web development, desktop/native apps, embedded systems, systems programming, 3d programming, mainframe programming, massive enterprise team projects, small one-person projects, in-between projects, etc...?
I say he who is versed in all of these cast the first stone... :)
The world doesn't have to be black and white. Why do we geeks try to make everything 0 and 1? The world is not binary. You can "sell out" yourself - work doesn't necessarily make you happy but it may give you means to do something that makes you happy.
I've been working with Java since 1999 and I'm amazed - it won. From applets to EJB hype to Struts and to now Spring and Scala and Android. Game over - they've become a Lingua Franca. There is always room for other players but Java is so firmly entrenched in Fortune 500 code bases it will never ever go away..
But it makes no difference for open source, hence the Linux coders disdain for VM languages, and it makes no sense with Python or Ruby where you interpret the source. And native JIT makes more sense now, the JVM being a bad language to write a JIT compiler for, as it loses a lot of important information.
If you want to run it on anything else, you are pretty much SOL.
This is not what anyone should call portable.
Then, there's the Sun/Oracle thing... While Sun was still pretty respected, being associated with Oracle feels like a wolf trying to befriend a chicken. Especially coming from the open-source perspective, I'd rather not deal with them. If design-by-committee wasn't bad enough, the control of a company like Oracle should set off some alarms...
I like Java and JavaScript, I don't like too much C# and Delphi (maybe because of this that I used those in my worst job ever? ;-)). But I don't think that C# and Delphi are bad programming languages used by idiots.... I don't think so, because I know some super programmers using those languages, and I know also some very bad programmers using for example Ruby. In short good programmer will use any language and will create cool software, bad programmer may use the best language ever and will create something what sucks ;-)
And this that companies decide to stay with Java or even COBOL have sense, to rewrite code from one language to other you need people who knows both languages, and are in those two languages really good.
#Of all the great programmers I can think of, I know of only one who would voluntarily program in Java. And of all the great programmers I can think of who don't work for Sun, on Java, I know of zero. -- Paul Graham
#Java is the most distressing thing to happen to computing since MS-DOS. -- Alan Kay
#Java is, in many ways, C++--. -- Michael Feldman
#C++ is history repeated as tragedy. Java is history repeated as farce. -- Scott McKay
#Arguing that Java is better than C++ is like arguing that grasshoppers taste better than tree bark. -- Thant Tessman
#Like the creators of sitcoms or junk food or package tours, Java's designers were consciously designing a product for people not as smart as them. -- Paul Graham
#There are undoubtedly a lot of very intelligent people writing Java, better programmers than I will ever be. I just wish I knew why. -- Steve Holden
#The more of an IT flavor the job descriptions had, the less dangerous was the company. The safest kind were the ones that wanted Oracle experience. You never had to worry about those. You were also safe if they said they wanted C++ or Java developers. If they wanted Perl or Python programmers, that would be a bit frightening. If I had ever seen a job posting looking for Lisp hackers, I would have been really worried. -- Paul Graham
#In the best possible scenario Java will end up mostly like Eiffel but with extra warts because of insufficiently thoughtful early design. -- Matthew B Kennel
#The only thing going for java is that it's consuming trademark namespace. -- Boyd Roberts
#Java is the SUV of programming tools. A project done in Java will cost 5 times as much, take twice as long, and be harder to maintain than a project done in a scripting language such as PHP or Perl. ... But the programmers and managers using Java will feel good about themselves because they are using a tool that, in theory, has a lot of power for handling problems of tremendous complexity. Just like the suburbanite who drives his SUV to the 7-11 on a paved road but feels good because in theory he could climb a 45-degree dirt slope. -- Greenspun, Philip
#JAVA truly is the great equalizing software. It has reduced all computers to mediocrity and buggyness. - NASA's J-Track web site
#C and Java are different in the non-excitability department, though. With C, you don't get excited about it like you don't get excited about a good vintage wine, but with Java, you don't get excited about it like you don't get excited about taking out the garbage. -- Lamont Cranston (aka Jorden Mauro)
#Java is about as fun as an evening with 300 hornets in a 5m^2 room -- andguent
#If Java had true garbage collection, most programs would delete themselves upon execution. -- Robert Sewell
Java: write once, run away! -- Cinap Lenrek
Java is a DSL to transform big XML documents into long exception stack traces. -- Scott Bellware
#The definition of Hell is working with dates in Java, JDBC, and Oracle. Every single one of them screw it up. – Dick Wall CommunityOne 2007: Lunch with the Java Posse
#Java is like a variant of the game of Tetris in which none of the pieces can fill gaps created by the other pieces, so all you can do is pile them up endlessly. -- Steve Yegge (2007, Codes Worst Enemy)
#Whenever I write code in Java I feel like I'm filling out endless forms in triplicate. -- Joe Marshall (aka jrm)
Some notes: I don't know why PG can't, but I can certainly name a dozen great programmers who mostly work in Java. Greenspun recommends that instead of Java, you use (wait for it...) .NET.
The Dick Wall comment I have no issue with :-)
well they make sense :)
as an aside, I feel old being able to talk about having programmed for years.
my first programming experience was in unstructured BASIC. I think I've managed to reverse the brain damage from that, but I can't be too sure.
The interesting thing about Blub programmers is that they do not know they are Blub programmers.
Even more interesting: Even those who know about the above phenomenon and make meta-comments on it are Blub programmers and do not know that they don't know this. </mega-irony>
But I try to keep up to date with regards to PL technologies, so I think I'm closer to the top of the contemporary Blub ladder, but I guess any Blub programmer might think that!
My Blub is Smalltalk, and I'm proud to claim it as such.
Programming is about the joy of creating: thinking, expressing and sharing of ideas. If your argument in favor of something is, "it's bad, but banks use it", you've missed the point of programming.
No, it means you don't work for that bank.
I've been in the situation several times where technology decisions are made based on brand. The Java solution is the only one evaluated "just because".
I've personally seen a scripting language been thrown out and everything rewritten in Java.
After a couple of years they had to go back to scripting languages for a big part, for productivity. So they would ship sometime... (To minimize embarrassment, they used a different scripting language. [Edit: Yes, the second scripting language have almost as much hype as Java...])
<offtopic> It's been a while since I worked with PHP, but when looking at performance or distributing work I can appreciate the desire to migrate to a different language. I've always seen PHP as more of an over-ambitious template language (even though smarty and so on exist to perform this function on top of PHP). Basically I'm not surprised by your story. </offtopic>
We don't like Java, but the JVM has met our needs pretty well. I was tempted to argue for Clojure, but I'm not sure we could have taken the performance or maintainability hits for discouraging static typing.
(I'm right now relearning css, javascript, dom etc. The present place is getting to be a bit non-challenging and boring. And I promised myself I'd work hard to do interesting things the rest of my life.)
Edit: I might add my 2c. I have no problem with Java, really. It is like a simplified C++. It is just boring.
- Paying with a credit card.
- Going to the emergency room.
- Adjusting your 401k.
- Using your insurance card at the dentist.
- Shopping around for the best car insurance.
- A BNSF train pulling a Union Pacific coal car.
- Transferring money between banks.
- Filling a prescription.
The question to ask is: What are the economic and social forces keeping the COBOL code base alive? Seeking to supplant a long-surviving language in a particular niche without first asking this question is a fool's errand.
Do you want to be the person who volunteers to rewrite those codebases into $HOT_NEW_LANGUAGE (or even $BORING_STABLE_LANGUAGE) and be on the hook for ensuring that your rewrite exactly replicates the behavior of the old system? Introducing bugs--or even inadvertently fixing bugs--during the rewrite is absolutely not allowed.
Let's say, for concreteness, that each one of those tasks above is a multi-million line codebase. Think about what that would cost, both in person-years and in monetary terms. (Sure, you can write 10x less code...but half a million to a million lines of Python is still a lot of Python.) Remember, you probably have to have a fairly exhaustive specification of how the original system worked before you embark on the rewrite; just getting that specification together is likely to be tilting toward person-years of work.
Do you want to be the manager who goes around to talk to all the involved stakeholders and explains to them why this is a worthwhile use of their systems, time, and money? ("We'll have an easier time recruiting people to work on the system," probably doesn't fly; neither does, "$LANGUAGE is cleaner/faster/more readable.") What do you tell them when they ask about possible issues during the transition? And so on and so forth.
Java is a workhorse of a language. It's stable, gets the job done, and is reasonably sane. It's also readable, which in my opinion is one of the most (if not THE most) important traits of a software product. Readability. Simplicity.
The problem I have with Java is that I feel like it never evolved to meet its potential. It feels like C# 1.1 to me.
These days however I think the most interesting programming topic is not Java vs C++ or Java vs C# or any of these tired old debates.
What's most interesting to me is the notion that dynamic languages are somehow more productive or superior to strongly typed ones. It seems to be a commonly held view in the startup scene especially. It just doesn't make sense to me.
The difference is just that it's more likely that I have to use Java at some point, compared to COBOL.
wait.. that's actually kind of a good idea. Raise your hand if you're a COBOL developer. Any young COBOL developers trying to break into the field?
Android is certainly going to help Java remain relevant, but this is another example of how it isn't highly compatible with the entrepreneurial mindset. The Android app ecosystem isn't as good at rewarding independent app developers as the iOS app ecosystem is. So people who, in entrepreneurial fashion, want to be judged by the market, will probably make iOS apps because that's where the money is. I argue that that'll produce a 'brain drain' away from Java - Java will be the language a day job makes you use, and something else will be the language you use for projects that you care about.
The projects that people care about, in the long run, are far higher-quality code than the projects that they only do for a paycheck.
When iPods and iPads are included, iOS greatly surpasses the Android install base. These aren't just phone operating systems; they're mobile device operating systems.
Also a point concerning most language wars is that quite a few are initiated by people with interests on the contender; that is, the language authors, software vendors, etc.
However, I hate many of the Java APIs, specifically most "JEE" crap, such as EJB, JMS, most third party ORMs (Hibernate), most Java "web frameworks" (too numerous to list).
Java IDEs are bloated, slow, and often unstable with extra plugins (Eclipse)
ORMs, i feel, are a misguided adventure, and Java on the desktop (eg IDEs) are a really easy target. That said, a faster disk and gobs of memory make IDEs really fly.
Some snippets:
A 7 seems very close to a 9 or 10, but often a 7 is a local maximum — you can’t get any higher by continuing to follow the same path that got you to that 7 in the first place.
A 7 is pretty good. At this level you feel generally content. It’s OK, fine, acceptable, satisfactory.
What you’ll find when you leave the comfort of your 7 and go chasing after that 10 is that your 7 was never a 7. It was only a 3.
Java is the epitome of "7"-ness. It's a decently powerful language that you can do cool things in if you find a good rock and smash the right things in the right places. As a language, it's mediocre but so much work has been poured into it that nothing is too hard to accomplish in it... then again, very little is easy or fun in the way that Ocaml (once you get it) is easy and fun.
Java appeals to business types because it seems like the low-risk choice. The libraries are going to be there, and even if it's hard to be better than a 7.0 programmer in it, mediocrities can easily get up to 3-4, which is seen as "good enough".
You might be able to go from a 6 to a 7 in a week or a month, perhaps even a day with conscious effort. A few tweaks here and there, and you’ve got it. But to go from a 7 to an 8 might take a year or two. 7 doesn’t always connect with 8. You might have to take a path like 7-6-4-2-3-4-5-6-5-4-6-7-8 to get there.
This is what switching out of the Java paradigm, into Ocaml or Haskell, is like. You have to work hard and learn new things before you get to a level of skill where you can be even a 5, much less an 8 or 9... but it's actually possible in those languages.
If you try to do real, production programs in Haskell or Ocaml, you find that they have a lot of problems too.
I've written some reasonably cool stuff in Haskell (like one of the top tutorials that people use to learn it). My teammate got his Ph.D under Simon Peyton Jones and did his doctoral thesis in Haskell. We were talking one day about what it'd be like to write real production systems in it. His strong opinion (and my weak opinion) was that it'd be hellish, because of certain misfeatures like lazyness or the hacked-up record system. All the people that complain about Java would merely find new things to complain about with Haskell, other ways in which the language prevents them from getting useful work done. Instead of whining about verbosity, they'd whine about space leaks.
I find that people who are a 9 or 10 on the expertise scale usually know Haskell, but they don't program in Haskell. Because the causation works the other way. If you're a good programmer, you'll seek out other languages and learn them, because it'll make you a better programmer. But if you're a great programmer, you'll know when not to use stuff you've just learned, because it'll just make your life harder. Learning Haskell doesn't make you a great programmer, but great programmers have probably learned Haskell at some point in their path to greatness.
What is going to be so hellish? Space leaks? That doesn't seem like the worst thing in the world to me. Lots of scripting languages tend to bloat over time and the usual answer is to kill and restart the process every now and then. Even Apache does this to its children.
If I have to kill some daemons every now and then, but I get the robustness that Haskell seems to offer, it sounds like a great tradeoff to me.
I don't think laziness by default is all that useful in practice, but neither does it seem to be a fatal problem.
I'm not all that impressed with the web platforms for Haskell, but I'm thinking of doing Haskell in the backend, and Python in the frontend.
So... go ahead, pop my bubble; tell me how I'm being stupid...
You really want predictable execution behavior in those systems. You want to be able to look at a graph of runtime parameters - memory usage, or server load, or QPS, or 95th percentile latency - and see that it's stable, and not have surprises like a massive spike that then shows up as user-visible outages. Because getting paged really, really sucks, and losing money because your customers can't access the system sucks even more. "Kill and restart the process every now and then" is not robustness.
If your intention is to play around with some prototypes and see what you can build, Haskell on the backend and Python on the frontend is a fine choice. Your biggest issue (other than the learning curve of Haskell) will be finding libraries that you can leverage, and Haskell has one of the nicest C FFIs out there. Other than that, here're assorted other little annoyances I've run into.
1. Positional data structures (tuples, "naked" [non-record, no accessor] ADTs, functions with long parameter lists) really suck. You will eventually want to stick another bit of data in there, and then you have to update all the usage sites with new pattern bindings. As immature as the record system is, take the time to use it from the beginning; it'll save you pain later on.
This is a very common pattern in C++ as well; many experienced API designers I know will give all their methods the signature of "bool someMethod(const MethodInput& input, MethodOutput* output)", where MethodInput and MethodOutput are structs. At Google, we often use protobufs as the structs; that gives you a bunch of other benefits, as you can instantly print them out for debugging, and you can log them efficiently, and it becomes trivial to turn the API into an RPC service if it outgrows a single process.
2. Don't be afraid to use type inference; oftentimes, the compiler can infer a more general type than you can write down. If you do write down the types, be liberal with your use of type synonyms; you will probably end up changing those types later, and it sucks to have to visit a few dozen functions with a search & replace. "newtype" is very often worth it, if just for the added typechecking.
3. Point-free style is cool, but I've never been able to look at point-free code I wrote a month ago and understand what it was doing. Don't do this outside of very specific cases where the point-free version has some semantic meaning (for example, you're treating a partially-applied function as an object that does something. If you wouldn't define a closure for it in Python or JavaScript, don't make it point-free in Haskell).
4. Haskell module patterns are much more similar to C than C++ or Java. You typically want a clear divide between "data" modules (that define fundamental dataypes) and "code" modules (which define functions and algorithms acting on those datatypes). Trying to use the OOP-style, "one class per file" approach is very frustrating in Haskell.
5. The "mathematician's naming convention" (all single-character variable names, with "s" as a plural to indicate a list) is just as bad an idea in Haskell as it is in C. Go give your variables some meaningful names and ignore all the tutorials that have "xs" and "ps" and "qs".
6. Very often, you'll want to define a monad for your code from the get-go (you can even just typedef the IdentityMonad to start out with) and write your code in a monadic style from the beginning. You will want to add error-handling and probably state and logging at some point in the future. If you start out with a typedef'd monad type, you can just change the typedef to some monad transformer stack as you need to.
However, you're still suggesting that Haskell is only good for prototyping, not for "real apps", which understandably for you are Google-scale apps. There is a very long distance between what Google does and what I need to do, today, and premature scaling is the death of many projects. But let's be ambitious and pretend that one day I will want to operate at that scale. Assuming C++ is out of the running, is there really no alternative to Java?
I've been working on apps in PHP (Flickr, now Wikipedia) and while I admire the language, in the same way I admire how weeds can colonize an area efficiently, I am not going to choose that for a personal project. I agree with your assessments of Python and Ruby, and I'm not sufficiently enamored of any framework in those languages to make it worth the trouble. I can sling Perl as well as anybody (even in a style approaching functional) and it can be very efficient, but it's hard to find collaborators these days.
This seems to leave Erlang, Haskell, Scala, or maybe Node.js + JavaScript.
Scala seems like what an enterprise would choose for its foray into functional programming, and indeed that seems to be the hopes of its creators. While it's a "safe" choice, for Java shops maybe, I fear the massive shear forces between Java's way of thinking and Scala's attempt to paper over all that with functional thinking. Not to mention the complexity of that language. Still, it seems to work for Twitter, FourSquare, et al.
There's nothing wrong with Erlang, and it has its adherents in industry, but the syntax annoys me.
I'm already an expert in JS, and a codebase of a single language has its benefits. The intense competition in the browser to make JS an application language seems to have already vaulted JS performance over other scripting languages and new libraries are being written every day. Still, it just feels odd to write directly to a database or file in JavaScript. And I've gotten myself tangled up in JS' asynchrony a bit too much recently. Maybe that's an irrational prejudice.
I guess this is why I've been looking on Haskell; in part because it offers some hope of really writing a lot less code and having that code be so well-typed, automatically, that it practically writes its own tests (see QuickCheck) or doesn't even need them. It seems like there ought to be some way to get the best of that without needing to shoot yourself in the foot because you suddenly want to log some action and you didn't define some code twenty layers above it as monadic.
There's also nothing wrong with writing your v1 in one language and then rewriting in a different one if you need to scale. You will probably need to do this anyway, even if you start in C++ or Java, because the architecture needed to scale by an order of magnitude is usually very different from the architecture needed to iterate quickly.
There are two types of languages,
the ones everyone complains about,
and the ones nobody uses.
-- Bjarne StroustrupI think things like the record system could be fixed up with simply more eyes on the problem. Lets face it, the Haskell community and contributor base is relatively small. If it had the resources of say C++ or Java behind it - a lot of these small problems could be tackled.
But when it comes down to it these are minor details, not fundamental flaws of the platform such as the ones discussed with Java.
Also I do program solely in Haskell during my free time (ok, maybe some matlab on the side haha). While the learning curve has been incredibly intense - it is so damn rewarding that I keep coming back. The solutions are incredibly generic, elegant, testable, and even quite fast with a little performance optimization work (with experience the amount of effort required for this tends to go way down as with anything). I guess I would rather write the correct code first, and put a little time into optimization than write highly optimized incorrect code and spend a lot of time fixing bugs.
But far and away the largest problem that Haskell goes a long way towards solving is composability. Many may argue this point but I really believe this is the largest challenge we face today in software. So many issues boil down to this. The vast majority of bugs, re-writing, etc... comes from software that was not designed in a composable manner. Because let's face it - with the current tools like Java/C++ it is incredibly hard!
Java, as a language and a platform, is not fundamentally that bad. It was certainly done by very smart people with lots of experience.
It sucks because it has several design decisions embedded into it that were necessary for it to gain broad adoption and yet ultimately pretty annoying in the long run. Take closures, for example. The reason Java doesn't have closures is because it had a design constraint that all heap allocation must be indicated by the "new" keyword (same reason it didn't have autoboxing until Java5, and why classes aren't factory functions they way they are in Python). The reason for that was that at the time, the majority of programmers believed that heap allocation was slow and unpredictable, and in order for a new language to gain adoption, programmers needed to be able to control heap allocation and ensure it was used predictably.
This is actually still true - in domains like avionics and other "hard real time" areas, heap allocation is generally banned because it introduces nondeterminism into a program's run-time characteristics, and even with tuned incremental GCs, Java programs still spend a non-trivial amount of time in the GC. It just doesn't matter all that much, because Java started being used for applications where a few hundred millisecond pause for GC just gets lost in network latency.
Haskell faces a similar uphill battle. In order to get the critical mass of people needed to build out the ecosystem that C++ or Java has, it needs to be useful for the programs that people write today. But in order to do that, it needs to accommodate all these wonky developers with their weird ideas of what's necessary and what's not. Chances are, if it did that, there would be some design choices made that make Haskell nearly as lame as Java. And even if there aren't, and Haskell remains exactly the same as it is today, it'd soon be pushed into domains it wasn't appropriate for, just like Java, and people would be cursing it out for its flaws.
As Simon Peyton Jones says, "Avoid success at all costs."
There's a two-edged sword to every design decision that you make. Yes, Haskell gives you a lot of composability through lazyness, type inference, and nearly everything being first-class. Lazyness grants this through "pay for only what you use" - if a caller never uses the result of a library, the parts of the library's code that generate that result will never be invoked. The flip side of this is that if you suddenly use one more field in a tuple, way down the line in some unrelated portion of the code, you might trigger a very expensive computation. This is unacceptable in many large apps written by multiple people; you shouldn't have to worry that a tiny field reference can bloat the program's memory consumption by orders of magnitude.
(I have example trade-offs for type-inference and first-class everything, as well, but this post is already getting too long, and I wanna go do other things with my Saturday. ;-))
So, popularity requires bad design decisions. Put it bluntly, most programmers are ill-educated. Fine, let's fix that problem, then.
No matter what language you use if you want to use the results you're going to pay the calculation/resource fee. All Haskell (via lazy calculation) is doing is giving you a speed increase when it can tell you aren't using certain results.
In Haskell, every single token might trigger a long computation, so it's very easy to introduce something that wildly changes the performance characteristics of the program.
Honestly I just haven't experienced this very often in Haskell... When I do it is usually a 'doh moment and a simple fix.
Ocaml is an elegant, simple language that is in many ways like a "functional C". You can also write very fast, robust code in it. Haskell is where the next generation of cool language concepts is coming from (like Lisp in the 1960s-80s) but I'd prefer Ocaml for production use.
That said, you'd need to put some resources into rewriting the runtime to make use of multicore. Ocaml is blazingly fast but right now the implementation is single-core only.
I also had issues with the garbage collector traversing arrays of native types which is a complete waste of time, especially when said array is 7GB and immutable.
I don't want to give the wrong impression - ocaml is a fantastic language. It just has some poorly documented rough corners which can bite beginners.
Ocaml's problem, from what I've seen, is that INRIA wants to run a tight ship regarding the design of the language. This makes sense, but it also means a lot of real-world use cases get ignored. For example, my understanding is that priming Ocaml for multicore use would require substantial rewrites that aren't a high priority, given INRIA's desire to maintain it as a "research language".
The 2^22 - 3 array limit (and the corresponding 2^24 - 12 string limit) on a 32-bit machine (it's 2^54 - 3 on a 64-bit system) are examples of this: the language designers simply didn't anticipate that people would be using the language for purposes that require such enormous arrays or strings. These use cases are tremendously important for real-world production use but not terribly interesting from a research perspective.
Do we have to quote cult leaders on Hacker News?
Steve Pavlina is the guy who writes blog posts about winning blackjack through ESP. His wife is a professional psychic. He sells magic CDs for hundreds of dollars that will give you psychic powers when you listen to them in bed.
There's no credibility to be found here.
Yes, he later went seven flavors of kooky... but no amount of kooky retroactively disproves good ideas. That's also a level of discourse which I'd prefer to avoid on HN.
The real question to ask about Steve Pavlina though is whether his blog posts are designed to help YOU make money, or to help HIM make money. He typically doesn't provide objective evidence indicating you will be helped. And if he wanted to, he COULD get this evidence.
So for instance he claims that using various magical powers you can make money. He could invest $50,000 in running scientific trials of these methods and objectively prove to his readers that it works.
THAT would be worthy of Hacker News.
But if Steve Pavlina is fair game to be quoted on HN, I am gonna start quoting Jesus. Cause they have about the same level of credibility.
http://www.sodaware.net/dev/articles/shareware-amateurs-vs-s...
1. If the person is an authority or expert on the topic being discussed. In this case, the person has credibility and it is smart to give them a level of trust.
2. If the person is providing a reference to some objective, public evidence that can be independently evaluated to determine if the statements are valuable.
The post in question did not provide either #1 or #2.
Steve Pavlina is popular because he's a good writer, not because his ideas are supported by evidence or because he has credibility or legitimate authority.
With the general public, all it takes to be influential is good writing. e.g. Jesus Christ is popular.
Hacker News should aim for a higher level of discourse: discourse based on verifiable facts, or based on credible authority. Not sophistry by well-spoken demagogues.
1. There being no evidence provided to support the claims.
2. The author being a well-known cultish demagogue willing to say anything to get your attention.
In order for someone to be useful to you they need to tell the truth and give you accurate information that has been tested and verified.
There are lots of very smart people who it would be a big mistake to listen to. Cult leaders are the perfect example!
It is striking to me how often a world renowned expert, really top-notch in his field, can turn around and say something spectacularly dumb in an area that isn't his field. You'd be surprised how often people just don't know what they don't know, or get emotionally attached to something foolhardy. You get an expert entertainer talking about statecraft or a hard scientist talking about religion or even just a software guy talking about hardware. It can be gobsmacking.
There is a train of thought that tries to classify people into reliable and unreliable -- worth listening to or not. And I think that's a very bad idea. No one is perfectly reliable. No one has a completely rational and educated worldview. No one. I think just about everyone is going to have an opinion about something that I think is monstrously, provably, stupidly wrong.
I think the best you can do as far as reputation goes is assign it to (person, topic) tuples.
But I still think that's a heuristic at best. Perhaps a necessary one, but I think it's better still to reserve judgement for evaluation of the evidence. Listen to what someone says. Listen to the arguments he makes. Listen to the arguments other people make. Trust your own experience and reason, and go with what makes sense.
What I am saying is that if you ignore people who you think believe stupid things, you'll be ignoring a lot of people who really do know a lot of things worth listening to. And I think more than that, I'm saying that if you classify information, not by empirical value, but by the tribe of who it comes from, you're evaluating the world more like a cultist than like a scientist.
Then I saw what a really good OO design was like. I learned what real separation of concerns and encapsulation could do. It was an epiphany that the programming I was doing wasn't nearly as good as I thought it was, despite everyone around me being proud of it.
I quit that job do my best not to look back.
Other than that, sure RoR can be a nice introduction to MVC. But Monorail was a much cleaner framework from an OOAD perspective. I won't even append "IMO" to that. :-)
Seems to me that those principals are not a quality of a language per se but of design principles that can be applied to any language (maybe some easier than others).
Have you played with Stripes? Simple, efficient, fast, extensible--blows Struts out of the water, and is up and running in under five minutes.
Most people seem to think that Ruby got popular because it was LESS Object-oriented than C++, Java and .NET.
In Ruby, everything is an object. There's nothing like Java's glaringly out of place "primitive data types". Not to mention that late binding is one of the qualities Alan Kay listed as being central the the meaning of the concept "Object Oriented Programming".
Ruby's support for "functional" programming essentially comes down to its ability to encapsulate code in closure objects and the core libraries' pervasive support for these code-objects, called "blocks." But there's nothing about blocks that's anathema to OO. Ruby's blocks are ripped off wholesale from Smalltalk, one of the pioneering OO languages and the one that coined the term "object-oriented programming." Blocks are objects. You can send messages to them, store them in arrays, etc.
Ruby is very similar in general to Smalltalk, much more so than Java. It's also very different from a real functional language like OCaml or Haskell, and trying to write a program as though it were one is an exercise in frustration.
Here are some aspects of Ruby that are more strongly OO than Java:
• Classes are objects — they have methods and instance variables and can be used anywhere another object would be used.
• Due to classes being true objects, class methods can be overridden. In Java, class methods are pretty much just namespaced functions. There isn't even a self/this in Java's static methods. That is totally broken OO — Ruby does it right, Java does it wrong.
• Every type in a Ruby program is an object type. In Java, some types are objects and some aren't. For many types in Java, there are both object and primitive variants. I'm not commenting on whether this is good or bad, but having non-object types in your language is not pure OO.
I would be hard-pressed to come up with similar counterexamples that show Java to be more in line with OO principles than Ruby.
Nice job writing a 1000 word article about Java and web application programming without mentioning the elephant in the room C# with ASP.NET
I've seen small and medium shops move over to or adopt C# at a very high rate(for internal web apps) in the past 5 years. .NET is big in the government too and C# is adding nice feaures that Java has either no equivalent or a poor implementation not to mentions technologies like ASP.NET MVC.
THAT is what is eating Java's lunch more than anything else. It boggles the mind how someone could write a whole essay on this topic without mentioning C#/ASP.NET. I think that's a symptom of reading popular blogs around the internet which talk only about things like PHP/Ruby/Python etc. but comes across as incredibly shortsighted.
What about Mono?
Such as?
What? No. Not at all. Maybe, maybe I'll concede that the JVM, when configured properly, is well suited for the middle layer of a webstack, but to say that Java has completely conquered web application programming is just silly.
I don't really get this article though. The "friendly fire" is what fuels the drive to make new hotness to be as good as it can be. I don't think its damaging outside of the handful of people daft enough to take it too personally.
The argument presented in the article is appealing enough, but ends before it gets to the part where it explains how to make inroads towards the cobol folks. Its been criticized up and down, left and right. The people still using it have taken themselves outside realm of constructive criticism. Any time spent there fighting a losing battle could also be spent improving on what we, who are willing to use new tools, have.
C# does away with a lot of the boilerplate code necessary in Java (i.e. type inferencing, concise lambdas with true closure instead of anonymous single method classes, yield return for lazy enumerables). By baking this syntax sugar into the language, it removes the need for all of the enterprisey patterns needed in Java to accomplish the same things.
Java the virtual machine (JVM) is what I dislike more. It's a platform (like Windows) and within its virtual world, things are just not real. It's all pretend and I guess I should expect that from a "virtual machine".
Both the language and the JVM are mainstream and used heavily now... mostly in big, corporate environments. Devs can make a good, safe living writing Java, and there's nothing wrong with that.
If you hate Java or the JVM, do your hobby projects in a language you enjoy more. If you have no hobby projects or strong feelings (one way or the other), I'd argue that you're in the wrong business.