Do Scripters Suffer Discrimination?

TheTheologian writes "In his InfoWorld column, Chad Dickerson says 'there is a level of quiet discomfort between the "scripting" versus "programming" factions in some corporate development environments in which I have participated. In some instances, executive-level technology management has held scripting languages in disdain as not being "real" languages for day-to-day problem solving, which has discouraged highly talented scripters on staff from practicing their craft. In such an environment, scripters are relegated to the lower ranks ... ' He goes on to say that some companies will assign Java and C++ programmers tasks that take them weeks but could be done by Perl or Python programmers in a few hours. Is it true that some companies are so overcome with code bias they'd assign weeks of unnecessary work rather than give it to the scripting untouchables?"

Comments

Yes

[OneStepFromElysium]

Yes, often scripters are biased against.

No, it is not fair.

Programming is programming; solving problems is solving problems. What tool you use is just as pointless of a reason to express bigotry as the color of one's skin or one's gender is.

On the contrary -

[Sabu mark]

- many in my company believe that scripting languages are often more suitable for all applications except those where processing power or speed is absolutely critical. The added performance overhead is paltry compared to the development overhead involved in writing code to the more exacting specifications of compiled languages.

IT's called a standard

[TedTschopp]

At the very large company I work for there are standards. And if they were followed we wouldn't be in the trouble we are in now with over 16 different databases, 24 different programming languages, 8 different OS's.

The reason a company wants you to develop in Java or C++/C or whatever is to maintain the standard, do you have any idea how much money is going to have to be spent to maintain the employee knowledge to support so many different databses, OS, Languages, etc...

That's what standards address. Now the real question is what is the process to create a diviation from the standard, and is it justified?

Thats what this questino should address.

Ted

Re:IT's called a standard

[Sebastopol]

No kidding!

We had an intern who wrote a bunch of stuff in Python and Ruby. He was all gung-ho on those languages and made a big deal about how they were "it". When he left, no one had the time to learn how to support these languages, so we ended up re-writing them in Perl so that everyone could support them.

FYI: his scripts sucked, too. He'd make lots of dumb mistakes like assigning a variable called "retval" and then checking "ret"!!! Duh. gcc would have caught this immediately, so would "use strict".

Wrong Person, Not Language

[Washizu]

Typically these jobs that take weeks instead of hours are assigned to the wrong people, not the wrong language. The right person should figure out the best solution for the problem and tackle the problem correctly. The wrong person will go after it in his favorite language and ignore the best way if it includes any amount of work before he begins coding.

Re:Wrong Person, Not Language

[aridhol]

That doesn't work if The Powers that Be have decided on a solution ahead of time. If TPtB decide that you must use an in-house language that takes a few thousand lines to code what Perl can do in a few dozen, you can't use the right tool. You have to do what TPtB and the PHB have decreed.

Mountains and molehills..

[k98sven]

Call that "discrimination" is hardly justified,
what it most likely is, is good old managerial incompetence,
perhaps with a dashing of conservatism as well.

Anyone who claims that one programming language is superior for all and any purpose is obviously incompetent to make such decisions.

Personally, I wouldn't stay long at a company like that. Unfortunately these kinds of things are very, very, common. Bosses know one way of doing things, and they want it done that way, no matter if its not a good way or not.

Re:Mountains and molehills..

[Gallifrey]

I think you're over symplifying. Managers realize that the more different languages are used means that, most likely, the harder future support becomes. Instead of just giving the programmers free range in what language they should use, two or three languages should be selected that provide good coverage of various functionality, and development should be limited to those languages.

I've worked places where the developers use whatever language they want. Guess what? Every time one of the developers leaves, their stuff gets rewritten since no one else likes their choice of language. That's not good business.

The title of idiot manager should not be placed on anyone that wants to reduce the choices of the developers. Instead, it should be placed on managers that don't recognize that at least more than one language will be needed and force everyone into C++. Unfortunatly, it seems that if management makes a decision that limits the "freedom" of the developers, they are labeled idiots irregardless if their decision makes sense business-wise.

Use BOTH!

[wowbagger]

On a project I designed, I deliberately designed the system to have TCL built-in, for a very simple reason.

Scripting has its place, as does more conventional compiled code.

Use compiled code to do the heavy lifting - in my case, things like FFTs, signal analysis, and such.

Use scripting to tie it all together.

That way, when you are trying to figure out the problem domain ("Now, what does the radio expect me to do when it sends a GTC message - maybe it wants a CASSN message? Clicky-click - No, doesn't seem to be it. Maybe a IDN message? Yep - that's it.") you can try things out very quickly.

You can also very quickly string together smaller functions into larger blocks ("Ok, to test the radio, first I do this, then that, then the other.")

I cannot even begin to imagine how long simple things would take if we didn't have an embedded scripting language.

All in how you say it.

[grub]

"I am good at scripting." == lame.
"ph34r my l337 skr197x0r sk1llz, f44g0rz." == cool.

Certainly

[kafka93]

I don't know about 'weeks', but there's little doubt in my mind that tasks are often assigned to C or other 'proper' languages that could more easily be tackled with a so-called scripting language. Whether this comes down to 'prejudice' or mere ignorance to the potential of perl and the like is open to question.

And, without wishing to develop too much of a flamewar, this same issue comes up -- more frequently, even -- with the battle between 'traditional' web development languages that use CGI -- notably perl and C -- and more modern languages like PHP, ASP, etc. It's my view that a truly experienced and effective developer, whatever the particular circumstances or decisons to be made, will be sufficiently open-minded to consider multiple alternatives: those who show a propensity for platform elitism, or for discounting certain solutions out of hand, often seem to prove poor developers - for the very reason that they show a lack of imagination, an unwillingness to consider different options, and so forth.

Also, people often only consider one side of the equation -- and it's the least important side: the particular language used often has vastly less impact upon the success of a development than does the ability of the developer to write clean code, to think in a sensible fashion -- and to get a *full* picture of what's going on. Take Slashdot -- perl-driven, perhaps, and working reasonably well in its way -- but betraying a lack of understanding of modern web development techniques such as the use of XHTML/CSS in place of kludgy tables and the like.

Long story short: the language won't make the difference, and the developer or manager who thinks it will is deluded -- and will pay for it in the long term.

I guess I am biased against scripters as well...

[shodson]

I guess I would be labelled as biased as well. Scripters often are talented, home-grown and self-taught but true enterprise systems require more enterprise-capable features and capabilities offered by RDBMSs, tranaction coordinators, asynchrnouse messaging, distributed computing, etc. I'm sure some or all of those things can be accomplished with scripts as well but vendors and products in these categories tend to API their products to programmers (Java, C++, .NET)

Also, I find scripts like Perl/PHP/ASP and other harder to maintain for larger projects. And, if the original scripter is fired/laid off how much easier is it for a new scripter to jump in and successfully maintain that code base? I think people in OOP-land work really hard to creating standards and methodologies that make code maintainable over the long haul (just attend an OOPSLA conference some time).

As far as hiring biases, it depends. I've seen people hire scripters because they can get their site up just as good or even better than a programmer. That works great in small organizations, but if you are working on products with 100+ developers then scripting becomes pretty painful, hirers of large teams would probably rather like to stick with tradidional business development tools, languages, platforms, products, etc.

Flame away...

Does the end user know the difference?

[aardwolf204]

10 Echo Starting Application
20 system "start iexplore -k http://localhost/index.php"
30 goto 10
40 profit

Re:my belief

[kiolbasa]

Sounds good, but I'd break it down more specifically: Scripting is interfacing, tying things together on a higher level. Programming is functionality, algorithms and such. This still has nothing to do with language choice, as many languages can handle both to a degree.

Re:Oh please!

[smallpaul]

Any such distinction between them is better explained along the software programmer versus system admin dimension (programmers do more programming, admins more scripting).

That's the misunderstanding that leads to problems. Scripting is programming and scripting languages can be used for software programming. I mean are you going to say that the task of building slashdot is "system administration" not "programming"?

scripting "cowboys"

[Wolfgar]

There are multiple facets to why scripting is descriminated against. Some of it is justified and some is not.

For starters, the biggest myth of scripting languages is that they don't perform well. The bottom line is that there are very few applications where the overhead of the scripting language is going to outweigh the performance cost of a bad design or poorly written code.

That said, the biggest problem with scripting languages is that they are so easy to use. The tends to create a coding cowboy type environment where folks solve a problem really quickly in a script but that script is never kept in version control, or it is written in a language that noone else in the company is trained to use, or it contains hard coded entries for database passwords, or there are hundreds of scripts and it becomes a nightmare to make a change to the way things work because the scripts don't share any codebase...

Note that none of the above problems are the fault of the scripting language. They are more the fault of developers abusing them. In a sense, scripting languages leave a lot of rope for folks to hang themselves with. And because lots of folks do hang themselves with them, there is a lot of ammunition that people can use to spread FUD on scripting languages.

But perhaps most importantly, there is this goofy thing called human nature. For some reason, we silly humans are easily duped into thinking that "you get what you pay for". It's marketing/sales 101, and it happens all over the place. For example, if you see two bottles of wine, one for $2 and another for $20, odds are that most people will be convinced that the $20 bottle is a better wine, even though there is no evidence whatsoever to base that decision on.

Well, scripting languages are typically free, so the natural inclination of people is to think that they aren't as good as products for languages that sell for tens or hundreds of thousands of dollars. Unfortunately, I don't see this ever really changing, but then I've never been accused of being an optimist...

PHP scripting/coding/whatever

[Ron Harwood]

I have written a web-application (game) in PHP... and a friend who is a java snob (he feels no other language is worthwhile any more... and I have to listen to it... :P) constantly is saying thing like "well in java - that problem doesn't exist because [insert long winded arrogance]", or "loose types are a short path to hell - and that's where you're headed with PHP" and "PHP isn't a real language anyway - no one would use it at an enterprise level"...

Pointing out that Yahoo is now using it as their default language - and that Rasmus (author of PHP) actually was hired by Yahoo as a result is simply dismissed as bad judgement on their part.

It's like arguing religion or politics... :P

So I just sit back and listen to the tirade - and try not to egg him on...

Re:PHP scripting/coding/whatever

[Anonymous Coward]

It just astounds me that anyone can be snobby about Java. I mean, it's not a terrible language, but...

The problem isn't the language, or anything remotely to do with programming. The problem is that most programmers are as arrogant as all get out. They find something they like, and because they are convinced that everyone is their intellectual inferior, they need to point out the error of their ways.

Re:PHP scripting/coding/whatever

[MikeFM]

The problem is programmers that are insecure because they aren't confident in their ability to move between languages as needed. Programmers usually have their favorite tools for any given job but the ones that get really nasty are the programmers that are only comfortable with the few tools they use.

For me I'm pretty confident in my ability so I can move between any language that exists or is just invented as the job goes along (happens sometimes) so I don't especially get snotty. Python is one of my favorites but it certainly isn't perfect. I have done a lot in PHP but have grown unhappy with it for large projects. It is good for small to medium sized projects. Java is okay for programs that are going to run on servers with lots of memory and that won't be restarting the program often but is to heavy for most of the things I do. C/C++/Asm are good for low level stuff that needs to be fast but IMO should not be used for the bulk of things they get used for.

Re:Yes

[Purificator]

i even see bias within scripters (e.g., perl scripters are higher up the ranks than bourne scripters).

in a lot of cases this bias is justified: shell scripts have more portability problems as, say, the location and vendor for awk differs from system to system, or the behavior of "echo -n" changes. this carries over to, say, C vs perl as well: in most cases a C program will run faster with a lighter footprint than a perl script, so when either of those are a big concern then how you solve the problem is as important as the fact that you solved it.

i'm afraid i share the bias for this reason. i think you should pick the right tool for the job, not just do everything in perl because you're a "perl guy" (or a "C++ guy," for that matter). sometimes that means spending weeks writing a program in C that you could do in a few days with perl.

I disagree 100%

[Ender Ryan]

I've done my fair share of Perl, C, C++, Java, etc. programming, and I have to call BS on your comment.

There may still be a small amount of truth to what you said, however, modern scripting languages are every bit as maintainable as C, C++, or Java. In fact, an incompetent C programmer probably is the most likely to create unmaintainable code, as scripting languages require less total code, and therefore it's easier to absorb quickly.

Most scripting languages are designed around letting small problems be implemented quickly.

True, but most scripting languages that are still widely used today have evolved beyond that.

But in any case, you're certainly correct that they each have their place.

Cheers.

Re:I disagree 100%

[martyros]

There may still be a small amount of truth to what you said, however, modern scripting languages are every bit as maintainable as C, C++, or Java. In fact, an incompetent C programmer probably is the most likely to create unmaintainable code, as scripting languages require less total code, and therefore it's easier to absorb quickly.

What do you mean 'maintainable'? Sure, an incompetent programmer can screw up the best languages. But the programming languages aren't designed to help incompetent programmers -- they're designed to help competent ones. I remember reading about a study done in the 80's that suggested that experienced coders wrote as many bugs as inexperienced ones -- they just found more of them before the ship date.

With that in mind, there's a hierarchy of places that bugs exhibit themselves, going from good to bad. The best bugs don't get written; the next best are caught at compile time. After that, are bugs which cause the program to crash immediately (fail-stop) and the worst are bugs that cause random, non-evident behavior much later down the road. Anything you can do to push errors up the hierarchy will make programs easier to debug and maintain. Hence strong typing languages, OO, things like that.

Sure, all decent languages have comments, functions, ways to structure the code that make it somewhat easy to read. But last time I checked (which was a while, granted) Perl didn't have strong type checking to make sure you didn't pass the wrong kind of thing to a function. You have a handful of data types that do everything; it doesn't allow you to make assumptions about what other bits of code are/aren't doing, as you can with a properly-organized strongly-typed language. That's the next step in maintainability -- partitioning the thing into littler bits and making sure they work right, and moving errors up the hierarchy to compile-time errors.

Re:I disagree 100%

[Anonymous Coward]

modern scripting languages are every bit as maintainable as C, C++, or Java.

Maybe not quite true for Perl, but for Python, this is an understatement.

I've never seen code written in any low-level lanugage, much less in Java (!) that was half as readable as the equivalent code written in python

The only real disadvantage of interpreted/scripting languages is raw power. They are just a greater abstraction from pure machine code than lower level languages like C, etc., which are themselves abstractions from that machine code.

Yes, scripters get short shrift

[jlusk4]

A topic near and dear to my heart.

In places I've worked, the CM system (build, defect-tracking, patching, etc.) was written in scripting languages.

The people who worked on it were never really considered to be "developers", even though the systems could have benefitted from requirements analysis, design and code review and modular development practices. That had two effects: the good software engineers who were scripters got frustrated, and the crappy hackers were able to slam in crappy code that worked fine but was fragile and hard to maintain.

It's even easier to produce crap w/a scripting language than w/a compiled, statically-typed language. (Not that you can't produce crap with C/C++, don't get me wrong.) This ties in w/the preceding paragraph, but it's also a good standalone point -- w/out rigorous code review, Bad Stuff is going to accumulate more rapidly on the script side.

That might be more a reflection of people's attitudes towards the kind of work that gets done w/scripting languages (quick-n-dirty) than a reflection of attitudes toward the programmers who do the work.

Re:Legitimate concern

[Guppy06]

"Most scripting languages are designed around letting small problems be implemented quickly."

Isn't that the core philosophy of Microsoft's Windows Update service?

Don't blame the intern!

[Beetjebrak]

Why did you let an intern deviate from company standards??? I don't blame the guy/gal for being a beginner and thus writing "sucky" scripts in whatever language. But you guys have been so plain DUMB for letting the intern go ahead with Python and Ruby knowing full well that you couldn't support these languages. It's sometimes too easy to just blame the intern... YOU (experienced script guru familiar with company policy) should have instructed him/her (fresh out of school newbie) to use Perl and nothing else. And if that weren't an option, why did you hire this intern in the first place?

Re:Flip side

[repetty]

"If it ain't compiled into assembly language, it ain't real programming."

Interesting definition. My distinction has always been that if I can fuck up memory, then I'm programming. Otherwise I'm scripting.

--Richard

Supportability

[johndeaux]

I have dazzled many enterprises in an emergency by delivering Perl scripts in hours or days that do amazing things. BUT once the emergency was addressed and they began to look under the hood and saw it was Perl script they had me re-engineer it in C++ or Java (weeks to develop...) because they had no one on staff (besides me) that could support the Perl. They spent the money for the increased amount of time for development to reduce cost in long term support.

God is in the chip tracings

[theCat]

It seems like the deeper you have to go to get something to work the more immaculate you are. Like everyone is hovering somewhere above laying down silicon, the further away from tracings and transistors the less holy.

In this regard machine language programmers spank assembly coders, who spank compiler builders, who spank those who use compiled lanagues, who in turn spank scripters, who would spank spreadsheet macro writers if those people ever came to the party. Of course everyone is aiming at getting particular patterns of electrical potentials established across specific etched wires and via arrays of transistor gates. But some of us are closer to God and everyone knows it.

I figure it is just like any other religion. Closest to God are the self-flagellators, ascetics and grazers, those who abuse the flesh and the mind in order to get to the bare naked truth of God. They would dream in machine code but speak not a word anyone could understand, just mumble. Then the mendicant monks and wild holy men, clinging at the gates of the city, begging alms, pitifully beseeching to God; assemblers. Less mentally scattered beggers with pens would write very terse, almost insane ramblings about how the world is actually made, their searing visions what we would call compilers. Those who would actually take those insane ramblings and teach them as a path to truth? They use languages that rely on the compilers and most people would call them preachers and spiritual leaders and merely pity the others, if not fear them.

I take my religion easily. I don't preach, and I am not a missionary; nobody is gonna be saved by me anytime soon. I conduct the rare bit of working sorcery, often for personal gain but not always, and my relationship with God (or Goddess as the case may be) is functional and laid-back (obviously). And I'm a scripter. I code to please myself as well as the higher powers. Mostly myself. If it works, groovy God is happy too. Hey I got other things to do besides obssess about Truth and my navel, OK?

It's those Nancy boys writing spreadsheet macros that are wasting their time. Rookies. ;-)