I always had the impression that people that say they 'hate Java', usually don't hate "Java: the language". Most people that dislike programming in Java have a negative sentiment because of:
- 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)
Java is so popular, easy to learn and use that there are tons of terrible frameworks and bad programmers in the community. Rebel against it all you want but in the hands of great developer you can get pretty amazing software written in Java like Hadoop, HBase, Lucene, Cassandra, etc. Java is the assembly language of the JVM and since most of the cooler new languages are on the JVM (and written in Java often) it will likely remain as the way to eek the best performance out of your applications and likely has the library you need to get your job done.
As for your points in here. Most of them I can respond with "don't do that".
I don't think those are examples of great software. They are very useful, and many fill a niche that needed filled, but they aren't great software IMO. Hadoop is a very leaky abstraction to give one example. I've seen it crash frequently because people used wild cards for their input and the job tracker would run out of heap and crash.
Hadoop is a leaky abstraction because it crashes ? Does not compute!
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 !
The differences between Java and its bytecode are pretty small. There are only a couple things that you can do in bytecode that you can't do in Java source and they are mostly irrelevant.
Since we were talking about Java and not bad engineering management and poor design choices, I thought I would point out that programming in Java doesn't have to be like that. Perhaps I should call it Java!EE.
Mostly, this. I've seen Java go fast and work well and scale and do other "enterprise-y" things, but there is tons and tons of awful software out there.
I just feel like there are better choices for most projects.
Some of your complaints are definitely right. A lot of factory-mill certified Java programmers go crazy with XML, factory-pattern, and other enterprisey stuff.
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!
Oddly missing the point for an article about missing the point.
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 certainly identify with your point, but I actually had the opposite reaction to this article; particularly the second half.
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.
Right but there's a difference between hype and experimentation with new tools and methodologies.
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.
My concern, one that I believe I share with the author, is that the zero-sum tenor of tech-community discourse is overshadowing the more fundamental advances (and setbacks) that we could be focused on. And the attitudes of what seems to be a generation of edit-line/update-browser developers is only making it that much more difficult to drag those advances into established industries.
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.
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.
It's more of an antecedent-consequent relationship than redirection, in my opinion.
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.
Actually, yeah, Coffeescript is actually bootstrapped using Jison (a javascript implementation of Bison), and implemented in Coffeescript! :)
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.
Yeah- You've definitely convinced me that I need to take a closer look at coffeescript. But I'd only be really interested if it could take something approaching OWLlink Functional syntax and generate code in any popular language, with my main concern being the ease of controlling exactly what is generated. Not because I think OWL Functional is 'better' than JS; I just think flexibility is an important criteria for judging the quality of tools along these lines.
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.
No, cargo-culting is a bad idea if you don't know why you would pick a piece of technology. I'm okay with technology being a crutch, and helping to carry you over terrain you do not yet understand. But that is different from using technology you do not understand for reasons you do not understand.
Just using a NoSQL store, because it's a NoSQL store is a bad idea, and can lead to all sorts of dangerous consequences.
Maybe it's not surprising that a mainframe programmer completely fails to understand the debate.
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.
I definitely agree with your sentiment. If you're working on your own personal projects/startup, most of the time you aren't gonna choose Java, but another language whether it be Python, Ruby, etc. But if you're in a corporation, you don't have the flexibility and freedom to choose what you want to work for. This association of corporate life with Java contributes to people's hatred of using Java. I bet if corporations started using Python, more and more people would hate Python as well if they had to use it on a daily basis for boring, business processes
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 of corporate life with Java contributes to people's hatred of using Java.
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.
You really don't think Python is reaching the point where a manager type would be comfortable with it? It's mature, it has tons of libraries, it's used in all kinds of successful projects. I really don't know. It just doesn't seem anything like a high-risk choice to me.
> If you're working on your own personal projects/startup, most of the time you aren't gonna choose Java
... 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.
That's funny, apparently I'm getting downvoted repeatedly for having the nerve to say that FOSS Java projects are not a minority. The irony is that I left Java behind for Python seven years and never looked back.
If I was taking this votes/points/karma thing seriously I would be rather pissed, now I'm just laughing at the rabid fanboyism.
> where Rubyists and Pythonistas are monkey-patching metaclass decorators
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
I like to compare hating java to hating SUVs - they may be used inappropriately most of the time, but there are scenarios where they are the best tool.
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.
I never thought I would defend Cobol but I have found that Greenscreen terminal based programs written in Cobol and Powerhouse are amazingly fast compared to equivalent web based applications. (I speak from my experience in Financial industry. your experience may vary). Scalability is a mater of throwing more IBM hardware at it and its not very expensive to operate. The IBM Iseries is something unlike anything I had ever seen in terms of scalability. Just saying that your new fancy language of choice is not necessarily better than Cobol.
Robert Glass wrote a series of articles defending Cobol as still the best language in some ways for business programming. He didn't talk about performance, IIRC, rather about language expressiveness (mainly language constructs for writing reports). But what you're saying is not surprising. The disease of our industry is the notion that old stuff is icky and stupid.
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?
> 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.
I don't hate Java, per se. I did a lot of Java coding from '96-'06. I went with it as it became the king of the 'enterprise'. What I realized later though is that you can't use Java very efficiently in a small shop (one or two guys).
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.
TL;DR (as I see it): Complaining about Java as a language is pointless, as all of the "new hotness" languages out there don't slay the old dragons of ancient business system languages like COBOL, which is where the author thinks people should be spending their time.
I don't specifically hate Java the language, although I'm not enamoured with it either. I do hate the whole culture / attitude and baggage that comes with the language if you have to use it in an enterprise environment. That same culture that warped XML from something moderately useful into a horrible joke. Same goes for SOAP, UML and basically all things 'enterprise'.
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)
Yes, we were talking about this specific thing at work the other day. How come all non-trivial Java programs end up a mass of Factory and Implementation classes?! Several of the systems I support even weave in Spring, which while helping in some ways, completely obliterates readability. :(
My theory is that the language's lack of complexity bothers 'high-end' Java devs at a subconscious level, so they think they have to invent it in order to seem relevant to the larger community. Another idea is they may believe elegance is a function of using powerful language constructs, rather than a function of minimalism.
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.
I believe it is because the complexity more or less has to exist, when you remove it from one place(in java's case the base language) you add it in another(in java's case pattern soup). Just think about how you would solve the problems patterns solve for Java in other languages. In every case that doesn't require pattern soup involves language features Java left out.
You're right in that there's a certain base level of complexity due to the problem being solved.
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.'
I wonder... how many programmers have been exposed to enough different problem domains and languages to really make an accurate judgement on what is "the best programming language", if any such thing even exists (which I doubt).
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... :)
I don't hate the features that are there, I hate the features that are missing. Most languages I know let you express vector<int> without an external library, but the libraries that ship with this language only let you express vector<"oh wait let me call that function/allocate a new object for you">, which is significantly different. It doesn't provide coroutines or continuations, while even C++ does.
I'm 7/9 on your list ("versed" if not necessarily "expert"), and I can honestly say that there's only one sweet spot for Java that I've been able to identify: cross-platform GUI work. And that's entirely down to the tooling.
Some of us do Java for a day job and feeling a lack of creative expression at work - explore our creative side with other frameworks. Or even pottery classes.
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..
Since there are many languages that now target the JVM, I guess my main distrust should be targeted towards that instead of the language itself. Can someone explain to me what the advantage of running on the JVM is compared to something else (including native code generation)? From what I understand it provides: native tuned GC, stable and tuned JIT, and a class/module mechanism revolving around reusable code libraries (e.g., you could drop in a library written 6 years ago and have it 'just work,' when with C everything needs constantly shifting header files). I haven't used the JVM seriously in years, but I always got the feeling that around these core strengths were layers and layers of bureaucracy -- XML 'makefiles,' a stack-based VM that must inefficiently be translated to a register machine, and the feeling that everything is overengineered to the point that a simple "hello world" takes up gargantuan amounts of time and resources compares to things like Chicken Scheme or Go which have roughly the same features. Would anyone who uses JVM-based languages care to address these fears, I'm honestly curious if my hesitation is well-founded.
The JVM allows commercial software to be usefully cross platform. If you are working with open source or scripting/jitted/non compiled languages this doesnt matter.
Compiled C or C++ code was hard to get for the right architecture and work with.
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.
You have packed a lot of misinformation into one post. Cross platform does not matter for open source? People who use Linux also have a disdain for VMs like those that run Erlang, Python, Java, Scala, Clojure, etc?
The JVM is probably the foremost example of a VM that uses JIT-ing really really well to achieve near-native speeds for a VM language.
Large corporations have the money to run huge applications on serious systems, and might get a slight performance benefit from running Java. Try running it on virtual servers for small web applications though... It's painful. Compared to Python, Ruby, Perl and PHP it eats resources like crazy. Developing and deploying Java apps feels slow and like being stuck in the stone age, unless of course one starts building a large automated infrastructure with continuous integration servers and repository managers... leading back to my first point: complex, heavy and hence expensive infrastructure. Debugging large web applications is worse than any other common programming language for the web. In all honesty, I've never written any serious software in that language – I know more about administration of systems running Java – so I'm not getting into a discussion about the language in se, but it seems very hard to get a clean transparent architecture in larger applications without drowning in hundreds of small little classes littered throughout. While there is a lot of badly written software out there in any language, it's always the Java programmers around me that complain most about trying to decipher how a complex Java application actually works and which code and classes hook into others.
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 don't get this whole "Java sucks movement".
You don't like Java? Cool, use something else. Your boss not let you do it? Convince him or her. Create prototype of what they want from you using your language and use it as a proof that your language of choice is a proper tool.
If you cannot, and your bosses decided to use Java it isn't problem with Java, but with you, or your company, so you need to work on you, or change a job.
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.
#Using Java for serious jobs is like trying to take the skin off a rice pudding wearing boxing gloves. -- Tel Hudson
#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)
That's a lot of quotes, mostly by people I've never heard of (PG, Kay, Greenspun and Yegge excepted). I'm not saying there's no truth to them, but they're mostly fluff and little content.
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.
any of them write a more successful language than Java? or how about Visual Basic even? For all the complaints, at least Java moved programming technology to another level on a massive scale, lest we all be complaining about C/C++ still.
Java seems to be mostly a step backwards from C++ in terms of expressiveness, with kludges here and there to hide the fact. Because the kludges are very slow, I have had significantly less luck optimizing Java than C++.
Indeed. Python is my Blub; it's just so darn easy and it has enough functional capabilities that I haven't yet felt compelled to throw out everything I know and start with Haskell or Clojure.
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>
I am a Haskell programmer, and aware of the more powerful abstractions available in Agda and similar languages. So I am aware of my Blubness :-)
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!
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.
I enjoy creating as much as the next guy, but I think the "point of programming" is to solve problems. And if banks use Java to solve problems, then that's what you use. If you get the "joy of creating" as you go along, great, but your employer doesn't require it.
The interesting point in this for me was the idea that Java, or any other development platform with an "enterprise" sticker slapped on it, will be the obvious choice for a given problem space simply because it has the sticker.
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 been in the situation several times where technology decisions are made based on brand
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...])
We went PHP->Java a couple of years ago, because we'd need thousands of app servers if we didn't. We recently agreed that when we replace the stuff that isn't performance-critical, we don't need to take the productivity or morale hits to do that in Java, but we'll be damned if it's staying in PHP.
Well, I'm not for or against Java or any other language. I agree that there can certainly be "bad" choices for specific problems, but it's absurd to think that Java specifically (or COBOL) is some kind of scalability magic bullet.
<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>
Sadly no, I've chosen not to identify myself so that I can fully speak my mind. But in short, the PHP 5 interpreter (with APC) was a pig even for a scripting language, and few builtin client stacks lent themselves to making parallel requests to different backend services with timeouts in milliseconds. The rewrite was also an opportunity to jettison technical debt like support clutter for long-disused features (many forgotten after turnover in engineering). We only had to tune the GC a little; the gotchas have been minimizing exception volume (they're still extremely expensive, especially when stock Tomcat 6 handles certain bogus requests that way) and learning to avoid certain J2SE features which impose unexpected synchronization (weird stuff like creating fresh java.util.Calendar instances instead of cloning one). Nowadays we're moving from servlets towards Netty and async everything so our cores don't context switch so much.
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 not really a web/php programmer, but my (humble) experience really was like the cliche -- the limiting factor was the db and not the scripting language.
(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.
All the above industries are billion dollar players in our economy. All of the above industries write new COBOL and mainframe assembler programs. I’m not making this up, I work in the last industry, and I’ve interviewed and interned in the others.
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.
> The question to ask is: What are the economic and social forces keeping the COBOL code base alive?
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.
I'm working towards an MVP that uses Java (on Android), C#, and JavaScript. It's interesting comparing and contrasting the languages while using them all at once.
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.
I don't hate Java as long as I don't have to use it.
I don't hate COBOL as long as I don't have to use it.
The same is true for a number of languages that simply aren't fun to use.
The difference is just that it's more likely that I have to use Java at some point, compared to COBOL.
Java is the default language in the best selling phone platform, Android. For that reason alone it will remain relevant for a long time. I know Android can run other JVM languages, but until the platform becomes stabilized (meaning most big security holes are filled, new non-trivial features are rare) there won't be a push to make non-Java languages a first class citizen.
You are eliding the difference between selling a lot of devices and selling a lot of apps. I notice this ecosystem over here that's running on Objective-C that's doing a very good job of selling apps and directing money towards developers.
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.
I think you've been asleep for the last year or so. This is not even about Android vs iOS, I don't care about that stuff. There, clearly, is a large interest in developing for Android (again, whether it is on the same level of another platform is irrelevant to Java's future viability). Real, good developers are taking it seriously, and profiting.
Actually, Go would be great for GUI programming, precisely because it has a concurrency model that doesn't suck, and GUIs are almost always concurrent. Remember that Go's concurrency model is a descendant of CSP which Rob Pike first used in Squeak, a language designed exclusively for building GUIs: http://doc.cat-v.org/bell_labs/squeak/
> Java is the default language in the best selling phone platform, Android.
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.
A lot of transactional systems are being written in Java already. So it's a matter of not being worth rewriting the working systems on production why Cobol is still alive.
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)
Have you looked at JEE6 ? They've really pared down a lot of the boilerplate you had to do, and the reference implementation Glassfish is a snappy customer.
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.
There a lot of powerful frameworks in Java that make application development fun and easy (e.g. Camel, Spring, Hibernate). Java can replicate many of the popular features of other languages - anonymous functions are duplicated by single-method interfaces and anonymous inner classes. I say use the best tools available, and Java has still got to be one of those.
My sentiments :
Good : Java has lot of well-documented libraries. Yay.
Bad : Lots of boilerplate code, you can't add flexibility to the langage (not even with "simple" C macros or closures).
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.
"This is what switching out of the Java paradigm, into Ocaml or Haskell, is like."
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.
I've been playing around with Haskell recently (actually have been for years, off and on) and have been thinking about doing a real production system in it in the near future.
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...
If you're comparing to Python (which is stable but hella slow) or Ruby (which tends to be both unstable and slow), GHC stacks up pretty well. By "production systems", I was mostly referring to the sort of things that are normally written in Java or C++ - Google-scale server farms, or financial transaction systems.
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.
Assuming C++ is out of the running, the alternative to Java is basically Scala. And that's it. Maybe Go will be an alternative in the eventual future, but right now it lacks the library & tool support.
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.
I've written a lot of code in F# and I have to agree that writing business software in a functional language has a little bit of a learning curve but once you figure out how it's done it's much easier.
While I appreciate your experience, you basically are saying that it would be hellish because of two features. Haskell and/or OCaml have many incredible benefits, and many of them do not rely on laziness to work. Sure it allows you to write some incredibly elegant, generic solutions - but I don't think it is necessary to have it as the default.
I 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!
Oh, I think that nearly all of the problems with Haskell could be fixed up if it had the resources of C++ or Java. The problem is that in getting those resources, it would create new problems that would end up looking a lot like the whining about C++ or Java.
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. ;-))
> 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.
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.
But other languages give you a syntactic cue that what you're doing might be potentially expensive - it's a function call. That's why most language styleguides have a naming convention for accessors, so you can distinguish between method calls that are basically free vs. method calls that might be expensive.
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.
Hmm I have come across many a codebase in countless languages where there was no way to discern that type of information from the naming convention. Even accessors in say C# or Java are perfectly legit to do any side effect they want. In fact I think it is worse in those situations - because side effects are not modeled. Indeed, no language has found a way to model non-termination in the type system, hence the halting problem.
Honestly I just haven't experienced this very often in Haskell... When I do it is usually a 'doh moment and a simple fix.
I would use Ocaml before Haskell as a production language, actually. It's hard to reason about space performance in a lazy language, as I'm sure you can imagine.
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.
Ocaml has its own performance gotchas (especially on 32 bit machines) although they are much easier to work around once you know them. For example, if you allocate a string larger than 16MB on a 32 bit machine ocaml will segfault. If you don't know this little fact that can be a really hard bug to track down.
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.
These are interesting observations. I'd love to hear more about them.
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.
This is one of the reasons I love Go, it is preeminently pragmatic language, not designed for "mediocre programmers" (Java) or "genius programmers" (Ocaml, Haskell, C++), or to fulfill feature checklists, but to be useful and used by hackers that want to get stuff done and not just to think about stuff.
... and yet Steve Pavlina was a Windows developer.
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.
Steve Pavlina has one essay, in particular, which changed the way I thought about my business and directly contributed to my later success. (The five-second version: improvements in your funnel are multiplicatively effective. Does that sound obvious? It wasn't obvious to me, and it set me down the road of A/B testing and other hillclimbing, and I climbed my way right out of my day job.)
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.
Since Steve Pavlina makes something like a million dollars per year on his magical blog, he has credibility when it comes to making money.
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.
If someone quoted Jesus (or their favorite spiritual icon) on HN in the same positive and relavent manner that Steve Pavlina is being mention in this thread, and nobody flipped out, it would come close to a watershed moment of maturity for tech forums everywhere.
I believe it was an article called "Shareware Amateurs vs Shareware Professionals". His old Dexterity is no longer available, but he released the copyright on all his material so I mirrored it (and all his old Dexterity articles) on my site:
No, because failing to ignore the history of the person telling you something and their motivations is how you get slippery slope logic that leads to things like using Eugenics to validate killing people who are poor or mentally ill.
I generally am not concerned with who said what but whole "wind-up" of OP kind of hinged on this "1-7-8" conceit and Steve Pavlina as the authority documenting it.
The truth of a statement can be determined by two things:
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.
We're not quoting him because he's a cult leader. We're quoting him because it was a reasonably insightful blog post that is relevant to the topic. I, in fact, have no clue who Steve is, and found the posted link a valuable addition to the discussion. If you believe it was not so, I'd love to hear your reasons.
The author was saying something philosophical. It wasn't a question of correctness (philosophy isn't real enough to be judged so) but a question of well-spokenness. I found it a well-written peace which offered interesting insight. None of that requires evidence, and none of that depends on author intent. I had (and still have) no idea who the author is, and found it a good piece nonetheless.
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.
I'm reminded of the first time I tried out Ruby on Rails. I had done some PHP, Perl, C, and Java programming before that. I had worked on some medium sized projects, but in general anything larger than a few dozen files got so complicated it was hard to keep track of.
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.
That's weird because a lack of SoC is probably my biggest pet peeve with 99% of the Ruby code available, including the Rails source.
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. :-)
What about the language you are using enforces real separation of concerns and encapsulation that Java doesn't have?
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).
Presumably, Periodic was referring to Rails' emphatically opinionated framework, which (under the right circumstances) can shine a light on at least one approach to SoC that may, in turn, lead to a deeper understanding of the underlying principles.
What does "I had done some...Java" mean? You used servlets to write a web app? With our without JSPs? When? That elham are sfo many frameworks out there that comparing RoR to (generic) Java seems nonsensical to me.
Have you played with Stripes? Simple, efficient, fast, extensible--blows Struts out of the water, and is up and running in under five minutes.
That was my exposure, Struts, and poorly designed struts too. I think 90% of the code was in static methods. I deferred to the people with 10 years of seniority over me at the time.
In what way is Java more object oriented than Ruby?
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".
I could be off-base, but your thinking seems to be, essentially, "More buzzwords can be applied to Ruby, while 'OO' is the only one that applies to Java, so Java must be more purely OO." This is not a very accurate view of the two languages.
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.
It was not that Ruby was more OO than Java, it was that Ruby on Rails had a better design than the spaghetti-code Java (poorly designed Struts apps) I had been exposed to.
> Java, with its faults, has completely conquered web application programming. On the sidelines, charging hard, new languages are being invented at a rate that is mind-blowing, to also conquer web application programming. The two are pitted together, and we’re left with what looks a bunch of preppy mall-kids battling for street territory by break dancing. And while everyone is bickering around whether PHP or Rails 3.1 runs faster and can serve more simultaneous requests, there lurks a silent elephant in the room, which is laughing quietly as we duke it out in childish arguments over syntax and runtimes.
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.
The problem with C# is that it's tied to Microsoft, and we're already seeing what can come of that with developers wondering if .NET is a first-class Windows 8 development platform or has been relegated to legacy status and supplanted by HTML5. Microsoft is remaining silent.
Mono doesn't get close to .NET, even in versions and in implemented functionality, there's always missing something. Writing a serious web application in asp.net is not the same as writing a serious web application in mono.
>So what is the real problem in the this industry? Java, with its faults, has completely conquered web application programming
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'm currently writing some cobol for shits and giggles. Its terrible.
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.
I don't think it's ironic. C# directly addresses many of my concerns with Java.
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 language is OK. The only downside to it (in my opinion) is forcing OOP on everyone. Other than that, it's fine.
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.
- 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)