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?"
In reference to perl vs. C that scripting is good for a quick and dirty "proof of concept"
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 code both, and I agree with the columnist, although the column was a bit lacking in useful information or original opinion (although he did give a decent analogy), so here's my take on the subject.
When I have to decide what language(s) to use in a project, there are many factors entering the decision, beyond a simple analysis of mile hike vs. Mt Everest. As he touched on, some languages have specific strengths and weaknesses. I wouldn't use java for parsing large text files unless I had other really good reasons to do so.
The only place this breaks down is maintenence. I think that, and the low entry point actually one of the big reasons scripting laguages are looked down upon. You end up with a lot of scripts in place that were poorly written by inexperienced programmers, which have gotten even worse as other programmers applied patches and bug fixes. ASP is particularly offensive in this way, as, while it is possible to write clean & readable code with it, most people will find it much easier to write nightmarish spaghetti code.
What the initial programmer expected to be a mile hike, turned out to be something much longer, as scope creep and unforseen bugs turned it into an expedition. Rather than turn back and resupply, the stubborn programmer kept going, marvelling at how clever he was to keep himself alive with only a swiss army knife. Unfortunately, this lack of sufficient tools carries over to every other trip up the mountain to fix a bug or add a feature, and clever hacks turn into brutal kluges.
There's not always a right answer, but everything has its strengths & weaknesses, and refactoring or restarting from scratch is an often overlooked option at any stage in development.
Money I owe, money-iy-ay
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
In 1993, programming was done in C and scripting was one in .bat files or shell scripts. It would be fine, even good to descriminate between scripters and programmers in that environment. Then HTML came along, which was more of the same thing. Any old joe can write HTML, but real programmers use C++.
In 2003, however, the difference between scripting languages and programming languages is not so clear cut. C can be used to script the CGI that holds up a simple website, and perl can be used for writing programs.
Is Java a scripting language? It has constraints similar to that of any other programming language, but technically runs on top of a virtual machine and is thus a scripting language. Scripting languages will continue to become more powerful and more difficult to use, and this will further blur the line. With perl even gaining the ability to be a compiled language, it's often hard to tell a programming language from a scripting language.
In this way, how can you really look down on a scripter because of the choice of programming language when C and perl are almost interchangeable for many tasks?
In the long run, we're all dead.
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.
Java is made for applications. PHP is made for dynamic web pages. I think, by default, this gives PHP an extra layer of planning that you have to do, and restricts you to a different set of options. And for your game, I think PHP was a far better choice.
Remember Barren Realms Elite? If I wasn't so lazy I'd be about half done with my PHP rip-off of it.
Whale
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.
This "either or" stance is false. Scripting *is* programming and to be a decent programmer you need to know both a compiled language and a scripting language. Programmers who know only one language can not be called professional programmers in a true sense of the word (BTW in old days one needs to know assembler and a high level language to be called a professional programmer; Programmers who can program, say in only Fortran, or PL/1 were often called suckers ;-)
Moreover in complex systems it's much better to use both.
The main advantage of a scripting language it that it permits writing five or more times less lines of code. For a large system this is a tremendously important consideration. Many projects died just because the codebase size exceed a reasonable limit and thus IQ of the development team and the resources of the organization to maintain it.
When you have that much less code, it's not only easier and cheaper to maintain the codebase, the design itself can be more better. This is the same consideration that eventually killed usage of assembler language for writing compilers. Moreover the time to create the first version and cost of the development can be considerable less. That's why scripting implementation is often done as a prototyping phaze.
But for most complex projects the development team can benefit from using both scriptnng and a regualar compiled language from the very beginning to the very end of the development cycle and coding different parts of the system in the most appropriate language
In this case you need a scripting language that links well with your base compiled implementation language (for example TCL+C ) but that gives a lot of possibilities to structure the system more flexibly.
One important possibility is to have an internal scripting language for the system that you are developing. That is an important advantage for a large class of systems.
All-in-all scripting language is more important on the initial, exploratory part of the system life cycle. As the system became more mature and design stabilize, it might make sense to rewhite some parts of the system in a high level language. If speed is of primary importance all the system can be rewritten, but this is a pretty extreme and rare case.
One can consider Java as a language sitting between two chairs: it's too verbose and low level to compete with scripting languages and it's too slow and inflexible to compete with classic compiled languages like C and C++.
But still using Java is a compromise that helps to achieve some benefits of scripting language and some benefits of compiled languages while using a single language. The main problem is that you often need to write 5-10 times more lines of codes in Java and that's a huge cost difference.
See http://www.softpanorama.org/Scripting/index.shtml for more inforamtion
- Nikolai Bezroukov
OK, so a big question is what is the difference between scripts and programs? To me, a script is something you just write. A program is something you design, then write. I don't really care what language its in. A 10 line Java program that does some simple operation on args is a script. A huge multi-module Perl file/script is a program. There are other terms to differentiate what most people are talking about, its simply compiled vs. interpreted.
Re: The Main Topic
This basically means the difference is that programmers can script but scripters can't program. *ducks* Seriously, if you are writing complex enterprise-critical applications in javascript, you aren't a scripter, you are a programmer (who probably made a bad language choice). Conversely it you are just running search and replace on open source C code to suit some minor business requirement and compiling it, you aren't a programmer.
This is not the greatest sig in the world, this is just a tribute.
Yes!
There was a task:
There was a file with ~600 URL links with real media. A task was to check those URLs.
My TCL solution took me about an hour and was accepted.
Another persons' Java solution took 2 weeks of his time and was not debugged at all.
that other person vas VERY experienced in Java and
wrote a lot of projects in it.
Would be to say that 'scripting' is a subset of 'programming'.
autopr0n is like, down and stuff.
I used to work for a company who insisted that everything be done in Java. Now I work for a company who is in bed with C# and other .NETedness. I can understand standardizing on a set of tools, but I think this attitude is kind of dumb in some respects. Sometimes it feels like hammering a screw into the wall with a somewhat stale loaf of bread.
I just finished writing a front-end application at work using Python and wxPython (which is incredible I think). It would have taken me at least a week to do it in C, C++, C#, Java, or any other buzzword language, but I finished it in a little over a day using Python. My app has the added benefits of being cross-platform (Windows, Linux, and FreeBSD), it has a native look on each of these platforms, and it runs a lot faster than a Java/Swing app would.
Ideally, such a time saving technology, and those who know how to use it, would be valued. Yet somehow those pointy haired MBAs that seem to run most companies don't seem to get it.