Can we stop the language bashing please ?
jacquesmattheij.com
jacquesmattheij.com
- "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...
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.
I kinda would like type hinting too, although that's a deeply divisive issue in a dynamic language community.
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.
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 I said: fantastic, request for a bunch more.
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'm going to have to look that one up.
You have to be thoroughly familiar with something in order to properly hate it.
http://www.art.net/~hopkins/Don/unix-haters/handbook.html
and includes the text of the chapter 'The X Window Disaster'.
First hit when googling for the book name itself is a pdf of the whole thing (of indeterminable legality).
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.
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.
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.
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.
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).
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".
[1] http://thread.gmane.org/gmane.comp.version-control.git/57643...
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.
In fact, I could probably find more of them than I care to remember, which is why I posted that bit of text in the first place.
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 think you read stuff in my writing that I didn't put there.
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.
And so on...
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.
--Nietzsche (Thus spoke Zarathustra)
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.)
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.
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.
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.
> 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.)
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 ;)
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...)
> remarkably poorly written, not well thought
That was really funny!
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.
Natural languages take a long time to learn, and do not differ considerably in expressiveness or conciseness.
Programming languages take a relatively short time to learn, and there are large and significant differences in expressiveness and conciseness.
For instance, contrast:
sum = foldl (+)
And: public static int sum(Iterable<int> numbers)
{
int total = 0;
for (int n : numbers)
total += n;
return n;
}
Rarely do you find such pronounced difference in expressiveness between natural languages.I isn't rare at all to come across words in one language that require a full sentence in another.
Fingerspitzengefuehl in German is a nice example.
It requires a full page of explanation:
http://en.wikipedia.org/wiki/Fingerspitzengef%C3%BChl
And it still misses some nuance of the German that I can't quite 'place my finger on'.
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.
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.
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.
So now you've gone from "Java source code is 10 times the length of Ruby", to "Java is primitive and restrictive"?
This is the sort of idiotic baseless language bashing that is such a waste of time.
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!
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.
Can you imagine a world where we were all stuck with COBOL, ALGOL and ADA because no one bothered to write any criticism outlining the areas where these languages weren't sufficient? Are you really claiming that everything from http://www.cs.utexas.edu/users/EWD/transcriptions/EWD06xx/EW... to http://www.pbm.com/~lindahl/real.programmers.html is all useless nonsense that helps no one?
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.
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.
I don't think we are. Perhaps some feel so if they don't have enough programming experience and aptitude.
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.
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?
It's all buzz words and bs.
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.
Can't you?
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.
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."
Though I have to say, your characterization of the issues with multi-threading is nothing short of hilarious.
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...
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.
Ruby is a very human-readable langauge, Erlang is powerful concurrency.
And as I've said I believe concurrency to be largely a self made problem you can avoid when you learn to program better.
But thanks anyway :)
Ruby as easy to read as Java and C, bwHA.
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.
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.
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.
The article might be more convincing if it didn't go out of its way to bash a language. :)
I highly doubt those have as much experience as I do with mumps (long story) so I'll just ignore them.
As I noted above you have to really know something before you can properly hate it.
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.
That still leaves lots of room for uninformed rants whilst cutting out the majority of the noise.
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.
Comparision != Bashing;
(And yes, there is some overlap. Please no long word definition "discussions", either :-)
It's childish and boring.
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?
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.
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.
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.
How is Erlang working out for you?
But I'm slowly getting there.
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).
So even in hammers there is apparently distinction enough to get people very attached to their tools.
And don't get a woodworker started about their chisels either.
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.
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.
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.
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.
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.
It's unfortunate that language creation with custom syntax isn't easy.
Something went wrong? Slashdot effect?
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.
"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.
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.
"criticism for the sake of being unpleasant" is, I think, the point Jasqcues was making :)
Hopefully the comment he made was intended to be a parody of your title or otherwise humorous.