I honestly hope people don't stop language bashing or really anything-bashing. Strident advocacy can be insightful, amusing and food for thought. Done well, it's also more interesting to read than measured bloodless arguments carefully constructed to conform to the Interplanetary Disagreement Protocol version 7.A. I'm always perplexed that in the face of the avalanche of writing about 'passionate users', there are many who put tremendous value on technical communication that's as dull as robotically possible.
There are plenty of ways to show your disagreement and juvenile rants only serve to vent the spleen, nobody is going to come away from an exchange like that with a changed mind, in fact they might start to associate the tool of choice of the 'ranter' with the ranters behaviour.
Real Programmers (TM) can do their work in any environment, they will have their preferences but for the most part they'll be language agnostic because they have learned over the years that the tool is less important than he or she that wields it.
I realize this goes against the grain here, PG is very strongly of the opinion that the tools matter a great deal, but I've seen mediocre people with great tools fail miserably and I've seen people with nothing but edlin and an assembler written in BASIC (of all things) make a small fortune by building some very elegant stuff.
The more interesting fact about this bashing is that the closer the languages are to each other the more fanatical the bashing.
A python programmer will not get nearly as excited about some perceived shortcoming in COBOL as they'll get about one in perl or php because those languages are being used in the same 'domain' that python is used in (for the record, Python advocates are amongst the ones doing the best job for their language of all the ones named here).
I think the assumption that all writing is or should be an attempt to change someone's mind is misplaced. Despite the contortions to equate it to high art or some form of self-actualization, programming is mostly work and work, along with its rewards, involves a fair amount of frustration. Writing and reading about those experiences can be quite interesting and informative and the spleen vented also serves as good reminder not to take oneself (and one's tools) excessively seriously. Tastes vary but I know I'd rather read, say, a chapter in the Unix Haters Handbook than yet another wide-eyed post about the inimitable ecstasy of being within 12 feet of a Rails app.
I agree, but would note that high art and self-actualization are also mostly work. And, in fact, there are lots and lots of Haters' Handbooks for high art and self-actualization as well.
To pick an example at random: I am given to understand that one of the routine tortures of classical musicians is to play Pachelbel's Canon, a thoroughly tedious earworm that is requested at nearly every chamber-music gig. One of my friends in college ran a classical music radio program called Anything but Pachelbel. And there's a very fun section of Robert Greenberg's lectures, How to Listen to and Understand Great Music, which could easily be retitled The Pachelbel Haters' Handbook.
And one could definitely write The Science Haters' Handbook. The author of Piled Higher and Deeper is doing a marvelous job.
Have you ever seen or used the bellcore 'mgr' windows manager ?
Besides the plan 9 stuff I thought that was one of the most elegant attempts at making a window manager, all the interaction was through stdin / stdout.
In the middle of a conversation about, among other things, not taking things too seriously, someone downvotes a comment of obviously lighthearted intent (comes with a convenient emoticon!). Sometimes I suspect there's a secret HN Cabal dedicated to the smushing of any hint of levity.
"I think the assumption that all writing is or should be an attempt to change someone's mind is misplaced."
I'm more fond of writing that seeks to get people thinking and talking about things than proving this or that is The Truth.
A problem with limiting writing to persuasion is that it requires you to first pick a side or figure enough out to know when something is better or worse than something else. But what if you can't? Often what's needed is more discussion, more people kicking around more ideas.
Sometimes getting people rattled is what's needed to provoke interesting responses to move things forward.
I agree with your (Jacques's) larger point, but I think this is a bit of a mountain out of a molehill especially this bit - "It's just a good old hanging party in disguise." Really? .
Every community in the world has fierce discussions about the comparative merits and demerits of the various tools used.
I know martial artists who have fierce debates about which martial art styles are "best" while agreeing that it is the fighter not the style that is ultimately important.
I disagree with this bit of your argument too.
"Real Programmers (TM) can do their work in any environment, they will have their preferences but for the most part they'll be language agnostic because they have learned over the years that the tool is less important than he or she that wields it."
The best programmers I know are not language agnostic at all. They have marked language preferences to the point where they will go out of the way to work with the "best" languages they know. The tool is less important than the wielder, sure but the best wielders try very hard to use the best tools, which is hardly "agnostic".
If this were true, PG could have written HN in PHP. PHP is perfectly adequate for the functionality of HN. The best programmers go for their preferred tools (to the point of buildig new ones if necessary) rather than "agnostically" select whatever will do the job. I suspect COBOL would "suffice" for most business apps, for e.g. and perl for most web apps. If one thinks all langauges are "equal" ins some abstract sense, why bother inventing new ones.
Now if you are saying that one shouldn't actively going about criticizing/putting down other people (as distinct from the languages/tools/ etc they use), than I agree. I hope we never come to a politically correct era where all of us mumble pious homilies about how all languages are Turing Equivalent etc.
All that said, I think your frame of "features from other languages that i would like in my favorite language" is brilliant. Good thinking.
> I disagree with this bit of your argument though.
Good, let's see if we can both learn something :)
> The best programmers I know are not language agnostic at all.
I agree with that, it is just that they will be capable of doing the job in any language, it is their preference to do it in the one that they think is suited best for the job.
> They have marked language preferences to the point where they will go out of the way to work with the "best" languages they know.
Absolutely.
> The tool is less important than the wielder, sure but the best wielders try very hard to use the best tools, which is hardly "agnostic".
Ok, point taken. What I meant with agnostic is that it is a point of personal preference, not dogmatic. I'm not sure which word fits better there than agnostic.
> f this were true, PG could have written HN in PHP. PHP is perfectly adequate for the functionality of HN.
Who knows, it might even be better suited than arc :)
(side note, HN seems to be crashing an awful lot lately, in spite of reduced length of the lists for the new, home and submissions pages).
"What I meant with agnostic is that it is a point of personal preference, not dogmatic."
I wonder if even this is true though. Very strong personal preferences for one tool or language over another can look like dogma to outsiders. What makes something "dogma" is ignorant adoption of a view point or preference and then blindly parroting it and actively demonizing people who choose other tools.
The best programmers (the subset we are talking about) don't blindly adopt (or maintain) their preference for a specific language out of ignorance. Linus Torvalds, for example, has a very strong anti C++ bias [1]. That doesn't make him not part of the set of "best programmers".
Again I agree with your larger point of going around bashing other people because they have different tastes from yours being an unproductive exercise.
"I would hate to program in PHP (or even, I think PHP sucks as a programming language because of reasons x y z) and would much prefer to use Python (or arc or whatever) " is very different from "People who use PHP are idiots and should be burned at the stake".
Actually I am fine with that headline ("PHP must die").
I didn't bother reading the article, because I know all the arguments about what is broken in PHP (and also what is not) and it was unlikely I would learn anything new and I have better things to spend my time on. I just read it as saying something like "Shaolin Kung Fu should die" It is just an opinion about a tool, not necessarily a correct one.
Now if he had said "PHP programmers must die", then sure, I can see why that would bother people.
Maybe not everybody aspires to being a "real programmer", if that means merely being a tool that other people (MBAs) wield at their fancy. Those unreal programmers might have other desires, like working on beautiful things or in an aesthetically pleasing environment.
I just spun the thought further. When would be a situation where you wouldn't care about the language? If somebody hired you to do something, in the language of their choosing. I don't see another possibility?
You are interested in working in a particular area, where a language you didn't like was the best tool for the job.
from Arduino's website:
The environment is written in Java and based on Processing...
Want to play around with an Arduino? The best tool for the job is Java, not because Java is a particularly good tool but because all documentation and community is built around it.
Want to work on the Linux kernel? Feel free to ask them to rewrite it in something other than C because you dislike C.
If I were in a hurry and there would be one 'best' tool but I was already familiar with another.
If someone asked me to fix something for them in an environment that I'm unfamiliar with, maybe even do not like, but the price of asking them to switch is higher than my inconvenience.
In the case that there are serious constraints on the amount of computing power available, say I want to build a data acquisition device that runs of a solar cell and a small battery.
- "Just write an HTML file" deployment. I want to be able to dump an HTML file into a directory to get started, with none of this skeleton directory stuff. Then I could incrementally refactor that file into a template, pull its logic into views and models, customize the paths with a urls.py, and build my app up with baby steps instead of jumping into MVC land immediately.
- Tight integration with webservers. This FCGI/SCGI standalone stuff is a pain, particularly if I also want to serve static files. I want to start with something transparent like PHP's Apache module and then go to FCGI/SCGI/proxying only if I get big enough to add a separate appserver.
- User comments on the documentation. They're occasionally misleading, but usually explain some necessary corner cases.
Things from Java I want in Python:
- A fast JIT compiler.
- JavaDoc. Yes, it's superior to docstrings, mostly because there's a standardized documentation generator for Java and basically all Java projects use it. When I look at a Python project, I have no idea what documentation format they're going to use.
Things from Erlang I want in every language:
- Message-passing concurrency. It's time to ditch threads.
- "Let it crash" mentality. It's virtually impossible to enumerate the ways which your program may fail, so let it die and focus on what you should do to recover from the failure. Then use a supervisor process to make that happen.
Things from Python I want in every language:
- Whitespace-significant syntax. Controversial I know, but I find this drastically reduces clutter in code.
- Doctests. I don't think Python goes far enough; its philosophy is that doctests are documentation and unittests are tests. But with a couple simple extensions, doctests could be tests too, and much more concise, readable, easy tests than the xUnit framework provides.
There're a bunch more I could come up with, but this is already a long post...
Fantastic points! Request for a bunch more, written up.
http://www.sinatrarb.com/ at least does it with one file (but it's not HTML, which I agree is a lower on-ramp).
User comments on docs is brilliant. Flash does this, but moderated, with a long delay (weeks!). So, a reddit/digg/HN/SO voting scheme would fix this. But I agree, that just plain comment - unvoted, unmoderated - would still be a net win.
Javadocs is assisted by strong typing. A huge win is hyperlinks for return types and arguments, so you can quickly trace through. A doc-only type-system convention for python would help here. There's also that extreme approach in Haskell of looking up functions entirely by their type signatures.
"Let it crash" is cool, but makes sense only for servers, I think. It's moving away from a general purpose language to a specific application. But it's an important one, so why not? I mention this just because it's a bit mind-twisting.
EDIT doctest was new to me, and that's fantastic too. http://docs.python.org/library/doctest.html Years ago, I had the idea of writing unit tests automatically, by capturing the output of a manual test session, and then using it directly as an automated test: so that you get it 100% for free, since you do the work anyway. I didn't realize that python's REPL makes this trivial (uh... so lisp has probably been doing this for 30 years...); and pasting it in the code itself is another cool improvement. It still has the problem of unit tests, of freezing the API; but if you change it, you'll want to test it again anyway. Hey, if you refactor the code, you can probably refactor the REPL session at the same time.
As a new php -> python programmer here are a couple other things i'd naively like to add to python:
Built in json_encode.
Type hinting
The only reason i decided to learn python was because of the free quotas on the google app engine.
I suppose I'm still kind of reeling from the triple whammy of having to learn Django (ok, its not really hard), Python, and the google app engine with its non-relational db all at once. Unlearning relational stuff is much harder than it looks.
Python 2.5 ships with simplejson, and in Python 2.6 it's been renamed to plain old json. I'm not sure on the implementation - one of the problems with Python JSON implementations was fragmentation, so if you wanted the standard implementation you'd use simplejson, but if you wanted the fast one you'd use cjson, yet if you wanted the maximally compatible library there was yet another 3rd-party JSON library. I'd like to think that the json module is fast and standards compliant, but I haven't looked at it.
I kinda would like type hinting too, although that's a deeply divisive issue in a dynamic language community.
If you're interested in a Lisp-based PHP-like web framework, I've been working on one called Dragonfly for newLISP (http://www.rundragonfly.com), which has some of the things you asked for like a standard doc format and thread-less message-passing concurrency, as well as "just write an HTML file" development.
One of my favorite things about PHP though is its documentation, which as you point out allows for user comments. That is something that I would like to see more widespread (and something that Dragonfly unfortunately lacks).
I agree with the sentiment of the OP: there are many languages out there, and they each have their own strengths and weaknesses. I also don't thing you'll ever find a language that will please everyone, so say 'no' to language monogamy and pick the one best suited to the task at hand.
Bashing serves a useful function. Not all bashing is productive, but just focusing on positive aspects of every language without any critical thought doesn't work. I would agree if you wanted to change your call for more balance and less comments that contain just bashing.
Critical thought and critical analysis requires criticism, it isn't pretty, but that's how things work sometimes.
As a reference, this is some of the more well-written criticism I've seen on languages and its existence makes the Internet a better place: http://yosefk.com/c++fqa/ (And I say this being rather fond of C++ actually. I disagree with a few of the points made, but I can't deny this is a very nicely laid out critique that bashes C++ in such a comprehensive way it's nothing short of an excellent read.)
There is constructive criticism and there is 'bashing', which I mean to read as being one step shy of attacking those people that use something out of choice or need.
The parallel with religion is a strong one: If you criticize something that's great.
If you start to use your criticism to increase your own stature or if you use it to demean others ('real programmers don't use x') then you've gone from criticism to bashing and it serves no purpose.
Just like the catholics and the protestants in Ireland would go out of their way to try to force the others to 'live like they do'.
Just because it's different does not automatically make it wrong. Some people drive Yugos, others drive BMWs or Audis. Arguably they all have their shortcomings and advantages, the market place decides who is 'best' for a particular application and budget.
Constructive criticism is not telling someone the stuff they use sucks because yours is better, it is telling someone what good things you can do with your toolset. Then you can objectively compare the two and you'll most likely end up somewhere in the middle.
The typical basher has already made up his mind beforehand, and will not move a micron to middle ground.
As soon as you start to make arguments like everybody should use X because everybody knows Y sucks (with or without specifics) it is no longer constructive.
If your stuff is hot shit then do something awesome with it and tell me about it.
That's a thousand times more powerful and productive as an argument than any kind of explicit or implied criticism will ever be accompanied by a 'drop what you're using' advice, especially if it comes packaged in the typical internet rant.
Please tell me exactly where the line is between bashing and criticism and then get the entire world to agree with it.
I agree with you that there's a lot of bad criticism out there, but you draw a distinction where none exists and overall your critique of criticism was did nothing to address fundamental issues.
pg's disagreement hierarchy posted on here every couple of seconds is a much more thorough call towards constructive criticism and actually provides workable and useful advice. Here you're just going off and saying "wouldn't it be nice if we didn't have evil X in the world?"
Sure, it would be nice if it was more civil. Did you want to actually make any real suggestions on how to bring that about? Going off and criticizing all criticism and rambling on about how we should all just focus on the positive attributes of all the languages we discuss is just downright lazy and populist.
> Please tell me exactly where the line is between bashing and criticism and then get the entire world to agree with it.
That's a rather high standard don't you think ? If the people on HN on average would agree with it that would be good enough for me.
> I agree with you that there's a lot of bad criticism out there,
That's good :)
> but you draw a distinction where none exists and overall your critique of criticism was remarkably poorly written, not well thought out and did nothing to address fundamental issues.
I apologize for my lack of writing skills and apparent deficiencies in my thinking faculties, since you leave out specifics I'll have to assume that you meant all of it.
Let me try again: There are lots of languages out there, most of them were created out of some kind of need, they fulfilled a purpose or they wouldn't have existed.
To blindly argue that one language is better than another out of either a personal attachment to some language or a perceived shortcoming in the intellect of those using it is counterproductive.
Languages are like individuals, they come to life, have a period when they're in their prime and they will fade to obscurity, their best features will continue to live on in the DNA of those that follow it.
If we concentrate on what's good in languages and we try to use that knowledge to improve our understanding and our toolsets then we are using criticism and comparison in a positive way.
To simply tear down the tools 'the other guy/gal' is using is counterproductive, it will not change minds and in fact will leave all the participants with a bad taste.
I think - after reading your comment, maybe mistakenly so - that we can do a lot better than that.
> pg's disagreement hierarchy posted on here every couple of seconds is a much more thorough call towards constructive criticism and actually provides workable and useful advice. Here you're just going off and saying "wouldn't it be nice if we didn't have evil X in the world?"
I don't know where you keep getting the world from I didn't bring that in, but, if you want to interpret it that way, don't you think it would be nicer if we didn't have evil X in the world? And given the option to change would you hold on to evil X even after a suggestion was made that could change the world for the better ?
I'm not in PGs league, either as a programmer, a writer or a businessman, and I don't profess to be, but I'm allowed to speak my mind.
> Sure, it would be nice if it was more civil.
That's good, we agree again.
> Did you want to actually make any real suggestions on how to bring that about?
Once again my apologies if my writing isn't perfect, this is not my first language, I try my best.
The suggestion was to analyze those languages that we apparently despise and to find their 'good bits' so we can implement those in other languages. This will help to remove the barriers between those languages and will make switching from one to another easier than it is today.
> Going off and criticizing all criticism and rambling on about how we should all just focus on the positive attributes of all the languages we discuss is just downright lazy and populist.
I thank you for your constructive criticism and hope that I've been able to address your points.
> I apologize for my lack of writing skills and apparent
> deficiencies in my thinking faculties, since you leave out
> specifics I'll have to assume that you meant all of it.
That was me being less than civil and less than constructive, I actually had edited my comments just before you posted this response. My apologies.
> but I'm allowed to speak my mind.
Oh, absolutely, but I'm also allowed to point out that nothing you said will advance the state of dialog forward and is little more than bemoaning that sometimes individuals go overboard from helpful criticism to unhelpful criticism. Just complaining that criticism exists really doesn't help anyone.
Arguing for less of it, by the way, doesn't help anyone either. Arguing for better criticism is valid in my mind, but I don't feel like you did that here. And if you had, I would also have appreciated seeing you actually lay out a cogent and reasonable argument on what you felt was better criticism and how to achieve it.
In my mind we'd be much better served here with an article entitled "How to criticize a language right" or something along those lines.
> The suggestion was to analyze those languages that we
> apparently despise and to find their 'good bits' so we
> can implement those in other languages.
Ah, this is not an unreasonable suggestion, but I took what you wrote to mean that you thought people should stop ever being negative about languages and only ever focus on the positives and to me that's just not right. I think any approach that advocates better criticism that doesn't allow someone to just be critical if they desire is flawed.
Sure, when one can be balanced and review both the ups and downs of a language, that's nice. But I think it must remain perfectly valid for someone to simply focus on the areas they see as needing improvement. Especially in the cases where that person feels that the areas where the language is good have already been covered, are already evident or have been covered by people better equipped to cover them. (Unfortunately not everyone is equipped to point out both good sides and downsides to everything. Sometimes a specific person's view will yield interesting insight on the downsides of a language without yielding anything but relatively uninteresting insights about its upsides.)
> In my mind we'd be much better served here with an article entitled "How to criticize a language right" or something along those lines.
If you write it I'll read it.
On another note, I see from your self-censoring that you know the difference between bashing and criticism very well, witness the difference in your first and second versions of your original comment ;)
> On another note, I see from your self-censoring that you know the difference between bashing and criticism very well, witness the difference in your first and second versions of your original comment ;)
I wish posts had version control. I tend to post things and then almost immediately head towards the edit button to delete things that don't meet a re-run with a more critical eye. It creates confusion sometimes, which is unfortunate.
I suppose I ought to compose my posts before posting them, but I've found it hard to stop myself from posting quick replies. (They always start out as quick replies...)
That type of thing does actually matter, allows people to avoid, or think twice about using certain language features and imparts a vast amount of wisdom to anyone wondering about some of the dark sides of C++'s design. C++ made some very interesting headway in terms of language design and we can all learn from the areas where things didn't work out quite as intended.
Since some people (maybe not you) actually make new languages and rely on this type of discuss to help them create better languages in the future, it's absolutely vital that such criticism continues.
Creating a programming language isn't hard. It's not rocket science. It's just a mechanism for us to express ideas and to execute machine language on a CPU.
Good programmers can decide for themselves what to use, what is ugly, what is crap.
Just like a poet steers clear of ambiguous 'bug prone' words.
Creating a programming language isn't hard. Creating a good programming language continues to be a large challenge that benefits from learning where other languages failed.
I'm not frankly even sure what you're arguing anymore. You're way out there if you think that language design is all completely irrelevant to anyone.
And frankly, as a programmer, I value my colleague's opinions on different languages so I don't have to go running off to investigate every new harebrained language myself.
Perhaps if you'd read more criticism of existing languages you'd be able to more clearly see the needs for new languages to address certain issues and new technology challenges.
I think many programmers would have told you they didn't feel unreasonably restricted by COBOL, ALGOL, ADA or FORTRAN as well, but I sure am glad different people felt annoyed enough with those languages to write some new ones.
Point is, if they hadn't created new languages, we'd still have all we have today. It'd just be in those languages.
Some people will always whine and moan about any language, but in every case there's a work around for any dislike they have. If they're a good programmer they'll be able to work out a solution. It's like a builder moaning that he can't always build on perfectly flat stable ground.
What 'new technology challenges' do you mean? The fact that suddenly in the last few months we've been able to switch to 'realtime' web! Which is a marvelous technological achievement never before seen in computing?
You really don't think there's been any progress in programming languages in the last 30 years?
I think there has, and I think there will continue to be progress. The area that seems most likely and is getting the most attention right now is concurrency, an area that many existing mainstays handle fairly poorly. We may not need a whole new language to address these deficiencies, but certainly different language design concepts, principles and frameworks may need to be incorporated into future versions of languages to provide their continued usage in the new manycore environment we seem to be kicking and screaming our way into.
Certainly I can and have written multithreaded code in C, C++ and many existing languages, yet I can see the value in exploring ways to make that easier.
I don't think there's been much to speak of no. Probably the most useful work has gone into runtime optimizations, JIT etc
I heartily strongly disagree about concurrency. Concurrency is handled badly by most languages because it's a horrible thing to run more than 1 thread per CPU. But I won't start another rant on that.
>> " the new manycore environment we seem to be kicking and screaming our way into."
Again, I don't buy the koolaid. We were using multi cores 10 years ago and warning that we'd all have hundred core CPUs.
I too have written multithreaded code, and decided the solution was to stop writing multithreaded code.
> Concurrency is handled badly by most languages because it's a horrible thing to run more than 1 thread per CPU.
I'm not sure that's a viable position anymore.
> Again, I don't buy the koolaid.
Yeah I know it seems like trendy nonsense but the power-wall is real and every chip designer I know has given up on improving single-thread performance anywhere near the same rate we used to. (And yes, I've listened to one of IBM's research scientists discuss this and when asked explicitly what they were up to with POWER6 and he basically they did it because they could, but they didn't see any future beyond that and overall they were going back to focus on parallelism like the POWER architecture had in the previous designs.)
> I too have written multithreaded code, and decided the solution was to stop writing multithreaded code.
Amen.
But again, I don't think that's viable. We need some way to use multi-threads somehow to get the performance we need in future programs. It could be full multiple processes maybe instead, but we'll need something.
I think we can both agree that it certainly shouldn't be like it is now.
> I too have written multithreaded code, and decided the solution was to stop writing multithreaded code.
Not too long ago on some thread here I said I thought that writing solid multi threaded code was hard and I got reamed for it.
I think I have above average experience in C and writing an operating system kernel has given me a good amount of insight in to how difficult it really is.
Anybody that thinks writing a multi-threaded program is a walk in the park hasn't done enough of it yet (or at least, not enough debugging, especially under high load you can have the weirdest problems if you aren't very very careful).
Writing multithreaded code on a single core is like saying to the OS:
"I don't know what order I want my code to execute, here! You decide some random pattern, and I'll write a ton of code to deal with your random execution of my code."
> "I don't know what order I want my code to execute, here! You decide some random pattern, and I'll write a ton of code to deal with your random execution of my code."
Writing like that makes me jealous.
There is so much insight in that one line, it shows how much you've done better than any long exposition ever could.
That level of brevity is something to aspire to, maybe one day...
Multithreaded code can be useful on a single core when you have blocking syscalls. Non-blocking I/O can help but doesn't eliminate this. Further, non-blocking I/O carries its own complexities.
Though I have to say, your characterization of the issues with multi-threading is nothing short of hilarious.
Well I know you're not mentally challenged, or crazy, so I'm going to guess that you're in one of those "everyone-is-wrong-no-one-can-change-my-opinion" mindsets.
Natural languages and programming languages are two very different things. The choice of natural language usually doesn't make a huge difference to the length and quality of a sentence. Conversely, the choice of programming language can make a very big difference.
I disagree. Most natural languages have bugs. These bugs often provide the basis of jokes, but they're bugs.
Ambiguity, verbosity, tongue twistiness, etc in natural language would certainly cause you to steer clear of certain words, but we don't feel the need to reinvent the English language every year, or keep switching to other languages that seem to have less bugs.
Yes, there are individual words that may not have a direct equivalent in another language, but a language like German is not significantly more concise when applied to a complete document. If you have a 100K file written in English, it is unlikely you would be able to reduce that to a 10K file in German without significant loss of information.
On the other hand, it wouldn't be unusual to find that 10,000 lines of Java could be written in 1,000 lines of Ruby (or Haskell, or Clojure, or...). Further, the effort of learning a new programming language like Ruby is significantly less than the effort of learning a new natural language like German.
>> "On the other hand, it wouldn't be unusual to find that 10,000 lines of Java could be written in 1,000 lines of Ruby (or Haskell, or Clojure, or...)."
Only if you're comparing "Terrbile java programmer" with "good ruby/haskell/clojure programmer".
Now that may be the same as average java programmer vs average ruby programmer. But that's not a fault of the language, it's a fault of some people using the language.
I disagree. No matter how knowledgeable the user, they are constrained by the capability of their tools. An expert logger with a flint axe isn't going to be able to fell them as quickly as he would with a chainsaw.
Java is an extremely primitive and restrictive language, lacking a great deal of functionality that is used extensively in other languages. No matter how good a developer you are, there are fundamental limitations in a language like Java that can't be easily circumvented.
Java source code is especially verbose because Java has a very primitive and restrictive syntax.
This shouldn't be news to anyone. Java lacks macros, type inference, and currying. It lacks a concise mechanism for lambda forms, and variables in closures have to be made final. There is no way to delay evaluation of an expression, save through the default control structures. The generic typing system does not persist to runtime, and it does not support covariant or contravariant types. There is no multiple inheritance supported, nor any mechanism for mixins. Interfaces cannot be applied to classes after they are defined. Types are nullable by default, which is a remarkably dumb idea for a static language. Functions cannot exist outside a class, and the syntax is littered with redundant keywords like 'new'.
Should I continue?
Java's shortcomings are many and well known. Calling Java "primitive and restrictive" is not baseless language bashing; it's an observation of the design decisions made by the developers of the Java language.
Assembly language also lacks a ton of stuff. The point is, you build it if you want it. That's what makes you a good programmer.
I haven't needed any of the items you state as shortcomings of Java, but if I did, it really wouldn't be hard to add them in a preprocessing step.
Not one of the items you state really makes Java verbose. The real reason some 'enterprisey' java is verbose is because people use endless patterns, factories everywhere, separate implementation from interfaces for the sake of it, etc.
Which is why people rarely program in assembly language any more.
> The point is, you build it if you want it. That's what makes you a good programmer.
Sure, but working around the issues I mentioned would require altering the syntax of the language, or preferably constructing a new language from scratch. But I wouldn't count that as programming in Java.
> I haven't needed any of the items you state as shortcomings of Java
People rarely do until they have experience of using them; it's the blub paradox. If you take a look at the code of a seasoned Lisp or Haskell programmer, then you'll note that a large proportion of their code includes syntax structures that cannot be replicated in Java.
> But if I did, it really wouldn't be hard to add them in a preprocessing step.
Fixing Java's type system as a preprocessing step is not going to be very easy, I'm afraid!
What exactly is your point? I know axod believes that the choice of programming language does not matter as much as I think it does, but what's your opinion on the discussion?
Don't get me wrong, I believe language choice matters a ton when it really matters - maybe you need specific libraries, maybe speed/memory concerns, etc. I just don't believe the actual syntax (Which is pretty much the only difference between language source code) matters much.
Yes, sorry; let me rephrase that. I believe the syntax of a programming language matters a great deal, and has a significant impact on code length, quality and flexibility. axod disagrees on this point.
better still, stop binding yourself to a language - there are no Python programmers, or Java programmers - there are programmers that use the respective language (at that time).
That kind of blunts any personal attack. There are however communities, so I guess that is what people could attack, for better or worse. But its not personal.
This is exactly the type of mentality we employ when trying to hire folks for the FarmVille team. We tell our recruiters to put job descriptions out for "Software Engineers" versus "Flash Developers" and "PHP Developers".
For us, it's rare to find someone with both PHP and Flash experience. Heck, most of the senior devs have less than 2 years experience using both at the same time. So, instead, we look for really smart programmers with solid software engineering fundamentals since we figure that it's much easier to teach a smart person a new language than try to teach someone core CS concepts.
We've seen this work fairly well with several new hires. The language is, like you said, just a medium and changes depending on the project. The real challenge comes from understanding how to architect code in a way that's flexible/scalable/maintainable.
Ideally people would have used/shown interest in a reasonable spectrum of languages. And most tools in common use (common being the key word !) really should only take an afternoon to learn enough to get something done, however small. I am not sure why more interviews aren't done like that, but I guess hard to scale.
Granted, it's on the extreme end of high-noise/opinion scale, but "Bashing" is a natural component of the many evolutionary pressures exerted on any form of human memetic expression.
It's no different than literary or other forms of artistic criticism.
Be wary of ANY single idea or concrete instance of expression without a robust spectrum of discussion surrounding its merits.
Every language, including the most vile but still Turing complete abomination (I'm looking at you, mumps) has something that we can all learn from and something that is worth singling out for admiration.
The article might be more convincing if it didn't go out of its way to bash a language. :)
In which case, your request becomes "Can we stop the language bashing, unless you really know how bad the language is?"
Which, of course, is useless. You might as well write an article asking people to stop writing uninformed articles. If someone writes, either he believes himself to be adequately informed or he doesn't care that he is uninformed, and in neither case will he be dissuaded by such advice.
I actually like language comparisons. Since I can not be a master of all languages myself, I find it interesting to see what features people value about "their" language and what different languages have to offer.
Also, it is not just senseless bashing. If I invest in learning language X, of course I have an interest in X becoming popular to protect my investment and make it more valuable. Unless you can take that aspect magically away, I don't see how language wars could realistically go away.
"in actual fact the criticism is uniformly negative, usually quite childish and un-actionable, one step shy of a value statement about the users of those languages.
It's just a good old hanging party in disguise."
The problem is, I FULLY agree with EVERY aspect of EVERY php bashing (ok, almost), even though I use this language daily, and have been using it for almost 10 years now. ( :S )
The point is, the original implication, that Perl or Python or Ruby or whatever other languange fanatics fabricate or like these php bashing posts, is completely false.
If I had a blog, I could have hundreds of php bashing posts, because over 10 years of php usage you encounter a number of mayor WTFs (believe me ;) and you REALLY hate them.
I don't take it as a personal insult at all, and noone should. Ofc I'm not a php-only programmer, but maybe noone should be? Maybe if someone is offended by a bashing of his/her favorite language, it's time to reevaluate some personal issues about self esteem? Or if someone is a somelang-only programmer, then maybe a broadening of skillset (by other languages) is advisable anyway?
Hacking is one of the few art forms where the medium is itself an example of the art. It is natural for good artists to be passionate about their art; to love and hate certain examples of it. Working constantly with those examples is sure to amplify such feelings.
As a PHP-only hacker (wouldn't say fan), I am always amused with the PHP bashing. It's missing this or that. It does x wrong. Yet it only powers Facebook. It is the only language where I can be up and coding in no time to produce complex web apps quickly.
Language users always underestimate the second point: personal familiarity is a great productivity boom that no other language can match. Better the devil you know...
And a similar argument holds for databases, but it's a bit more complicated for that one.
"As a PHP-only hacker...personal familiarity is a great productivity boom that no other language can match. Better the devil you know..."
It's possible to become personally familiar with more than one language. Get to know many devils. ;-)
Learning a new language always feels like a pain when you're doing it, because everything's 10x slower than with your old language. But then you become familiar with the new one, and can write two languages at full speed instead of one, and the pain of learning it is quickly forgotten. Moreover, it gives you perspective on both the old and the new that can be quite valuable.
Do this enough and eventually you realize that there're some languages that are just bad. But it's very much worth examining their history and understanding how they became bad. Because I can guarantee that it wasn't because their designers were stupid, and the same forces that make a language go bad tend to make any software project go bad. If you're aware of them, you might keep your software project from going bad, at least for a while.
I do learn other languages. Right now I'm focusing on the non-alphanumeric soup we call Erlang. I can also (just) barely do some Python, and Node.js is next on the list.
For PHP, it's best to think of it as an inconsistent wrapper around lots of other libraries. In most instances, I know there is a function to do what I want, and a quick lookup gets me the right syntax.
I should have been more explicit in how it's going for me: slowly. Very very slowly. I think it's a function of the amount of time I am dedicating to it and the book is written in a very intense dump-everything-in-one-go kind of way.
Why aren't programmers more pragmatic? I like lisp better than any other language but if there is a better solution in another language then I will try to either learn it or use it. Why can't programmers see that languages are tools to be used and not fight if one tool is used over the other. You don't necessarily see this with other craftspeople when they create things. I don't see people arguing over hammers and if you did it sounds really stupid.
I don't think the analogy makes sense here. Unlike programming languages, there's little operational difference between one brand of hammer and another. Maybe brand X is known to last longer than brand Y, but they will still be more or less identical in daily use (aim, swing, get thumb out of way).
All craftspeople argue about tools. Be it sewing machines, chisels, knives, scissors, paints, brushes and just about anything else you can think of. Everybody has their favourite brand and design. The reason you don't see it is probably because you don't hang out at the right (online and offline) forums.
You cannot fix something that you don't know is broken. Programming languages can have flaws just like anything else. Unless someone points them out they'll never be fixed.
The idea that there is a single perfect language for doing everything is a myth. We need a variety of languages in our toolkit. They can be improved if there is constructive criticism, someone to listen and innovate changes.
Someone bashes php or Java, and, well I can understand that, but how dare you bash language bashing!
Joking aside, bravo for the denunciation, there's no best language, there's no worst language, they're tools in a box, the sooner we accept it the better.
They are not just 'tools in a box', though, that's a bad metaphor. Each language is a more or less complete toolbox, although each one has things it's better at. Still, most of us tend to grab the language(s) we know, first, rather than look around for the 'perfect' language for each job, unless it's going to be a very large project.
Exactly, it is all about economy. If the price of change is too large we'll stick with what we know already.
If the price of change starts to look like it might be made up for over the course of a project then that's an excellent incentive to switch to something more suitable.
Let's accept your argument, that each language is a complete toolbox. You'd likely grab a different toolbox to fix different classes of problems.
For large problems it's common to bring several different toolboxes (think of a primarily php site with a their public api scratched out in java).
The points among each language which contrast and define the 'things it's better at' differentiate the tools and or toolboxes (however you prefer to think of each).
Again, +1 for tearing down tearing down programming languages.
> Let's accept your argument, that each language is a complete toolbox.
You can write a web server with Tcl, Ruby, Python, Java, Erlang, C, or whatever.
You can also create GUI's with all those languages.
Any major language is most likely capable (and has some libraries) for doing common things.
> You'd likely grab a different toolbox to fix different classes of problems.
Like jacquesm says below, you would only do so once the cost of learning a new language is less than the perceived gains from using that new language. Since programmers are expensive, and jumping to something new and potentially unknown has some potential pitfalls, this is often not the case. I.e. it's better for the Ruby guy to write a little web server in Ruby rather than Erlang if that's what he needs, even though the Erlang one will kick the stuffing out of it in performance tests, unless of course he knows that performance is absolutely critical (it isn't in many cases), and more important than solving the "business logic" of the problem.
Language bashing = pointing out flaws in notation. If you think of programming as math, then you need the best notation so that you can solve your problem more easily.
It's unfortunate that language creation with custom syntax isn't easy.
Not sure why you got voted down for that, Rob, the sysadmin chose just that moment to reboot the box and you caught it before the db was up again, so it definitely was down for a moment.
It's funny, I rarely submit stuff from my own site to HN, of course that coincides with switching the server to a different phase.
I do not see anything inappropriate about use of term "bashing" - which I take as meaning, "to criticize in an UNcontructive manner," perhaps with a hostile, degrading tone.
Hopefully the comment he made was intended to be a parody of your title or otherwise humorous.
I'm trying to think of one. A better alternative might be "criticism", but "Can we stop the language criticism please?" seems like an obviously wrong question - without criticism, how do we know what's bad?
"Bashing" kind of suggests "criticism for the sake of being unpleasant". How about "non-constructive criticism"?
I can't quite explain what it is about the term "bashing" that I find annoying, but I think it's the assumption it seems to make that the criticism in question isn't well reasoned.
Criticism is fine with me. But bashing goes one step further than criticism, it implies something more than a simple and well reasoned pointing out of a flaw.
If you can't explain it then I hope you'll forgive that I stick with the bashing for now, it seems to cover the bases.
It's the only word I've seen used in that context that fits the bill as far as I can see.
