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.
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.
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.
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!
#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)
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++.
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.
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.
>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.
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.
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.
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.
> 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
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.
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.
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.'
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.
> 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.
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/
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.
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..
> 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.
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.
> 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.
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?
Why some user-level java.exe is better than any other .exe? ^_^ Why in 21th century, with only one remaining platform (x86_64) we should stick to 15 years old concept form isolated from OS environment? Why primitive select/pool/signal I/O and several "bridges" inside user-level process are necessary to run a web application?
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.
... 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.
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.
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.
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.
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.
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:
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'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.
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.
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 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.
"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 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'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.
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.
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.
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.
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 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.
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>
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.
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.
185 comments
[ 3.4 ms ] story [ 221 ms ] threadEither 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.
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.
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.
I'm sorry that just don't cut it for me, and I'm capable to dislike both COBOL and Java.
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.
#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)
Source http://harmful.cat-v.org/software/java
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.
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 :)
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.
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.
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.
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.
[1] https://github.com/languages
If I was taking this votes/points/karma thing seriously I would be rather pissed, now I'm just laughing at the rabid fanboyism.
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 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
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.
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".
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.
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.
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..
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?
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.
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?
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.
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.
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.
Huh. What did Jesus write again?
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.
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.
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.
http://www.sodaware.net/dev/articles/shareware-amateurs-vs-s...
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.
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.
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).
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. :-)
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.
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 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.
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.
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.
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.
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...
The difference is just that it's more likely that I have to use Java at some point, compared to COBOL.
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>
(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.
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.