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?"
is that it stops being 'scripting' and starts being 'programming' based on the scope of the project. Processing a web form is scripting. Writing a GUI app (be it in Win32 or wxPython) is 'programming'.
"I would say that 99 per cent of what my father has written about his own life is false." - L. Ron Hubbard Jr.
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.
OddManIn: A Game of guns and game theory.
There seems to be this mindset in large corporations that all "programs" have to be written in C, Java or another "compileable" language. In my job at a very large company (Caterpillar) we especially see ancient VAX-based apps or newer web applications that months are spent on, when a simple Perl script would do the same job in a matter of weeks or days.
Moderation: Put your hand inside the puppet head!
Hey, if all those art majors and wanna-be fashion designers hadn't decided to become "web developers", maybe someone who can write an actual program in Perl might get some respect.
Seriously, scripting languages have been "tainted" by the Web. "If it's a script, it can't possibly be worth anything" is a pretty common mind-set these days.
While I've seen some pretty awful C and C++ code out there, it's nothing compared to the horror of amateur Perl or (shudder) Shell scripts.
It's interesting to consider that scripting languages have been able to ride Moore's Law to the extent that you can reasonably implement things in a scripting language hat would have really needed to be compiled a short time ago.
-Mark
An author loses all credibility to me when he asserts things like "developers spend days and weeks writing Java and C++ code to solve problems that those talented Perl or Python programmers could have knocked out in a few hours", with absolutely no substantiation. I guess that with anecdotal evidence, you can prove anything.
I'd challenge anybody to come up with a problem that could be solved within a few hours in Perl or Python that couldn't be solved within 2 or 3 times that length of time (longer, but not "weeks") by a competent C or Java programmer. Certainly, there are jobs where Perl is absolutely the right tool. But I have a very hard time believing that there can be that much of a difference.
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".
https://www.accountkiller.com/removal-requested
One little piece of common sense to remember, though, is that it doesn't matter that e.g. Python would only take 10 lines and is easier to read, if there is only one person at the company who knows Python, and the other 30 developers only know C/C++/Java. You can argue that Python is easy to learn, and easy to use, and I will agree with you to the ends of the earth, but that doesn't mean that a particular individual will find it easy to learn or use.
;)
The additional factors of training expenses and/or recruiting and hiring someone who knows the language should be taken into account when evaluating the tools used on a given project. This is a basic thing in managing a project. It is only my personal opinion that sending all 30 developers out to learn Python is the obviously correct solution, that will save the PHBs (and developers) time, money and frustration in the long run.
...at this point, wouldn't it be a good idea to pick ONE of the scripting languages, and make it a co-standard? Sure, allowing anyone to code in language du jour isn't a great idea, but taking forever to do code simple programs because C takes forever to develop with...well, that ain't so great either.
-Looking for a job as a materials chemist or multivariat
I followed the programming (as opposed to hardware) branch within the Computer Science degree program at my University. At the university there was no stigma placed on one language over another, and so armed with my previous experience with basic, pascal and fortran, I dove into classes on perl, sed, awk, and Unix shell programming, as well as C++, Java and Lisp.
My first job was as a Unix systems administrator/technical support weenie on an proprietary embedded system. The system did not have (and it was not legal to add, without breaking our maintenance agreement) a compiler. So, any automation we needed to perform was in the form of shell scripts.
I ended up building a full blow interactive application that hundreds of people use on a daily basis to this day. The last bug for this system was found in 1999. Scripting allowed us to extend the functionality on that system, and all of the design tasks and lifecycle considerations were the same.
I have been in several projects since then, big and small. In every case I always was able to make the decision to use a scripting language if I thought it appropriate (for example, we needed to perform remote administration on hundreds of machines; what better way to automate this functionality than with Perl and Expect.pm - so I did). As a developer I always keep my eyes open for the most efficient means of getting the job done.
Perhaps being a system administrator for a time helped me avoid the stigma associated with 'scripting'. To me it is all just programming - plain and simple. Those that limit themselves and don't grok as many languages and methods as possible are selling themselves short. Today I am extending my abilities by teaching myself python, and extending my perl repetoire with perl/Tk.
Holy wars are only an overt attempt to subjugate other's ideas to your own. Its wrong - so, STOP IT!
Lodragan Draoidh
The more you explain it, the more I don't understand it. - Mark Twain
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.
At what price learning? At what cost wisdom? The price is a man's peace of mind, and the cost is his life.
I don't know why they make the disctinction, but certain contracts let by the government contractually define a difference between 'coding' and 'scripting'. On any given contract, some roles may allowed to do both, some one or the other, some neither.
As an example, project managers are not be authorised to code or script, software engineers may both code and script, technical leads are not allowed to 'code' but are allowed to 'script'.
My only experience with this policy cones second hand over lunch. It is the case of a small project that consisted of a project manager, a tech lead, and an a small number of junior engineers. The engineers were allowed to write 'code', the tech lead was allowed to 'script', and the project managers duties were restricted to scheduling and budget. Though it sounded like a good idea, schedule concerns required that the tech lead contribute to the project. Since the tech lead was not allowed to bill for time spent 'coding' it was decided to write the project in Perl (since it was considered to be a scripting language).
I don't want to get into a Perl flamewar, but I don't think anyone can disagree that Perl is not an appropriate choice of language for production systems. Perl _can_ do everything that a more structured language can do, but it doesn't necessarily do them well (it doesn't encourage good software engineering practices, has a steep learning curve, can be cryptic).
I've probably dis'd Perl too much already. flamewar is certain to follow. I'll stop more before I incite a holocaust. Suffice it to say that Perl wasn't the best choice for that project, yet the distinction between sripting and coding effectivly made it a requirement.