Slashdot Mirror
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?"
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.
- 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.
What Would Jesus Do
(for a Klondike bar)?
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
Fantasy remains a human right; we make in our measure and in our derivative mode... -- JRR Tolkien
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.
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.
www.eFax.com are spammers
Scripter, programmer what's the difference? The thought process is the same whether you are using cshell, java, assembler or any other programming tool. This is like saying that speaking another language will make a difference in mathematics.
UNIX/Linux Consulting
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.
When you are building a software application, you try to get everything synchronized, so all programmers will be able to understand and feel confident in each other's code.
Many times programmers, in charge of maintenance, have had to search through code only to find the bug related to a script which does not follow the norm of the project.
Therefore, in a serious project, with millions invested, scripting can be a dangerous shortcut that may plague the project a year later.
My point is not that scripting is a waste of time or an unneccesary technique, since it can indeed be useful, but it is likely that an average manager's gut instinct to avoid the technique unless it is the only way to achieve something, because the more it's intermixed with C or Java code, the less standardized the project becomes.
A concept may be easier to express in Chinese, but you don't see many novels written in English with Chinese added here and there. Uniformity often leads to quality.
"I only speak the truth"
Karma: null(Mostly affected by an unassigned variable)
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.
I can't say that I don't give a fuck. I've just run out of fuck to give.
but often scripts are seen as quick and dirty solutions to problems that should have been solved by the inital program. Not to mention documentation, scripting is SO free form that it often intimidates management...
errr....umm...*whooosh* *whoosh* Is this thing on ?
And the "right" language is not just a technical question. If the company only has Java, VB, and COBOL experience and the permanent staff isn't very flexible, the right language probably isn't perl, no matter what the problem is.
On the other hand I've worked in companies that could grok any language. We even made them up when we needed to.
Joe
Joe Batt Solid Design
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...
I'd have to say that that's a legitimate concern.
Most programming languages are designed around keeping a codebase usable even at large sizes.
Most scripting languages are designed around letting small problems be implemented quickly.
They each have a place. Using one in the place of the other really is a bad idea.
May we never see th
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.
Beer wants to be free
There really is a difference between scripting and programming. Scripting languages tend to be heavily dependent on compiled code. Where would perl be today if all the modules had to be written in perl? Instead, getting a module from CPAN, there's a good chance you are actually getting C code and a perl wrapper.
Another difference: type safety, programming languages have more stuff being caught at compile time than in runtime, then scripting languages like perl do.
Another differene: scripting languages make the common things easier, while programming languages opt for generality and extensibility. Compare writing to a file in perl, versus Java.
There are indeed differences. But that doesn't mean one is better than the other. I remember a joke that circulated around the internet about the evolution of a programmer. In the beginning was the beginning programmer with "10 HELLO WORLD". Then came C, with #include's, a main function that printed "hello world", etc. Then C++ with a #includes, a class, a main function. Then came COM with about 5 pages of code dedicated to making a COM service that outputted "hello world". Finally, the last stage, a grand master programmer: "10 HELLO WORLD".
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"?
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...
C is not a scripting language, because the end result, after compiling and linking, is an executable that can be run by the OS w/o a separate runtime (I'm including linked-in runtimes, such as the old dbase runtime kit, as 'separate', b/c the end result still goes thru the run-time interpreter).
Oh, and assembler is not 100,000 times harder to code. I actually found perl made me cross-eyed for quite a while before I grokked the mind-set behind it, and now I use it whenever I need a quick-and-dirty script to fetch some data, process it, and give me the results.
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.
"Mister Potato-head --MISTER POTATO-HEAD! Backdoors are not secrets!" (War Games, 1983)
To the untrained eye, perl looks like line noise, and may be rather difficult to maintain.
To the untrained eye, English doesn't make any sense. When hiring someone to maintain Perl scripts, one should look for the trained eye, yes?
I live ze unknown. I love ze unknown. I am ze unknown.
Of course, some people who specialize in scripting DO know the lower levels too, and thus the law doesn't apply to them, but many people whose jobs rely around scripting activities would be stuck if their abstractions leaked...
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.
Sticking feathers up your butt does not make you a chicken - Tyler Durden
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.
A quick aside: I HATE the term "scripting", as if it were some degenerate form of "real programming" - especially with feature-rich languages like perl that never have to call other applications.
Anyway, first-hand experience: thanks to the concept of perl modules and the incredible CPAN archive, writing applications that have to go to the network for things like HTTP or (especially) LDAP are trivial in perl but seriously heavy lifting in C.
You also get string parsing, regular expressions, and garbage collection built right in. Not to mention the incredibly powerful (from a code legibility standpoint) associative array or "hash" data structure.
Believe it or not, correctly written perl is orders of magnitude more legible than C or Java, because it works at a higher level of abstraction.
I wrote an LDAP->LDAP replication program, with schema and data format translation, in a couple of hours using perl.
Doing stuff like comparing the contents of a database dump (provided as a CSV) against an LDAP directory is trivial in perl.
C is best used when you won't have a perl environment availible and need the binary to stand alone. For pretty much every other task I've encountered in the last 6 years, perl got the job done faster and with much better maintainability.
DG
Want to learn about race cars? Read my Book
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?
Learn from the mistakes of others. There isn't enough time to make them all yourself.
The problem I run into with scripting (and indeed, other languages) is that I am one of three programmers at my business and the most experienced in a diverse number of languages, both programming and scripting. I try to use the right tool for the job....Perl for quick string manipulation, handling webpages, PowerScript to ease the pain of banal Windows programming, Visual C++ to handle the lower-level, API-humping apps, and pure C to do fast work when I need speed.
However, it has come around to bite me on the ass. For instance, I am the only programmer that knows Perl. As good as the tool may be, the company now regards me as an enigma -- something to be dealt with by procedure, policy, and backups. I am now being forced to document my code to a level at which a non-programmer could figure out what's going on and stumble through it. The same with the IDEs (if applicable). My code was well-documented and written before, any competant programmer should be able to pick it up. I am not being forced to do this for languages for which we have other people that know them...just the ones I am the sole intellect on.
So, as a warning to all of you trying to use your scripting or programming abilities for the good of your job. Good idea. But watch your ass or you'll end up writing n00b manuals for the rest of your days.
Blog,Twitter
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.
Er, no. Java is compiled into an intermediate form, just like every other scripting language such as Perl, Python, etc. Calling that "machine code" shows an ignorance of programming in real assembly language. Java bytecodes are just a numeric version of the Java language.
Wrong, wrong, wrong.
First, your precious native-code compilers compile into an intermediate language as well. No modern CPU runs a program as-is -- they all have tricks like microcode, out-of-order execution, register renaming, and other hand-waving that make the actual program run by the CPU quite different than the one sitting on your disk. I'm sure "that's different" for some reason, of course.
Second, Java bytecodes are a machine language. Admittedly, no 100% complete implementation of the machine in question exists, but I fail to see how that makes a difference. Are you saying that if I extended the picoJava CPU core to natively handle the last few instructions that are currently emulated, suddenly Java would switch from being a "scripting language" to a "real language"? That's asinine.
That's the primary reason that Java is so slow. The bytecodes cannot be efficiently interpreted.
The primary reason Java is "so slow" is that most of the people claiming that haven't used it in years. Java 1.4.1 is pretty damned fast as I see it. The other reason that Java is seen as slow is that its GUI libraries are not as fast as the native libraries. That doesn't have a thing to do with bytecodes, but rather with how they were designed.
There is nothing special about bytecodes that makes them any more difficult to run efficiently than any other programming language. In fact, they open the door to a lot of optimizations that are all-but-impossible with other languages.
There are things in Java that will NEVER allow Java to be useful as a general purpose language. The lack of an unsigned datatype is probably the most egregious flaw.
The only reason that unsigned datatypes matter one iota is in interfacing with someone else's code that does use an unsigned datatype, in which case nasty conversions must be done. If you don't need to interface with such code, you find that they are completely unnecessary. I fail to see how that is such a serious flaw.
I'm not saying "Java is the bestest language EVAR!!!", but please get your criticisms right.
ZFS: because love is never having to say fsck
After all, if technology selection was rational, everyone would be using Lisp or Smalltalk.
That is all.
Anyone worth their salt should be able to code in either scripting languages or compiled languages. If they can only handle a few scripting languages like Perl or Visual Basic then of course they should be discriminated against. They're 'real' programmers, sure, they're also bad programmers.
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.
No see, what the hell is this? Why couldn't a Java or C++ coder write the same Perl or Python script? If Python is a better solution, you should bring it up with your boss. If they don't go for it spend the extra time and collect the extra cash (assuming your hourly)
And secondly, I seriously doubt that a Python program could be written in hours that would take weeks in java, unless the coders are completely incompetent. Java has a rich API and is pretty easy to use.
autopr0n is like, down and stuff.
Dickerson wrote:
There is no such thing as an "unstructured textual document".
The person who finishes "first" does not always produce the "best" program.
What are you going to do in a year when all the developers are gone, and you need to update the program for some reason?
If you're going to create situations where your pet language will win, let's talk VSAM file manipulation. :]
Finally, as Dickerson seemingly fails to understand, choice of language should be as close to the programming staff as possible, not with the buzzword-laden clueless managers.
Karma: Food Fight (Mostly affected by Date Plate).
I make these comments from the business world, not so much what you do on your off days or as an academic excercise.
So with that, here begins my tirade:
In the 21st century, languages for business have to meet the following criteria. If your company is using a language that doesn't meet this criteria, you are in trouble, and probably don't know it.
Why? Because more than likely your competitor is using a language that does meet the following criteria, and you soon won't be in business.
As a past CIO, now a CEO, I won't get technical, I will just ask these criteria in the form of a series of questions. If you run a company, it is going to become clear, which language and OS you should be using by the end of the article.
Here are those requirements:
1) Software your business invests in, and owns outright is an Asset, not an expense. Obviously this doesn't include any shrink wrap software.
Interesting point isn't it?
If you build software or buy it, and toss it out the window because you change hardware platforms or upgrade because your vendor says you have to, you are bearing costs that you don't have to bear, and are throwing your money away.
I gurantee your competitor won't make the same mistake, because one of my sales people will be explaining it too them real clear like on the telephone.
More than likely, because you didn't want to listen.
2) Software is not only an asset, but it is your intellectual property which represents a unique way on how you run your business.
Software enables this idea. Good ideas are unique, not commodities. When a good idea is applied to a business process, you do more with fewer people, less money and out manuver your competitors as a result in price and service.
Software built by companies who acknowledge that software is an asset, also understand it is an investment that is to be protected and furthermore acknowledge that as part of the IP capital of the business, represents something a competitor can't BUY ANYWHERE ELSE.
So with these two points in mind, think about these little diddies
Why would I buy SAP for example, and Windows 2000, when my competitor can buy the exact same thing?
What does buying a business process API that anyone else can buy get me? Does it give my business an edge over my competitors if they can buy the same consultants and produce the exact same thing for my competitors?
Why? Why not?
If Joe Tool and Die down the street can choose a Shrink wrap software desktop/server system for File/Print and Office Suite from Company A, and I can do the same thing for my end users if I use the exact same.
What does that get me? Am I beating Joe Tool and Die down the street following his every move?
Can I somehow make or modify shrink wrap Office Suite Word Processor A, for example, to the point it can make me a unique business process as I invest money and time into growing my infrastructure that my competitor can't duplicate in a way that makes me more money than who my competitor is?
Especially if Joe Tool and Die decides to woo some of my IT people away from me?
Can I modify File and Print server shrink wrap software from company A for my users in such a way that my competitor can't, that saves me money?
Or perhaps, something my competitor can't buy off the shelf and do the same by adding it to company A's file and print server software?
If Joe Tool and Die can't own his software A, but I can own my own software B.
What does that get me?
Does that give me an advantage over my competitor if both sets of software have the exact same features, yet I can modify A and Joe can't modify B without a License?
Company A has As/400's and Company B has Sun/PC hardware and decides to merge with company A, yet it is decided that company A's software is the real advantage to merging with B.
If A has to totally scrap its As/400's to rewrite its software on Company B's Suns/PC's, what does that do to the shareholder value of the merger?
What would have happened if Company A had software that was written to be hardware independant like company B?
Do you think the merger would be of more value?
I think it is extremly obvious what I am getting at here, and why software as we know it, is going to radically change.
Many IT professionals never EVER ask these sorts of questions, Historically. Why? Primarily because until quite recently, the technology wasn't available in any practical sense, to make such decisions very very obvious, and very very easy to do.
Anyone have thoughts on those arguements and what language and OS do you think I am talking about as I pose these arguments?
-Hack
Got Geometrodynamics? Awe, too hard to figure out? Too bad.