Why Language Advocacy is Bad

richw showed us an excellent story talking about why language advocacy is bad. Its an excellent piece, and although many of the points he writes about are specifically related to Perl Programming, many of them can be equally applied to the irrational ways that people approach things like politics or Slashdot discussions.

The language must fit the problem

I think that running around shoving your favorite language down people's throats is a waste of time. But on a more subtle level, shoving it down your own throat can be a waste of time as well. I like C, it's a language that i get along well with, but there are times when it would be a pain to use C, so i will use something else that fits the problem better, like C++ (which is not half bad if you don't try and use a braindead class library... ). Some things may be better in Java, or even sometimes FORTH... Who knows, it depends entirely on the problem!
People who are strong supporters one any one language are like carpenters who really like crowbars, so much so that they try to use them as hammers, saws, rulers, etc... and spend a very long time fighting with the wrong tool for the job. Needless to say, a carpenter that behaves like that is not a very efficient one, and not one you'd want to hire if you with to have your house completed in finite time.

use a language where it's appropriate

The author is restating an extremely valid point that is realized by most decent programmers: use a language where it is appropriate.

I learned python before perl, and thought it was one of the coolest languages around (still do), and for about a year, did all my scripting in it. Then I had to debug some perl code, and doing so, managed to teach myself some perl. After learnign a bit more, I said to myself "hey, perl rocks!", and then proceeded to script solely in perl for the next 6 months or so.

Then I started noticing how each had advantages in certain domains. Doing any sort of work with serious data structures in perl is annoying. Perl's pseudo-typing, and automatic flattening of lists (because lists can only hold scalars.. dontcha know), really makes it annoying to handle heirarchical data. You have to start using references, which makes code ugly and hard to read. Python is much more suited for that sort of thing.

On the other hand, doing stuff like traversing the the filesystem quickly, munging text, ad-hoc parsing, is extremely sweet in perl. Python is just too verbose when it comes to those kind of things. My home machine is littered with perl scripts that automate administrative tasks.

Use a language where it's fit, and dont take it personally when people point out that a language is not fit for particular task (they're usually right).

-Laxitive

Re:The world should use...

Latin is nice. Perl is nice. why settle for just one? :-) See Damian Conway's [monash.edu.au] incredible paper on Lingua::Romana::Perligata -- Perl for the XXI-imus Century [monash.edu.au]. You can fetch it from CPAN [cpan.org].

________________________________

NOMEN

Lingua::Romana::Perligata -- Perl in Latin

DESCRIPTIO

The Lingua::Romana::Perligata module makes it makes it possible to write Perl programs in Latin. (If you have to ask "Why?", then the answer probably won't make any sense to you either.)

The linguistic principles behind Perligata are described in: http://www.csse.monash.edu.au/~damian/papers/HTML/ Perligata.html [monash.edu.au]

The module is used at the start of the program, and installs a filter which allows the rest of the program to be written in (modified) Latin, as described in the accompanying documentation.

EXEMPLUM

#! /usr/bin/perl -w
use Lingua::Romana::Perligata;

adnota Illud Cribrum Eratothenis

maximum tum val inquementum tum biguttam tum stadium egresso scribe.
vestibulo perlegementum da meo maximo.
maximum tum novumversum egresso scribe.
da II tum maximum conscribementa meis listis.
dum damentum nexto listis decapitamentum fac sic
lista sic hoc tum nextum recidementum cis vannementa da listis.
next tum biguttam tum stadium tum nextum tum novumversum
scribe egresso.

cis.

SCRIPTOR

Damian Conway ([e-mail] [mailto])

IUS TRANSCRIBENDI

Copyright (c) 2000, Damian Conway. All Rights Reserved.

This module is free software. It may be used, redistributed and/or modified under the terms of the Perl Artistic License (see http://www.perl.com/perl/misc/Artistic.html [perl.com])

MUTATIONES IN EDITIO 0.01

Initial release.

ADITUS

Lingua::Romana::Perligata has been uploaded to the CPAN and is also available from:

http://www.csse.monash.edu.au/~damian/CPAN/Lingua- Romana-Perligata.tar.gz [monash.edu.au] _____________________

There you go. Isn't that a much saner, much more legible language? :-)

Learning More Langauges Solves This

I've always felt that the solution to all the language wars would be if people learned different programming languages preferrably from different programming paradigms. A Perl bigot wouldn't go on and on about how truly OO Perl was if he knew about SmallTalk and neither would a C bigot rhapsodize about C's text-handling abilities if given Perl.

The problem is narrow-minded programmers who learn 1 langauge or 1 paradigm (functional, Object Oriented, procedural, etc) and refuse to open their minds to any alternatives no matter how well suited they would be to solving the task at hand.

Remember people, programming languages are merely tools and like most tools they are good at performing specific tasks and not-so-good at performing other. A hammer is great at removing nails stuck in a wall but would be useless at unscrewing the back of your VCR. Use the right tool for the job and keep in mind that your favorite tool is not always the right one.

Grabel's Law

Operating Systems and other software

You know, the same can be said for operating systems. Replace the bit about strong typing, etc. with scheduling, etc. and it should sound familiar. I guess the point is that everybody's going to have a certain way about solving a task and they're going to have prefered tools for doing it. Suggesting alternatives or comparing the way one tool works to another often leads to feelings of criticism, even where none was intended.

Funny that scientists are supposed to be logical and objective when engaged in their work but I guess programming always has been a mixture of science and art.

-Jennifer

Re:The language must fit the problem

However, here is a problem. If you do not know what language fits the problem, then you are destined to work with a language that is less efficient at solving the problem (in terms of time, space, complexity, all of the above). Compare writing a parser in C vs. writing one in Perl, or writing set operations (from scratch, not the STL) vs. using the built-in language support of Pascal, or writing a thread-driven program using C vs. using the language-centric thread features of Java. There is give and take, and there is general programming languages vs. specialty programming languages. However, the only way to really know what a language offers is through advocacy. Now I'm not talking fanatical advocacy, but rather discussions about the merits of one language over another. Its all about give and take. Find the language with the features you need to solve the problem at hand.

I liked this answer about language advocacy...

...from the C++ faq.

In 99% of the cases, programming language selection is dominated by business considerations, not by technical considerations. Things that really end up mattering are things like availability of programming environment for the development machine, availability of runtime environment(s) for the deployment machine(s), licensing/legal issues of the runtime and/or development environments, availability of trained developers, availability of consulting services, and corporate culture/politics. These business considerations generally play a much greater role than compile time performance, runtime performance, static vs. dynamic typing, static vs. dynamic binding, etc.

Anyone who argues in favor of one language over another in a purely technical manner (i.e., who ignores the dominant business issues) exposes themself as a techie weenie, and deserves not to be heard.

Identification

... is the problem. When I hear a criticism of my favorite tool/platform/OS/political party/religion/thing, I immediately become defensive. Why? Because I chose the thing, so any criticism of the thing becomes a criticism of my own intelligence, judgement, values or beliefs. And the more I invest in the thing, the more likely I am to identify and take offense with criticisms directed toward it.

To paraphrase and extend the article's last point, this identification is not necessarily a bad thing. The problem is that many (most?) people don't handle criticism very well, no matter how constructive. So we get defensive reactions which beget counter-offensive criticism and we devolve into useless shouting matches.

Re:Language Advocacy Is Great!

That's right, I was comparing them. I've written equivalent programs in Scheme and Perl to try this out. Of course, when we're just talking about syntax, it's purely opinion-based anyhow, and Scheme basically just hides the references and does the work for you, here. I believe that the reason for this is because this functionality was bolted onto Perl later, in the spirit of adopting useful features from other languages.

In Scheme, you have to check what type something is. It isn't untyped, exactly, but you don't necessarily know what type a certain variable has until you check. If you don't check, bad things can happen. That's the disadvantage that this flexibility provides.

In Perl, you do the same thing for references, while other variable types are more explicit. I just wish those types had similar methods, but people have written this in too. (Since floats, ints and strings are all automatically converted in Perl, you have to basically write something to test if a string could also be a float or an int to see if it's a number originally. Unless there's another way to do it, of course. ;)

I have nothing against either Perl or Scheme; I like them both. In fact, I was thinking about writing a Scheme interpreter in Perl, since Perl natively supports the features that Scheme requires. I just have to figure out a clean way to parse it all. The other advantages would of course be the extra libraries; Perl has a lot of awesome pre-written tools that Scheme generally lacks. :)

So, yeah, this sort of advocacy is fine until someone takes it the wrong way, and instead of listening to the arguments, has their feelings hurt. And I think that's all the article proves in the first place.
---
pb Reply or e-mail; don't vaguely moderate [ncsu.edu].

As some old Texas politician used to say....

If English was good enough for Jesus, it should be good enough for everyone!

(I think it was some governor from about 30 years ago... can't remember his name - at any rate, it is funny.)

Advocacy

It seems to me that advocacy happens when people feel that they must protect an investment, whether of time, money, or emotion.

Example 1. It's 1986 You just spent $900.00 kitting yourself out with a Commodore 64, 1541 Disc Drive, RGB Monitor, etc. etc. You are bragging about your new purchase around the watercooler, when some smartass begins to enumerate a thousand reasons that the Apple ][ outclasses the C-64. In order to "protect your investment" (i.e. continue to feel good about the $900.00 you just blew), you become a Commodore advocate.

Example 2. You have spent 5 years of your professional career working with Microsoft products exclusively. As a Microsoft professional, you now have a substantial investment of time into the operating systems and software Microsoft produces. Whenever you can, you will be pimping M$ to the max because it helps keep your investment's value high.

I think this also becomes apparent on a bigger scale, for example in the election fiasco you yankees just went through. Did anyone at any time who had any influence at all break party lines and say that they other side had a more convincing or righteous argument? Of course not, every step of the way, be it lawyers, judges, members of congress, election supervisors, whatever - every person's behaviour was dictated 100% by party politics. This is similar to the type of "advocacy" that the article's author was talking about, I think.

My solution (at least in terms of operating systems and programming) is to try to cover as many bases as possible and keep an open mind.

Re:Language Advocacy Is Great!

When it comes to type systems, I like Scheme; it has a nice, clean type system. Perl can accomplish all the same nifty tricks as Scheme can, (it has closures, yay!) but you have to at least use a lot of references, and the syntax can get pretty grotty.

OK, this is not a flame. But I think your post basically proves why Mark Jason Dominus really has a point in his article, and then some.

You start with a compliment about Scheme and it's type system, then the very next statement is in the spirit of why something else sucks. Now, granted, you were waaaay gentler than many people are, but the kid gloves get dropped by the third iteration on most of these threads.

Your post also points out a second real problem with most advocacy debates: both sides define the terms however they please, often indiosyncratically. And then they proceed to talk past each other until somebody points out that this is what is happening, then they argue about whose definitions of terms are more appropriate...you get the picture. In this particular case, I would point out that somebody who was interested in type systems might be pretty confused by your description of scheme and its type system, since scheme is often considered to be basically untyped (certainly compared to ML, which comes up in the target article).

I think the only useful kind of advocacy probably takes the form of seeing what the language can actually do. I have learned things when, for example, I saw that two languages differ in their solutions to one kind of problem, and that one or the other might make better sense in the context of other problems you had to solve. Dominus goes on to point out that perl, notably but not uniquely among currently developed languages, owes many or most of its features to some kind of agglutinizing proccess like this.

Re:Language Advocacy Is Great! -- when done right.

I agree, but you could make that argument about *anything*. Politics, Religion, slashdot... It's great, until it becomes petty, irrational, vindictive, you name it.

Precisely so. I think your post supports what I read as the point of the article -- that language advocates can lose their objectivity and sense of proportion in the heat of battle. Language flame wars (even over brace vs. keyword) are interesting up to a point -- then those of us who haven't put too many chips on the table can go on to something else.

&ltofftopic&gt Speaking of politics, was I the only one struck in the now finished election by how reliably a person's preference in presidential candidate could be mapped to his or her attitude towards a manual recount? I'll admit I was one of those people -- I preferred Gore and thought there should be a hand recount.

Perhaps one or the other side was right, but the the infrequency with which people split their positions on this shows what a rare commodity fair mindedness is.

&lt/offtopic&gt

But what about compounded-advocacy?

Well... sort of. I'm going to be pretty straight forward here, because this is a forum where I suspect quite a lot of people are against the two things I will bring up here. And mostly because of their own advocacy for their own operating systems.

The type of advocacy the author is talking about usually takes the standpoint of denying all the other tools available to fulfill a particular job, even at the expense of the weilders time, energy, and sometimes money. But what of when the user is reacting with his advocacy to his own tools and languages to a person sharing what they use. Maybe not to convert the other person. For whatever reason. Is it just straight out flaming that results when the person forces their own advocratic responses at the newcomer, or is it something more serious which needs to be addressed? I think this is much more of a problem than advocacy as presented by the article in question.

Case study 1: (shudder) Visual Basic. I dont shudder because of the language. I shudder because of all the advocacy going through the minds of a lot of the people reading (or not reading) this post. Visual basic is supposedly bloatware at its finest (or worst), it runs on and only compiles for Microsoft Windows, which is unacceptable to some people. But Visual Basic is, believe it or not, quite useful. Quite comparative to java, in a lot of aspects, because of speed, RAD and other useful features. For someone developing for windows, wanting the application quickly and easily without regard to speed, its invaluable. Yet time and time again, I see it shot down, flame, and torn to pieces. And its especially common among linux crowds.

Case Study 2: OS
I use windows. Sometimes. I find it a useful, fun, and enjoyable experience. Yes. I LIKE windows, and am not lying. Yet merely voicing any of its strong points is liable to bring me under a barrage of fire, filled with other peoples advocacy for other operating systems. And its not just Linux people, its NT people too, to exactly the same extent, they scream "Windows 2000 is solid", while hurling insults to my intelligence for choosing linux as my preferred operating system. Yes. My preferred operating system is Linux, even though I LIKE windows.

So what can we do about this? There has to be some way that we as a community can respond responsibly to this sort of thing as a whole. Or maybe its better off responded to individually.

---

Language Advocacy Is Great!

If it weren't for language advocacy, I wouldn't find out nearly as many cool things about programming languages.

Everyone has their pet peeves, and their favorite features, and usually they have reasons for it. For instance, I don't like Java; I think it's unnecessarily bloated, contrived, and non-intuitive. So when someone showed me how simple it was to make a little GUI app, (far simpler than the text version, I might add) I was suitably impressed. I still hate Java, but I have a better idea of where it should be used, and what it can do, thanks to that advocacy.

When it comes to type systems, I like Scheme; it has a nice, clean type system. Perl can accomplish all the same nifty tricks as Scheme can, (it has closures, yay!) but you have to at least use a lot of references, and the syntax can get pretty grotty.

I used Pascal for a long time, and a decent programmer often spends a lot of time getting around the Strong Typing--it interferes with what they actually want to do a *lot*, like when they want to create a dynamic arry, for example. C at least doesn't bug you about it, but they can both pretty much accomplish the same things. I can't stand the Java type system; they definitely broke the notion of what should be an Object or not.

But that's just my opinion, and it doesn't stand in my way when I'm looking for a tool. Lately, I've been writing in C, because I've been doing Operating Systems programming for class, on Unix, in C, and it works quite well. But when I was doing web development and system administration this summer, I learned Perl and PHP, and it was far less work for what I was doing at the time. I also got to see how much work it is to implement a complex CGI in C, and although I think it'd be a neat experiment, I'd start out writing it in Perl, thankyouverymuch. I haven't had to use Java because I haven't done any real GUI programming, but I might try it out just because the API looks a little cleaner than some other GUI APIs I've seen. (I'm not about to write in straight XLib yet; even "Hello World" is huge!)

So yes, do your advocacy. Tell people which tools you like, and tell them why. Pick the right tool for the job. I don't think these things have to be incompatible. Just try to stay rational about it; that's why Linux has an Advocacy-HOWTO. When done right, it really isn't bad at all, it's quite informative, actually. :)
---
pb Reply or e-mail; don't vaguely moderate [ncsu.edu].

You Are Not A Member

The Slashdot Tribe is voting you out.

(I wonder in how many years will "vote out of tribe" not be recognizable in the same way that "drink the Kool-Aid" is not recognizable by people who don't know the news story behind it)

Re:Advocacy

1. Thou shalt not GOTO

2. GO TO 1

--

Advocacy CAN be OK -- Why Mark-Jason Hates It

I'm seeing a common misconception of the article in a lot of posts here: that all advocacy is bad.

The author says, at the end of the article:

I don't really hate advocacy. I just hate the way we do it most of the time.

The article is not against advocating things. The article is about people's bad "discursive habits" -- the way we tend to discuss things. The author, for example, is not against discussing the advantages of the typing system in Standard ML. What the article *is* about is the curious fact that most people can't seem to do advocacy right.

We do it in a dumb way. And I think the discoursive habits we pick up as a result are going to impede the progress of programming languages for a long time.

And the progress of a lot of things. I wish more people understood this.

I Know How He Feels

I am a user of many languages and I've been in the field for a couple of decades. In my current company just about any combination of OS's and development tools that you can think of is in use somewhere.

Currently, I am digging into the beta release of Visual Studio.Net. All in all, I find the package very compelling. In particular, I find the concept of shared framework across many languages unified by common debugers and a single runtime to be a fascinating concept.

I've tried to enter into a dialog with both Java developers and a group that does C++ on Unix. I'd love to have an intelligent conversation on the merits of the dotnet approach vs. the direction of other areas of software development.

Unfortunately, the conversations have to get past "MS Sucks". They seldom do.

Kuro5hin article

There's an recent article on Kuro5hin [kuro5hin.org] about fear of XHTML. The most relevent thing in it is how people will violently stick to what they know. They learned to use font tags instead of CSS, and so they like it that way. They fear that their pages will not work in the future, and they fear that they can't do the same things in XHTML as in HTML.

This is an example of how advocacy (in this case HTML over XHTML/CSS) is very bad for everyone involved. People do not want to leave HTML, so parsers will have to continue to be complex. Browser incomatibilities will widen even more.

I often see this kind of thing. A new standard comes out, and it solves more problems than before, but there is this inertia on the existing standard. It's almost as if people decide that they have learned enough for them to retire on.

It's all tribalism

I think Mr. Dominus hit the nail on the head when he said, "the root of the problem is that we tend to organize ourselves into tribes."

I suspect this is a deeply rooted social instinct to become part of a group, support the group and have the group support you. Possibly, from the time when humans associated themselves with a family unit and vied for resources among other such units. And attacking other groups meant a greater portion of the pie for your own group, more support for yourself, and more acceptance from within your own group.

Slashdot is one such group. Why do the Microsoft-related stories routinely attract postings that number in the five or six hundred range? It all has to do with how we define our tribe.

Is it a bad thing? I think it is, when it starts to obscure the fact that we are all part of a tribe called "the human race."

--

Many Tools In The Toolbox

This article touches on a number of good points. A read all the way will do all of us good. I like to think of the problem as a toolbox. You can get a screw in with a hammer, but a screw driver will do a much better job. Just as you can get a nail in with a screw driver (by bashing it in with the handle... which I've done when there IS no hammer around), but a hammer will do a much better job.

I like to think of programming languages in much the same way. The best programmers have many tools they can draw from and understand the strengths and weaknesses of each for a given task... making it alot easier to use the best tool for a particular job.

The best programmers don't think of themselves as VB programmers or Perl programmers or the like... they just think of themselves as programmers.