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)?
Is it true that some companies are so overcome with script bias that they'd assign years of unnecessary work rather than give it to the coding untouchables?"
sulli
RTFJ.
In reference to perl vs. C that scripting is good for a quick and dirty "proof of concept"
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
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.
I've been lucky. The management at my previous job was all tech-savvy, so they knew to use the right tool for the job. The management for my current job are completely un-tech-savvy, so they don't know the difference ;)
I can't say that I don't give a fuck. I've just run out of fuck to give.
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.
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.
Hmm. I thought scripting *was* programming.
In my environment, we use whatever solution works. If it is a simple script, we do it, if it is a complex program. We do it!
Mike http://thenextgenerationofradio.com
People, please use the right tool for the right job. period.
I think the only difference, generally, between the two, is nomenclature. Although scripting languages are generally interpreted, all in all, there isn't too much difference.
So the name comes up as the big deciding factor. You call yourself a scripter, you're actually limiting yourself in the eyes of those who want to see a difference between scripts and "programmed" software. I've actually found a lot of resistance among people who write in scripting languages to call themselves programmers, even when, by rights, they do the exact same tasks.
Of course, no one ever stops to question when a programmer writes in a scripting language... except maybe to say "why are you bothering with that garbage?"
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!
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
"I am good at scripting." == lame.
"ph34r my l337 skr197x0r sk1llz, f44g0rz." == cool.
Trolling is a art,
..that the only time that really counts is programming time. Execution time is trivial. And this saving continues to be true over the entire lifecycle of any product. [as an assembler and C/C++ coder I will admit certain exceptions do exist in hardware dependent areas, but these are rare & getting rarer -- which is why I'm looking for work ;D
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
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.
C is a scripting language. It is no less interpreted than Perl. Perl can, by the way, be compiled into assembly code. So can PHP, I believe. C cannot run on its own, nor can Perl or PHP - it must all go through a middleman (interpreter/compiler) first.
The ONLY language that IS NOT scripting language, is assembly/machine language. Machine code needs no middleman interpreter or compiler to run. It is also 100,000 times harder to code and debug.
C is just more.. prestigious... than other scripting languages.
--- Grow a pair, liberals... stop letting the Republicans bully you!
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)
As a consultant for many years, I can assure you I've seen bias in many forms in many companies
Male vs. Female
White vs. Black
In-house vs consultant.
Cronies vs. Others.
Bootlickers vs. others.
Microsoft vs. Linux
C++ vs. VB.
Why should scripters vs. coders be excluded?
Now, if corporations are stupid enough to be biased (as opposed to simply making logical decisions based on the facts), they are hurting themselves, and hurting others. If you are so affected you should: A) complain, B) find new employment, C) put up with it but let it not bother you. Personally I prefer B, but A and C are also reasonable choices in some cases.
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 ?
A lot of companys don't like scripted languages because the source is required to run the code. For small companys like the one I work for this isn't a problem, but larger companys that may spend a lot of money developing there programs may feel better if they only have to distribute binaries.
;)
No doubt that scripting is a better choice from a programming point of view for many of these types of systems, but often it's not the programmers making the choices
Can understand both sides!
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...
Script kiddies, by definition, do not write their own scripts.:)
Is this a sigs-optional kind of place? 'Cause I am totally down with that if you know what I mean.
The problem that arises is that many scripts become mission critical, and yet are "hidden" in root crons or some other root-owned facility, and are not maintained in the corporate source control system. So other developers can't see or alter them. Worse, they don't often go through the same QC process as other pieces of software in the organization.
There is a healthy aversion by management to anything that is critical but not touchable but by a few, and which breaks all the controls put in place by management.
I personally like scripting. It does solve every-day problems efficiently. But I think it gets a bad wrap because of these lack of controls.
There's no such thing as a 'scripter;' there are merely those who use just-in-time or per-execution compilers.
Vintage computer games and RPG books available. Email me if you're interested.
I'm one of the people hit by this. My company used to have a group that was formed to use scripting technologies to help customize our core products. The C++ folks in R&D looked down their noses at the 'amateur' work we did, and during the last downturn the group was disbanded, the senior people assigned to core R&D and the rest sent packing.
After a year, they've found out they don't have a single major customer who's operation doesn't depend on some work done by the 'amateur' group, and they're unable to incorporate the required functionality into the core product. They're stuck having people port the scripts in order to get customers to upgrade. Meanwhile, some of the folks that left are making a healthy living doing consulting for our dealers and major customers.
This morning I heard the principal engineer estimate that it would take 2 years to adapt the core product to include some functionality that I wrote in Perl in 5 weeks... 6 years ago.
10 Echo Starting Application
20 system "start iexplore -k http://localhost/index.php"
30 goto 10
40 profit
Im dreaming ofa big bndwdth, That can resist the
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
I think it's not about compiled vs scripted languages but programmers vs amateurs. Lots of scripting languages have an easy learning curve and many people who are hired to write scripts have not really been trained as programmers. This, also why we often hear "perl code is such a pile of mess". Well, most of it seems to been written by people who learned it from tutorials and have no idea about basic concepts of software engineering, algorithms, programming styles and such. Most companies just can't afford to hire a person with a computer science degree from a respectable CS school for every job that requires coding.
my $0.02
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.
Otherwise we'd all be programming in Assembler..
Anyone who's ever programmed Microsoft VC++/COM/ATL/STL/MFC will attest that that particular environment does not do a very good job of hiding gory details.
I choose the language based on the task, if a scripting language is good enough and performance is not an issue, I'll be the first one to use Perl or even VBScript.
So, write it as a script, put it in a crontab, and make a VC UI that just fetches a "results page" of text and shows it to the end user whenever he/she/it hits the "refresh" button. Pretend you're working on it for the next two weeks, and spend the time you save doing something useful, like reading '., downloading pr0n/mp3/movies/whatever :-)
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".
I work in industrial information management, which is often accomplished using various types of information technology. Just from exposure, I've picked up and used some scripting tools to solve problems.
The fact that I use scripting tools some of the time was held against me in a review. Remember -- I'm not even *in* IT, not required to know programming *or* scripting -- but the value of "script kiddies" has been so diminished that the management here heard I could use scripting, assumed I was another devalued dot-com remnant, and assumed my value would be much lower. I was able to explain the difference to them eventually, but at the time, I thought their zeal to devalue scripters was noteworthy....
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.
Someone please give me an example of such a task.
If this is from a real world example (which I doubt) then I think those Java/C++ programmers shouldn't be employed.
I think that, once again, someone is under the impression that a person is only capable of one skill.
Is the author in management somewhere?
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...
On the other hand,
can be written in 30 seconds, where the equivalent C code would take all afternoon. A C program that evaluates just that one finite state machine will run at least an order of magnitude faster than grep will
To a first approximation, the time it takes to write a program is proportional to the number of lines of code in the solution, whether you're writing assembler or perl. The cost of a program is directly proportional to how long it takes to write it. So if you're going to opt for a compiled language over a "scripting" language, you should be sure that the additional cost is justified by the gains that come from performance.
In an awful lot of cases, it just isn't.
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.
Absolutely this is done, and the bigger the company, the more stubborn and thinking!
I've been sitting here at my little pathetic cube banging out perl scripts in a few hours to run diagnostics and spot problems in the day to day operations of the company.
The IT monks recently approached me and informed that I was practicing sacrelidge by using Perl instead of C or Java. In order to save my soul they would have to assimulate all my work and do it in Java.
That was nine months ago. They are still working on the first 3 of 50 scripts that I've put together in about one years time.
And don't mention the following words to any of them:
- Open Source
- GPL
- Freeware
- Shareware
or they will start screaming, running around the room, and hitting themselves over the head with boards asking the IT gods for forgiveness.Seriously, the notion of standards in todays IT industry is rather fucked up. They select one tool for every problem and go from there. Hell, if that was the case, then we would all be running Visual Basic and be happy. After all, there isn't anything VB can do that anything else can't.. right!
...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 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"...
:P
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...
So I just sit back and listen to the tirade - and try not to egg him on...
BlackNova Traders
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)
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
Most of those "modern web techniques" cause more trouble than they're worth. They tend to work consistently only with Internet Explorer, which is their real reason for their existence and the reason Microsoft promotes them.
CSS is in a wierd niche - unneeded for simple pages, and too weak to do what Flash can do. Most of what CSS is usually used for can be done on the authoring side, with Dreamweaver templates or something similar. CSS also interacts badly with firewalls and proxy servers that edit out hostile content. If you really need exciting animated graphical effects (and you usually don't), Flash has far better capabilities.
Almost nobody uses XML as originally envisioned - as a way to send structured data from a web site to the user's client. I built Downside to do just that for SEC filings, but apart from one obscure client program nobody uses, nobody downloads data that way. We're not seeing XML-tagged price and part number info on sites to allow price-oriented search engines to find the best deal for consumers, now are we? When you buy something online, you don't get back an XML-tagged receipt that goes into your own database. XML is mostly used for in-house and business-to-business applications, typically in situations where no human looks at the content.
If you have a hammer, everything starts looking like a nail.
A lot of managers don't know about scripting - so they see programming as the solution to everything. Let's face it - scripting is often behind the scenes, doesn't fit well into standards at times, and isn't as flashy on the surface.
On the flipside, I've often seen scripting-heavy people not communicate the necessity of their work, whereas more coders I know seem to have developed that skill.
The result? Management doesn't know about the options, so they'll go with what they know.
Just my 2 cents at current exchange rates.
"The Sage treasures Unity and measures all things by it" - Lao Tzu
Decsisions made for buisness aren't usually going to come with rigorus mathmatical proofs of their efficiency. They're typically the gut feeling of a supervisor who's interest is minimising accountability. If your skills aren't needed/appreciated at your job, find a new job or learn the skills that are appreciated
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.
To expand on that: I have found that a lot of people fail to realize that you should first identify a PROBLEM that a static computer program can solve repeatedly. If a process is temporary and won't be used several times yet still requires a lot of processing for the whole 1 time it'll be run, then perhaps a simple script will do.
Where I worked before, the order of the day was ad-hoc reporting. Management failed to understand that a static processing unit cannot produce very different sets of output - it can handle a lot of different branches of execution, but only those that are explicitly defined. Whereas some simple scripts to get the job done for a short while would have sufficed, they demanded that all output be generated by static compiled binary programs that they could run locally on their computers (no, they wouldn't shell out for a webserver or database server until much, much later, when they hired a new project manager with clue).
Yes, it was maddening. No, I will never return to work for them under any circumstances (save a large 6-figure salary). And no, they never learned their lesson - they're busy making a giant funding model in a binary program, where the model's implementation is CONSTANTLY changing & being tweaked, having modules added & removed. The program will never get off the ground, but for the past 2 years they've been plugging away at it, desperate to come up with that holy grail of "Static process Ad-Hoc Reporting."
May God have mercy on their souls.
i'm amazed that i survived - an airbag saved my life.
It's a hell of a lot easier to get a "programmer" to learn a scripting language, and make good use out it, than it is to take a "scripter" and have them learn a programming language and make good use of it.
I'll use the AutoCAD example:
AutoCAD has a built-in LISP interpreter. AutoCAD also has a C++ interface called ObjectARX.
Many "CAD Managers" have picked up LISP (become "scripters") over the years and have used that to automate repetative tasks in AutoCAD. Although useful and helpful, this LISP code is often a train wreck. Suddenly they will reach a place where they can't figure out how to move forward, or need something beyond this simple functionality.
You also have people that have "picked up" ObjectARX to write "C++" applications, that in reality are just LISP routines ported to C.
Then you have trained "programmers" that understand OOP and design. These individuals can step in and make use of the "true" power of the engine that AutoCAD has. These same programmers can write LISP or VB/VBA if they have a "quick and dirty" or need a "proof of concept" app. However, you'll never have the other guys comming out with a real robust add-on like the "programmers" can.
It's not that it's "descrimination," the issue is that people trained in CS are able to choose the right tool for the job, not "fumble around until they figure it out." This has unfortunately become the stigma for "scripters", because scripting is a lot easier to pick up than real software development methods, and as such you have people that may not really understand what they're doing performing the task.
C
- Sighuh?
Everyone assumed I would simply pick up his work and continue with what was in place. Upon inspection, I realized a huge chunk of his build system was C-based, with some BASH thrown in to tie the Makefiles together.
I took on a major task (of course without telling anyone =] ) and rewrote the build system in TCL (and improved the BASH imports to the Makefiles). I can't recall the imrpovement we had, but it was impressive. And it took a couple of weeks.
It proved to the co-CMs the improvements that could be gained with pure scripting without any need for "code."
-- SegFault
"One day, some time ago, something important happened."
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
One reason I would not feel comfortable programming a large project in a scripting language is the lack of static type checking. Compile-time guarantees about runtime behavior are a very, very good thing.
Someone should invent a scripting language with static type checking. (Are there any?)
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.
...but if my programming department is going to have to maintain a system, I don't want some unknown in a different department who thinks he's a slick Perl scripter (programmer, whatever) creating that system. I want somebody I know and trust to put the system together with tools that will likely result in a maintainable system.
Am I biased against Perl? Hell yeah. But only because I've used Perl. There are tools just as good for teeny tiny projects that won't collapse of their own weight if the grow to be any bigger. Some of them are scripting languages.
Am I willing to spend more hours of programmers I trust so I'm less likely to get bit in the ass by sloppy work later? Hell yeah again.
So am I biased against scripting? Hell no. But I will take actions that may look that way, especially to the Perl fanatic who doesn't get to play in the company's programming sandbox when I take away "his" project.
Sorry
What's a sig?
Well if you can be sure that the same person who initiates the program will be around in 10 years to maintain it -- then go ahead and use 40 different scripting languages and 20 different compiled languages.
However -- in the real world (where we have to request specific skillsets for our contractors upon one person leaving and another person coming) we have been forced to standardize on a handful of languages to ensure that we could get the job of 2 people done with 2 people. Not having to employ an extra Python or Perl guru just in case those few programs that the one guy who thought Python was cool and could do it "tons" faster than Java or C need to be maintained or added to.
Sure -- we have extra up front time writing Java programs in a week when Perl could do it in a day.....But at least if we replace our "Java" resource with a "Java" resource -- we can ensure that future maintenence and enhancments to existing programs has a fighting chance.
(+1 Funny) only if I laugh out loud.
I'm not sure, but in my building, there are three bathrooms -- Men, Women, and Scripters.
I've brought the point mentioned in the top blurb that "some apps can be developed faster in scripting langs" to the forefront in our company. I code in Director's Lingo scripting lang and by using Director as opposed to C++, we have a 2 x improvement in the time required to create our products. That is, we are now 2 x faster at creating our apps.
From a personal point of view, I think in English, not C++ or javascript. Complex syntax rules generally induce voilent convulsions in my tiny little brain. If a syntax follows the way I think, then I code my projects faster since I don't have to stumble over an obtuse sytax. Now, lingo supports "the property of object" and object.property - so we have a verbose syntax and a dot syntax. Though the dot syntax takes less keystrokes, the verbose is a dream to debug (for me) because I can read it like reading a sentence. it instantly makes sense. This makes me wonder why more languages do not support multiple syntaxes.
In case you're wondering, with this scripting language I've been able to create robust libraries (foundation classes) so the fact that it is not a "real" programming language is pretty moot to us. We have a C++ guy. Now, if he can only learn to create Director Xtras...
- Zav - Imagine a Beowulf cluster of insensitive clods...
Script are good for quick and dirty work, but when one come two years after do to maintenance, good plain old langage are perhaps best.
I'll take python over C in a maintainability contest any day. Pointers and memory management are notoriously hard to maintain.
I work as a tester for an embedded systems software group. When I started here, all of the tests were hand written and formatted. With information coming out of various databases and models.
Basically, none of the programmers wanted anything to do with formal testing so the process was a mess. I decided something had to be done. With the use of a MatrixX script and some Perl Scripts, a process that took 4 hours was reduced to 15 minutes.
Needless to say, this got a lot of attention. Since then, the company has decided to start sending people to training to learn scripting languages.
Unfortunately no one can be shown what Linux is, one must experience for oneself.
I use VB SCript in my ASP development- am I not a programmer? I thought I was. That's what I told my Mom I was. She'll be so disappointed.
:-(
That means I'll have to chnage my business cards
Seriously, what is the difference? Depth of the manguage? I don't know.
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
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
Speaking as a coder proficient in multiple languages, in an environment where as a team we cover many many areas and languages of experience, I would say this does not happen.
The reason being not that management lacks any bias, but simply that management don't tell us what to use - they trust us techies to make such decisions accurately. It's part of our job...
Sam
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.
Wow, such a complete misunderstanding of CSS... CSS is intended to separate content from presentation. That's it. It has nothing to do with Flash or "exciting animated graphical effects".
It's unfortunate that CSS is so misunderstood, as it is really a quite elegant model for web presentation.
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.
Some (like my boss) know C++ (sort of) and Perl (he's just been building the web site). Others only know C/C++ as being real languages and think of some of them as childs things. It then comes down to how much they rely upon the advice of their technical staff.
So I'm not so sure that it is discrimination as opposed to ignorance.
One language, one platform, one big piece of shit.
Nevermind I just forgot my point...
So, when you have a problem that is perfectly suited for Perl and can be solved by a Perl programmer in a few hours, it can also be solved by a Java programmer in hours. But only by a Java programmer who is already familiar with the aforementioned packages and doesn't have to search, install, evaluate, choose and learn them first. Most Java programmers, however, are more familiar with Java-typical problems and familiar with Swing, J2EE packages and the like. Those could easily waste two weeks writing clumsy code for something they're not experienced with.
These numbers are ridiculous. A factor of two or three is virtually nothing in software development. It is common that some programmers are ten times faster solving the same task as other programmers who use the same language and went through the same education. If you wanted to prove that a particular language is better suited for a particular task, you'd have to conduct a huge case study in order to get somewhat useful averages in the end. Just comparing two programmers and then concluding "one was faster, so his programming language is better" is just nonsense.
but what do i know, i'm just a model.
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 may take a week to code what takes an hour to script, but over the life of that script how much maintanence will it require. What you gain in a few extra hours of coding, if done correctly, can create a lifetime of savings.
I write software that handles a lot of Citifinancial's processes - 90% of it is in perl.
When I have to write something in C it's just never as easy or bug free.
C/C++ is sort of an exception because it was meant as a jack-of-all-trades before more focused tools were created, but...
.Net world in which there is one canonical, universal, modern format for text data.
A language like Java or C# is designed with an attitude that it will be used as the foundation for building software systems. It is for creating new systems and new data, and it is at the center of those new systems.
In contrast, I often hear Larry Wall (Perl) or Matz (Ruby) make comments that sound as though their tools are designed to accommodate themselves to legacy data and legacy systems.
Java and C# tend to say, "this is the new way to do things", while Perl and Ruby say, "we're doing our best to accommodate the legacy ways your systems do things".
I'll give you a concrete example: Unicode. Both Java and C# did the smart thing (for a foundation for new things) and said, "in our universe, all text is Unicode. Period. No messing around with old, crippled text encodings. We work only in Unicode, all of our APIs are pure Unicode, we only need one deep set of global APIs (instead of many alternative, shallow sets of regional APIs), and if you're smart, you'll set up your auxiliary systems (the database, for ex.) as Unicode systems, too, because that's what we use here." They can convert from legacy encodings to bring old data "into the system" and convert to legacy encoding if necessary to spoon feed some older "outside" system, but the real system is a Java or
In Perl and Ruby, the idea is, "well our job is to slice and dice other system's data, that's what we do, and we have to accommodate the many text encodings out there. We don't do anything really deep. We do basic, solid byte-pattern matching and processing without any real deeper understanding of language, because the encoding could be anything. We can't assume everybody uses Unicode". Meaning, in essence, we can't make rules of our own, we have to conform to whatever the real system wants.
It's as if some scripting language designers see their tool as a wrench for tinkering with engines, while the designers of Java and C# see their languages as tools for building engines.
This is an overstatement of the difference, of course, just for illustration of my point. Certainly Java is sometimes used as no more than "glue", while Perl is used to build whole systems, so there's a spectrum here. And Perl is trying to retrofit fancier linguistic features onto a scripting base as it grows into a "big language".
But I see the difference that leads to the bias referred to in the article as coming, at least in part, from the original language designer's concept of the centrality of his language's role.
"Those who have never entered upon scientific pursuits know not a tithe of the poetry by which they are surrounded."
Using traditional programming languages usually involves thinking phase. Something that quick use of scripting does not seem to involve. Have you seen Perl code reviews lately?
The three principal virtues of a programmer are Laziness,Impatience, and Hubris. See the Camel Book for why.Maintain perl code to see why not.
Solution: Debug all ductape coders from your system. Let all remaining use the best language.
Dyslexics have more fnu.
I watched someone spend an entire week writing a Java program to parse a text file even after I told them a one line sed script could do the same thing.
It isn't so much about discrimination in the racial or sexist sense, it's about technical ignorance coupled with a reluctance to learn. Fortunately, a person doesn't have to learn the 5 billion different scripting languages out there to resolve this--just sh plus sed/awk or PERL would save weeks of time. The ROI on scripting is at least ten-fold and often much more.
Healthcare article at Kuro5hin
If "Executive-level" management is making decisions on what programming language people should be using, they're sticking their nose were it doesn't belong. Lower level management (if even that) should be making that decision. Deciding what to use based on biases is always a mistake. I like Java a lot, but using it when something else would be better is a serious mistake....and visa versa.
Once the thing works, if it performs well enough, the resources to re-implement will dry up.
Once enough of it has been done in a compiled language (that is, about 20%...remember the 80%/20% rule). resources to re-implement the rest will dry up.
Soon Management will realize this new "Prototyping Paradigm" saves them resources, but gives them plenty of busy work (re-implementing scripts in compiled code) for when they need to look busy, and it will turn out to have been Their Idea All Along.
- "History shows again and again how nature points out the folly of men" -- Blue Oyster Cult, 'Godzilla'
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.
If those 30 developers can't decipher all of 10 lines of python (or any language) it's time to get some new developers.
"You're never ready, just less unprepared."
The problem with that idea is that a CS degree doesn't instill the drive or values required to become a really good programmer.
I feel you really need to be a self learner in this field, because by the time a language or idea is in the colleges, more likely that not brand new better ideas are already on the horizon. You have to be able to constantly self teach in order to keep up with the trends.
That takes a passion for the technology which you can't pin down in by looking at the certs someone may have.
I think that the issue really comes down to the difference between "scripters" and "programmers" not scripting languages and programming languages.
... introspection ... dynamic typing ... late binding ... evaluation environment ... in place rapid development ... abstracted stack exception handling ... *gasp*! cough.. cough..
Scripting languages allow the "coder" ("scripter" or "programmer") a great deal more expressiveness in their coding environment -- they are a more effective way to create ideas in code, often at the expense of some runtime performance. The rigid and non-introspective nature of compiled programs typically yields better execution performance at the cost of time taken to accurately describe the problem in the code.
The terms "Scripters" and "Programmers" seems to hang on the "coder's" understanding of how the code specifically interacts with the problem. Since scripting languages offer higher levels of abstractions, an uninformed coder ("scripter") may not be aware of the complete ramifications of their code. They are distanced from the computer's actual behavior by a great deal of abstraction. This is true for compiled programming languages too (or anything above, say, microcode), the difference is how much is being abstracted.
The ideal situation would be to have a "programmer" writing in a scripting language (mixing in compiled code when performance dictates, which it does sometimes). If your only available coders are "scripters" you may do better to have them write in a compiled programming language so they are aware of more of the execution environment.
Personally, when approaching projects of great scale and criticallity, I belive greater scripting language usage is important to be successful. The key is to have "programmers" writing the code so they can make informed decisions on when and where to use compiled programming languages.
I'm currently resisting the urge to go on and on about why scripting languages are important to scaling and criticallity
I guess I'll be modded down for that lack of self control.
I'm basically a C++ programmer, but I like and use Perl for smallish text-processing tasks.
... probably not very much.
However, the main reason I see for preferring C++ for long-lived projects is one that has not been mentioned here: the stability of the language specification. The specification of C++ is extremely thorough, and changes glacially slowly. That's a big advantage for software that will have a long life. Remember, folks, that the main work that programmers do is not developing code. It's maintaining code. I've only ever used Perl 5.x; I'd hate to have to maintain something written in an earlier version that didn't have references. And in a year or so, I wonder how someone who started with Perl 6 will like MY code
All languages have this problem but C++ has it much less than Perl.
As for the boundary between "real" programming languages and the wannabes: for me, the test is whether it's well enough specified that you can determine from reading the language spec whether a piece of code is valid, and if so, what it does. Perl passes this test. (well, 99%). Others, Ruby for example, don't. For this reason, I regard Ruby as a waste of time. But I'm very results-oriented. If you have a more playful disposition, YMMV.
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
After all, if technology selection was rational, everyone would be using Lisp or Smalltalk.
That is all.
Scripting isn't the problem. Slop and using the wrong tool for the job is. Ever try to write an 'application' using Microsoft Access? I was forced to when working in the temp industry...now that I use Apache/DBI/Embedded perl to do much better applications I am so much happier!
Pretty much all of my sysadmin and desktop customization on my linux boxen are done with a combination of bash and perl. Same with my web databases. Right tool for the job and whatnot...
I do not think it is a matter of languages... like others have said... they are really just different tools. Actually they are well, just different languages, some are more conducive for conveying different tasks than others are. Anyway back to the point, it really has to do with the labeling of people as either a Programmer or as a Scripter. Let's start with definitions. Now remember this is my opinion and should not be read as being an attack against scripters (in fact most of you that script primarily are actually people I would classify as a programmer).
A Programmer is a person who has a solid understanding of computer operation and a backing (either formally or informally) in computational theory. Because of this a programmer usually demonstrates the ability to learn new languages (interpreted or compiled) quickly and is more apt to choose the more appropriate tool for the job when given the flexibility to do so. Further more through a more thorough understanding of how various computer languages behave a programmer is capable of implementing a workable (i.e. maintainable and adequate) solution to a problem when the ideal languages are not available.
A Scripter on the other hand is someone that I would view as being of lesser skill or general understanding than a programmer, even though they may possess a deep understanding of any one or two "scripting" languages. I base this on my belief that scripting languages in general where created for one of two uses 1) to automate or simplify specific tasks for programmers to save them time while they are solving more complicated problems or 2) abstract complex tasks or provide interfaces for complex tasks for non-technical or less technical employees to work with.
So a programmer writing in PERL is just that... a programmer writing in PERL where as a game designer that is writing in his or her shop's game scripting language is just a scripter. (They are still a game designer something that I give them mad props for, I for one am very creative but about as expressive and artistic as a dull brick, but in the context of programmers and scripters they are scripters.)
Now as for the discrimination, that may me a bit harsh of a term to use but I do concede the fact that yes I have seen behavior that would lead itself towards that interpretation. Most of what I see falls into two categories, first would be what I would call programmers thorough understanding of computers and computational theory looking down on scripters because they are viewed as less competent or knowledgeable about computers. Not making a judgment call on this here, also its nothing new... you see it anyplace you have a group of people that consider themselves in the "in" verses those in the "out"... the stereotypical technical support view of a marketing or human resource employee for example. The second is when management miss assigns a task to a scripter or a programmer either giving the programmer a task that should really be assigned to a scripter or more damaging giving a task that should be given to a programmer to a scripter. In the first case the time of a programmer is wasted solving a problem or implementing a solution that should have been given to a scripter, at the very least it is a waste of programming resources that could be better spent solving technical problems that are outside the abilities of a scripter, but more often that not the programmer is being asked to solve a problem that while they have the technical skills to solve may not have the best background in understanding of the product, intent of the product or general artistic capability. The second situation, the one that I feel is more dangerous, when a scripter is given a task that should have been assigned a programmer at best produces a substandard solution that in the long run will be difficult to maintain in the long run. Many times though the solution is worse than that resulting in eventual product failure because it is not possible, or un-scalable, un-maintainable because of language changes, etc, etc. On top of this when successful management's perception of having a quick and cheep solution in scripters and scripting languages that can be used to solve all of their companies problems is perpetuated and if the projects (usually when not if) the projects fail or it is finally realized that to continue to scale they have to be reimplemented by programmers the unfair perception by programmers that scripters are unskilled and uneducated in the ways of the computer are unfortunately reinforced.
Ok... I probably babbled a lot more than I intended and took way too many lines to say way too little... ok... I guess I must have had some pent up angst or something.
Unfortunately this post was not cut short by the need to do real work
Have you thought for yourself today?
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.
Here're my tips to keep both sides productive and respecting each other:
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.
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).
If you didn't lay out the tranistors yourself, you didn't do shit!
autopr0n is like, down and stuff.
As a senior technical consultant for my company, I do not generally recognize any the Authority of any person, outside of the Customer, to specify which programming language I shall use. If the manager types think they know so well, I ask, why aren't they writing code?
Leave the technical decisions to those most closely coupled to the technical problem. Perhaps a few companies should learn a bit from Demming.
C//
"is only enterprise coding REAL PROGRAMMING"
In other words, you have assumed that the answer to that question is "yes" therefore you are dismissing so-called scripting as not being programming since it's not up to the task of a real enterprise level system (which I disagree with as well, but that's another post and another story).
Small, one-off jobs sometimes (often?) get overengineered because people start throwing around the term "Enterprise Level" like it's a foregone conclusion. There's lots of cases where, even in a true enterprise, the task at hand is small enough and isolated or isolatable enough that scripting is not only possible, but the better approach.
simon
home page
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.
=^..^= all your rodent are belong to us
Please erase my student loan debt. Please Please Please.
I will do anything you ask. I will be your slave for a month.
Free human servitude.
You will never get caught, I promise.
I don't read or respond to AC posts
As you say, "Bad Stuff" thends to accumulate more rapidly on the script side when the conditions are bad (such as when not following basic engineering best practices).
On the other hand, in the hands of a skilled programmer and in a good environment, "Good Stuff" tends to accumulate more rapidly on the script side too.
As a consultant who has worked for a wide range of company types..... from isp's to government organisations, I have observed that the closer a businesses managerial competences are aligned with engineering competence, the less likely they are to have hangups over the tool you use to get the job done. As you get further out on the edges, the more inclined managers seem to want you use "whatever our main system runs" to fix problems....
The difference between "scripting" and "non-scripting" languages is vanishing. Look at Parrot and Perl 6. Ruby is rumored to be getting its own VM (just like Java). Python has Psyco (Python Specializing Compiler, I believe).
On the other hand, look at clisp. Clisp has an interactive environment. So is clisp a "Scripting" language, even if it was probably invented before the whole "scripting" meme came about? If I make (or buy) an interactive environment for Java, does Java become a scripting language? What about ocaml where you don't have to specify the types, but they are inferred and enforced by the system, AND it comes with a compiler AND an interactive environment AND a VM...so what does that make ocaml?
I find this whole talk of "scripting" vs. "non-scripting" to be total and utter bollocks. There are good and bad programmers. Period. There are idiot Java programmers who make spaghetti code. There are brilliant Perl programmers who write clean, object oriented code you can understand that doesn't look like line noise.
It comes down to dynamic vs. static typing. Is there any *REAL EVIDENCE* that static typing results in better code when all else is equal?
One day, I a co-worker of mine asked me to help him figure out why was his component code for updating a sorted directory was not working as fast as he hoped. The code was in Visual Basic. He told me that initially it was working well, but after getting into production, the code "decided" to become slow. He was a decent VBScript scripter from what I observed before, but this was his first real Visual Basic code. I changed my opinion of him when I saw the code. This code was real production code, in Visual Basic at one time...
Now, who the hell still uses a friggin' bubble sort to sort a large array? This person certainly did. I asked him "Where did he get this code?". He stated that he found it on the net. After explaining the reasons why this code could be better with a Quicksort, I got the impression that the code was over his head. I ended up writing the code in C++.
The moral of this story is that some of the scripters, especially those who have never had a lick of computer science, have the mentality that they can do the job in less coding time than the compiled languages. For the most part, it is true. The scripting languages have their place. However, once they get into the realm where performance actually matters, then scripters are like a herd of lost lambs trying to find their mommies. They do not know jack. If I can teach them a thing or two (and they remember it), then their value increases in my book.
Coderz 4 Life
Would be to say that 'scripting' is a subset of 'programming'.
autopr0n is like, down and stuff.
scripting languages require less total code, and therefore it's easier to absorb quickly
This often heard argument simply doesn't hold. Perhaps some script that looks like /%askf a $$ kjs hf$"$ s
skjhsd ~/skjh
can really do the same thing as a half page Java Program. But to debug it, you might need to read a 50 page manual and take consciouness enhancing drugs.
Not that I think Scripting languages should be discriinating against. I can relate to comapnies who want to focus on one language, though. At least it sounds like a good idea, otoh I don't know if it's very realistic.
In any case, Programmers could still use scripting languages to speed up their coding in other languages, ie for code generators.
How about that? I'm an Enterprise Systems Engineer. I use both Scripting and Programming languages. I also design systems that incorporate scripts, programs, applications, physical components, etc. That's what engineering is, creating something using many different components. I'm a programmer, a sysadmin, and a 'scripter' if there is such a thing.
Back in the day the difference between a script and a program was simply how it was run. A script was a interpreted (usually line by line), and a program was compiled into the native machine language. Hense scripting was writing scripts, and programming was creating a program. Back then scripting languages were usually very very simple, such as shell scripting. They would execute a repeated amount of statements and become the glue between programs.
Today however technology has progressed so much that the line between a script and a program is blurred so much it's become irrelevent. What is Java then? You compile Java into bytecode, and then the bytecode is interpreted into native machine code, sometimes constantly, or in the case of a JIT, once.
Luckily I'm in a company with a manager who doesn't care how it's done, as long as it's done to specification and done by the set due date (which is flexible within reason). I use all kinds of languages, C, Perl, Java, PHP, Shell scripts, flat out SQL and PL/SQL.
Of course this is my take on it. And in Slashdot fashion I'm sure at least 10 people will point out 'flaws' in my comment and how it makes me stupid.
..There's a-dooin's a-transpirin'
Don't look at it as *their* unwillingness to learn new things, but rather as their maturity to recognize that a current tool is "good enough" to get the job done. When it comes down to it, is the (performace gain/footprint/portability/insert favorite reason here) a justification for the increased cost? If it is, then by all means, kick the programmer in the butt and make him learn a new language. If not, save everyone some grief and just get the job done.
Working around strong typing is like not wearing your seatbelt: you may get away with it for a while, but eventually something will go wrong, and the consequences will be horribly magnified because you circumvented the safety system.
A large part of programming is knowing how to get the computer to do your work for you, and a strong typing system can be made to do a lot of work. I make a point of never using Strings or ints to indicate state/type information. I define a DataType object, and implement a Visitor pattern. This lets me leverage strong typing: a method that accepts a DataType object knows exactly what it's getting, and implementing the DataTypeVisitor interface forces me to handle all possible cases, and all of this is caught at compile time, long before it causes any real damage.
...the next wave of technology.
It seems to be the natural evolution of things.
First we had machine language, where you actually input the programs in binary using front panel switches (yeah....I'm an olde phart and I remember those days!).
Then we had Assemblers, that made things a bit easier.
Then we saw the development of C as a higher level of assembler.
Basic came into play and presaged the scripting languages.
After that we see rapid progression of C++, Java, Perl, Python, PHP, VB and many others, some closer to the iron and others not. Some compiled, some interpreted, and many both.
It would seem to me (from my aged perspective) that programmers are seen as dealing with a lower level of abstraction than scripters (this is assuming all other things being equal, such as ability to translate requirements into logical, maintainable code artifacts, which are the same on the part of "good" developers, regardless of language).
However, the next wave is already upon us. Consider Web Services. Basically a distributed component model with a standardized encoding (XML) and layered on top of internet protocols.
So what is the best way to "glue" individual Web Services together into an "application"? It's not to write code (be it programming with Java or scripting with Perl...subsitute your fav languages if you don't like my examples), since that pours "procedural" concrete (to varying degrees) on top of a very flexible component model.
It's to use declarative specification. So we are seeing the emergence of BPM engines (Business Process Management) which can execute the specifications (XML-based more often than not these days) and with graphical modelling/process flow creation tools (typically based on a variant of UML).
So whether scripters are lower in the esteem rankings than programmers is irrelevant, since the next wave seems to be specifiers.
Chaeron Corporation
I totally agree-the tools make the programmer in some cases.
for example, I'm comfortable with c/java/perl/php/ruby syntax, and the only real tool I need is vim.
If you throw me into a situation like COBOL where you need to work on a mainframe, or a logical language like prolog where the syntax is different, I crawl under the desk and weep.
does that make me a bad programmer?
probably.
Looking for Book Reviews? Check out Literary Escapism.
mslinux wrote:
The answer to "it runs slow" is almost
- NEVER
"more powerful hardware".Karma: Food Fight (Mostly affected by Date Plate).
I don't blame Matz for not basing Ruby on Unicode ten years ago. It *was* immature then, but it's not now.
But even now, ten years later, Matz has made it quite clear that support for legacy Japanese encodings comes before internationalization. His repeated comments about "EUC-JP is good enough for me" and "Ruby's i18n strategy is simply whatever doesn't interfere with my work in Japanese [which is legacy EUC-JP-based]" make it clear that he is a guy who spends his time on non-globalized Japanese systems, because EUC-JP isn't good enough for anybody except that kind of developer. Anyone else who can use it, fine, but he built it as his wrench for working on legacy Japanese engines, not for non-Japanese to build new, global engines.
He's the Japanese equivalent of all the Western developers who kick and scream about giving up their byte==char architectures for the sake of non-Western text. They don't want to give up the efficiency of byte==char, that works fine for their own personal "itch", for the sake of a bunch of foreigners who should go build their own languages instead of messing up *mine*. Well, Matz did, and with the same attitude.
"Unicode compliance" to the extent that it doesn't get in the way of legacy Japanese encodings and utterly absurd systems such as Mojikyo is not what I'm talking about. (There must be 10,000 developers who want to do custom memory management for every one who wants to use Mojikyo, yet Matz thinks making everyone use the same GC is okay (it is), but can't tolerate using a single universal internal string format because -- he always uses it as an example -- what about developers who might want to use Mojikyo instead? Yeah, all 7 of them. Absurd argument.)
Any language can add "Unicode compliance to the extent it doesn't interfere with the important stuff" as an awkward afterthought.
I'm talking about languages like Java and C# that are actually Unicode based, Unicode only, not "well, in some future version you'll have the option of doing some things with Unicode if you need to." Languages that take the stance that, although Unicode may not be as good at dealing with EUC-JP data as EUC-JP itself, it is by far the best for creating new large-scale, globalized systems and new data in all major languages. Java and C# have their sights set on the creation of new systems of this magnitude, while Matz seems to see Ruby as a utility for his own smaller-scale, geographically-limited chores.
I have no argument with a guy building his own itch scratcher, and I wouldn't even have taken notice if he hadn't done such an amazing job in lots of other ways. But the original article is about scripting languages not getting the same respect, and my point is that they seem to have their sights set a lot lower than Java or C# -- not focused on building new worlds but on tinkering with a few existing ones -- and that probably has a lot to do with it.
"Those who have never entered upon scientific pursuits know not a tithe of the poetry by which they are surrounded."
Languages, be they scripting languages or compiled languages are just tools. You chuck them all in a toolbox and pull the right one out for the right occasion.
In the same way that you don't use a hammer to remove screws, you don't use c++ to do some quick text munging. You pick the tool that will let you get the task done as efficiently as possible.
You also take into account whether this is a long term app or a once off problem solver. Do you really need a spec cycle, architecture, etc, to retrieve some data from a postgres db to a csv file? No.
Indeed. We have a term for this: Turing completeness. You can write enterprise software in asm if you're a masochist. You can write device drivers in awk if you're wierd. That doesn't mean you should do either of these things
"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"
If it is, they need to get some different C++/Java programmers.
The Kruger Dunning explains most post on
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.
For PhBs how the words sounds does matter much.
If we say "virtual-machine portable languages" instead of "scripting languages", I think the valuation of that languages will rise in the eyes of PhBs
REAL programmers:
- know that only weak-minded wimps need high-level languages like Mummy Java and Daddy C++ to write their assembler for them, or lets them shirk the responsibility of knowing what's happening in the processor.
- Are suspicious of assembler anyway, and prefer to write machine code by hand
All this is just a hangover from the 'programmers in white coats' syndrome from the 1950s and 60s. Keep the machine room door locked. Keep out the infidels. Talk as esoterically as possible.IMO, what this discrimination is based on is the fact that with scripting languages, especially Python/Ruby/Perl etc, you can achieve the same task in minutes that in C/C++ or Java can take hours/days/weeks. Same as the recording industry trying to block digital distribution. And same as the ferry operators who would try to stop the bridge from getting built.
It's just "Job Protection". Period.
-- In the beginning was the WORD, and the WORD was UNSIGNED, and the main(){} was without form and void...
I program in Tcl and Python, and they are great for a certain class of problems, but they are certainly not right for everything.
For large projects that are shipped to a customer and must work right in the field, scripting languages are inappropriate. An air traffic control system, for example, should not be written in a scripting language.
Having said that, Python is great for analysing air traffic data and for automated testing of air traffic control software. I know because I do just that routinely.
I watch Brit Hume on Fox News
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.
As an avid PERL hacker (for the past 7 years), I find myself increasingly at odds against the onslaught of Java newcomers. It seems that these days, what really matters to IT directors is the "fashion" value of a language and not its real merits.
Where I work, I see this happening everyday. New projects are, by default, assigned to Java adepts even if they are relatively inexperienced or even fresh out of college/university. The whole market, here in Greece, is quickly veering towards this direction. The funny thing is, that these people quickly discover that doing productive work in Java means you have to have someone with at least a few solid years of coding behind him. So you have a large number of softcos who are looking in the market for people with 2-3 years of EJB experience and the market simply cannot supply them.
So when we scripters go to them and propose a working prototype in a few weeks (vs a few months) with object orientation, proven performance and plan for future maintenance all we get is a smile, a hint of irony and a short dismissal. No arguments, no discussion.
Makes you wonder, how these people got to be IT directors at all...
That said, it is true that scripting, with all the freedom it offers, requires discipline to write maintenable code. Java on the other hand, with it's huge APIs provides a strict framework which sort of guides you through. An inexperienced coder is bound to write better code in Java than in Perl, most probably.
And that is the crux of the thing. Experienced programmers are hard to get by and command larger paychecks. Once again a financial decision is made opposing technical considerations.
And the suits win once more.
Scripting is an artificial distinction. Both scripted and compiled languages are turing-complete.
I work for a company that only uses enterprise coffee pots.
We are more concerned about products that are considered "enterprise", than solving a particular problem. From what I can see "enterprise" is an alternative spelling for "expensive".
Scripting languages are free and therefore not taken seriously.
The perception is that COBOL, VB and Java programmers abound and are therefore technologies worth betting the company on. The perception is that there are so few programmers out there (witness the lack of job listings for programmers) that script code could not be maintained.
All this is sad because our current Java project is a year behind schedule when at least parts of it could have been scripted.
i regularly encounter perl "gurus" who are terrified of lower-level languages. i put "gurus" in quotes because their perl code sucks, too. i think most geeks have picked up on the strong tendency for exclusive scripters to be poor coders because they're just people who picked up a language's syntax rather than really learning how to program.
hence the heirarchy even among scripters; if you use a unix shell regularly, scripting in that shell is a cakewalk. you just type the commands you'd type at a prompt, but stick them in a file. if you put in some "if" or "while" statements you can congratulate yourself by writing comments and feeling like you have arrived somewhere.
as a result, i'm not impressed by "i know perl." i AM impressed by "i know C/C++, perl, shell, tcl, expect, python, ada, dibol, java, and pascal." while he's not likely to use pascal anywhere outside of a classroom (ok, maybe the odd legacy job), the fact that he has so many tools in his toolkit shows a broader understanding of how things work and more flexibility in how he'd go about a certain task. it also means he could probably pick up a new language more quickly than someone who just knows perl (and, thus, would be unlikely to understand things like pointers and dynamic memory allocation, CLEANING UP AFTER YOURSELF, and data structures like linked lists or binary trees).
"Mister Potato-head --MISTER POTATO-HEAD! Backdoors are not secrets!" (War Games, 1983)
A programmer is someone who has (in)formal education in information sciences including common data structures, design patterns, algorithm, and algorithmic analysis.
With the above skills, one should be able to master any language--compiled or interpretted. Often, the term "scripter" is used to describe someone without an understanding of the above who limits themselves to scripting languages.
Obviously, the later is inferior to the former. Most people tend to favor a language but even if that's a scripting language, that doesn't make one a "scripter."
Now as to whether a scripting language could solve problems more effectively, that's simply not relevant. The largest cost in code development is maintaining and expanding existing code bases. Therefore, it is more economical to use languages that are more widely known.
More people know Java or C++ than python or perl (at least, in enough capacity to do something useful). Therefore, in most circumstances, they are preferrable.
int func(int a);
func((b += 3, b));
This is why I hate Slashdot. I've never contracted for the US government, so I take your rather interesting comments on that as fact. I have no reason to doubt them, and they seem intelligent and observant. But then you start in on Perl and start pulling assertions out of your ass. And anyone who's reading this and doesn't know Perl well will likely just take your assertions as facts, due to how your earlier statements on government contracting seem authoritative, and you communicate your (mistaken) Perl oppinions as fact, as if "no one reasonable" can disagree with them. And your comment is rated a 5, so some pointy headed boss who's reading this flamewar because he's wondering what the difference between "scripting" and "coding" is is going to see "Perl is not an appropriate choice of language for production systems" and see your 5 rating and think it's a fact.
But it is a LIE.
I have to chime in here. I've been programming in C for 15 years, Perl for 13 years and C++ for 10 years. Consistently, I've found that Perl takes much less time and effort to program, because it encourages coding at a higher level of abstraction.
Note that I'm not talking about the rich CPAN library of modules you can leverage. (Java isn't the only language with a rich API library available.) I'm talking about new code, not slapping together API calls.
I remember an occasion (about 11 years ago) where I was wrestling with a 20-page COBOL program designed to export data from native COBOL files into flat ASCII text files to be imported into another system. This COBOL program was very slow and kept failing randomly. I could have spent weeks trying to fix this program, but I didn't. Instead, I spent an hour or two analyzing the data format. Before long, I understood the string format and the BCD-encoded number format used by that COBOL compiler, and determined the field layout in the binary data records. Armed with this knowledge, I wrote a Perl script to export the COBOL data into flat files.
The Perl script was literally around 8-10 lines of code -- the "unpack" line took the most effort, because all that data analysis went primarily into that one line of code. If I recall correctly, there was also a line or two that finished decoding numbers. There was a print statement to output the decoded records as flat ASCII data, and a read loop around the whole thing. It took VERY little code, and most of the effort was analyzing the data format. Writing and debugging the actual code took somewhere between 10-30 minutes beyond the time spent on data analysis.
This Perl script was bug-free when I finished -- it exported all data records correctly, and was even able to export the record(s) which caused the COBOL program to crash. Moreover, it converted the entire data file in 1-3 minutes, while the COBOL program took several hours to reach the point where it crashed about halfway through. (This was on 386 machines at the time.)
Now, some people would look at the Perl script, see that it's only a few lines of code in a "scripting" language and conclude that it's not "real programming". That's bullshit. Real programming is about problem solving, not the amount of effort expended. As a programmer, I'll choose the best tool for the job, instead of trying to make one tool (C, C++, Java, etc.) fit every job.
The same people who would disdain that Perl script would look at that 20-page COBOL program (i.e. >1000 lines of code) and say that was "real programming". It sure took someone a lot more time than I spent on the Perl script, and it looks like a more impressive piece of code to a manager, but both programs solved the same problem. To claim that one solution is more "real" than another is ludicrous.
Moreover, the Perl program solved the problem better -- it was literally about 1/100 of the size (in terms of lines of code), ran about 100-300 times faster on the same data, and it was more robust (the COBOL program crashed on certain records, the Perl script didn't). By any useful metric, the Perl code was easily 100 times better. (Ironic, given that the COBOL program was handling its native data formats, while Perl had to decode a foreign data format!) The COBOL program could be considered better for the programmer only in terms of politics. It's a lot of work (keeping busy is good for job security) and it's complex enough to impress the non-technical bosses that usually pay the bills, while the Perl code makes this programming stuff look easy by comparison.
The main reason my boss was impressed with this Perl script was that I had the COBOL program in hand as a baseline for comparison, so he could objectively see that my code was a fraction of the size, orders of magnitude faster, and that it didn't crash when the COBOL program did. Without that COBOL program for comparison (which someone else wrote), my Perl script probably would have looked rather utilitarian. (Which it was, actually!)
People often believe that I think Perl is the best solution for every problem. That's not actually true, but often time is of the essence, and when optimizing programmer time is a top priority (which is usually is these days), Perl often wins hands-down as the most effective tool. Why spend a few days or weeks writing something in Java or C++ when the same problem can be solved with Perl in a few minutes or hours? With Perl, I can be off to solving the next problem much sooner, which is important these days, when TODO lists always seem to grow faster than items can be checked off. C++ may be faster at runtime, but it takes longer to write the code, and often the added runtime performance isn't critical.
Perl is a real programming language, and an excellent general-purpose language for many tasks, especially backend processing. Good Perl code isn't cryptic or hard to maintain. If anything, it's easier to maintain because you don't lose sight of the forest for the trees. However, to maintain it you have to know Perl. If the existing developers don't have the Perl skills, isn't that what training is for?
Deven
"Simple things should be simple, and complex things should be possible." - Alan Kay
However I do feel that the impression, that pure scripters are, on average, not the most meticulous software designers in the world is not completely contrived, especially when I read many of the comments in this forum. Claims of Perl programmers being thousands of times more productive than Java or C++ programmers are simply ridiculous. This only shows complete lack of understanding for the role of programming languages in the overall software engineering process. But even without things like analysis, design, deployment, maintainance, team communication and so on, I challenge anyone to choose a programming task that he can solve in hours using Perl and that would take me months to solve in Java or C++.