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?"
true.
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)?
I got this FP by writing a perl script.
W00t!!!!
--The AC
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.
I think any good programmer (or scripter) would know there's the right (or better) tool for any job.
I hate it when I spend too much time writing C/C++ code, and figuring out later that it could be replaced by a simple 4 line Perl script.
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.
Show me a talented scripter that does not know another language, and I'll show you a dot-bomb refugee.
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
All the ladies give my Python some respect.
Yes, I'm -that- guy from TV.
The company that I am working at (Fortune 500) is in the process of a Linux migration on some of their servers. I was asked to write a VC++ application to run as a service on a dedicated Win2000 server. The service reads text files from the Linux server, modifies the text formatting, and then puts them back on the Linux server. I could do this in BASH using GREP in about 1 hour, but instead the company requires a "program", which is going to take a week or two to code, QA, test, and deploy. Crazy.
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?"
In other words, it doesn't matter if you are a script kiddie or a hacker just as long as you get the job done
Choosing a language or programmer which is not strong on structure is a judgement call that is sometimes appropriate and sometimes not.
I think we would need to hear exact and complete cases before we could make any sort of intelligent determination.
Mistakes happen. Bad judgement happens. Also, good judgement happens that isn't recognized by someone lacking expertise and the big picture.
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
How did that comment get Score 5: Funny ?!
"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
I know this is just flamebait, but I must reply. Scripting has a place, as does "programming". Use the right tool for the task, and you will win (normally).
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
Sorry to point this out so bluntly, but scripting is a *lesser* form of programming. Scripts are usually very specific to their task (i.e. they take in non-generic inputs/generate specific output). The actual code in a script is usually structured very badly, without any regard to future maintainability of the code. Primary task is to get the script working to solve a particular problem as quickly as possible, resulting in code that is of lesser quality than a program would be that solved the same problem.
Don't get me wrong, there is nothing wrong with this (non-maintainability/bad code etc.) in some cases... I'm just trying to point out, why some firms would be prepared to "waste" 5 days (time and $$$) getting a "program" written to deal with the problem, rather than a "script".
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
Answer, yes. Reason--because Perl sucks. If you want a problem solved in a few hours and you want the resulting product to be unmaintainable, call a Perl scripter. The Perl guys have given all scripters a bad name--I don't know anything in my workplace that is built with Perl that is maintainable by anyone other than the scripter who wrote it. Quality of the solution over the speed of the solution---
Should they take a look at the scope of the work. Do some estimation, then assign the time? Yes, if they assign the time wrongly, why the programmers/scripters words up?
Then, no one has good estimate on things, so, shouldn't the engineers/programmers/scripters update the progress to his boss on detail basic so, things would not be so understimated?
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.
deserve's got nothing to do with it...
for optimum use of porgramming time. A programmer can often accomplish the same amount of productive work in one tenth the time using scripting languages such as Ruby, Python, Perl, etc., than when using systems languages like C, C++ and Java. This is a real productivity savings that companaies ignore at their peril; processor speeds are improving as Moore's Law operates over time; but human brains are hard wiored and don't evolve so fast ;-)))
Programmer productivity, that's what it is all about; I defy anyone to define a good reason not to use scripting languages where they are appropriate! (Fire away!)
Scripting Language City at http://www.awaretek.com/slc.html offers many detailed insights into scriptign langauiges, their uses, and how to learn them and get the most out of them.
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!
Agreed. He's trying to cash in on some karma by posting early, even though he might have had something insightful to say if he had thought it out. The least he could have done is provide some EXAMPLES of scripters being biased against, since he seems to have such person knowledge.
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)
I agree, and this sums it up...
"Never attribute to malice that which can be adequately explained by stupidity."
Not only are the two groups not-mutually exclusive, but both tools are used akimbo. How often do programmers run their compiled binaries with shell scripts? Or Perl?
Any such distinction between them is better explained along the software programmer versus system admin dimension (programmers do more programming, admins more scripting). At that point its more of a trivial social exercise: the same with Emacs versus Vi (and how often has someone been "discriminated" against for that?).
In the end this is ridiculous. No one is getting denied health care, civil rights, or a way of living depending on their ability to code or script. If work was denied to you it just means the person is an asshole. And assholes only follow their own twisted logic. They might shit on you for being a woman, or fat, or any other non-important reason.
In the real world, this pales against real issues.
What is music when you despise all sound?
It didn't. Its actual score is 0.
Is this a sigs-optional kind of place? 'Cause I am totally down with that if you know what I mean.
Because sometimes the development time is faster in using a script than an application. There are plenty of tasks where resources aren't an issue as much as just getting the damn job done. That way, everybody can get back to the real work at hand.
No I'm not trolling.
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 think it is lot to do with the Program Manager who decides how a task has to be implemented. In most cases, these guys are not technically good.
I've experienced this first hand in the past, when I was merely a "scriptor". I don't believe however that it is descrimination so much as poor management, or managements lack of understading it's uses. A good manager should be well-rounded and probably a programmer her/himself with knowledge of both compiled and scripted languages. I've recently become pretty handy at both, and I'm finding that more often than not, I end up choosing a script, say perl or php,etc over c or java for day to day utitilties.
Are you sure? It says "Score 5: Funny".
yeah whats up with the bigotry angle. with coding there is actually a difference in the different languages, but with skin color it's no difference. are you honestly comparing the plight of people who have suffered from racism to a stupid programming language
Why should the standard be a Programming Language (C++ or Java) and not a Combination of Programming Languages and Scripting languages (Java & Perl)
As its been said in the past, always use the best tool for the job. And sometimes you need to standardize on a set of tools instead of one tool (Metrics vs. Standard, etc.).
At my office we use Java for quick GUI apps but use Perl when trying to manipulate files before processing in the Java apps. Trying to do it all in on language would take way too long and way too complicated.
As far as maintenance, keeping up to date on Perl and Java isn't too tough. Just keep the # of languages to a minimum and things should be just fine.
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...
the real 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
This phenomenon sounds like ignorance of scripting's capabilities rather than discrimination against it. I doubt that many companies would deliberately assign extra work just to stick it to the Perl programmers. C++ would seem like the safe solution to a manager too busy or lazy to learn about a scripting approach. To the most literal-minded manager, a "program" will likely seem like a more robust solution than a "script." It's a PR problem.
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.
Anyone that can script cannot necessarly program. Whereas those that can program can pick up a scripting language in very little time. However if you have someone who can script and a programmer who hasn't picked up that particular scripting language then common sense says go with the scripter as they already know what the heck they are doing.
(Sponsored by cheeseSource for President 2012)
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.
Execution speed is hardly the only consideration, and often is way down the list of priorities. A one-shot, ad-hoc request for data can be quickly fulfilled with a script that might otherwise take hours of programming/debugging. Even fairly complex tasks that are not speed dependent might be more easily maintained in a scripted language. The requirements of the task should drive the language decision, not some arbitrary concept of what "real software" is.
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.
That distinction is retarded. Use the right tool to solve the problem.
"Java Programmer" or "Perl Programmer" are things to put on paper, not to actually practice. Why use a hammer on a screw?
Unless you're a "Python Programmer". Then you should be put up against the wall, you commie scum.
Assuming this isn't sarcasm... It's because frequently the development time is a hell of a lot faster. Sure, you may be able to write a program in C that runs in half the time as my Perl script, but when my perl script runs in 15 seconds to begin with, you've probably spent several more hours (at least) to lave 7.5 seconds. I guess I must be both a programmer and a script kiddie. When appropriate, I use Perl frequently. Other times, I use C/C++ with/without Oracle's ProC compiler. Sometimes one is better, sometimes the other.
A modern day witchhunt.
... the real bad attitude toward scripts is based on experience...
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 think that scripts should be limited to small and easy to understand tasks. They are often easily broken. They often make dangerous assumptions.
Another point: I know good classic programmers that are also good scripters. I know far less scripters able to become good classic programmers.
...But yeah,budding Scripters in Hollywood really feel discriminated by the production programmers:-)
I've never understood why people want to write anything in a compiled language, given that hand crafted binary 1's and 0's are, without exception, faster than compiled languages (C/C++, Java, O'Caml). Perhaps people who write real software resent those who try to take shortcuts with their software engineering.
An excellent example of someone who doesn't understand the strengths of scripting. Apparently speed of execution is the only measure of a language?!? What about speed of development? Platform independence? Readability of code? etc...
http://www.missionfaces.com/
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
Really..I just finished my last My Own Operating System project (MYVBSOS) in VBscript yesterday.. Really it so ultra fast...
Its TITLE is score 5: funny. Are you stoned ;)
There's nothing like the good 'ol eval()...impossible to use with compiled languages.
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.
I believe that scripting is a form of programming and that the real issue here is not the language but the talent of the programming.
Someone who is a god-like scripting most likely can also program non-scripting languages fairly well too. And someone is a moron at programming non-scripting languages is going to be a moron when doing scripting work.
Good programmers are good programmers. If you area good programer you should be able to program in any language.
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 :-)
If someone "can't" use one of those types, then they aren't a real programmer. If someone won't use one of those types, then they aren't a real programmer. If someone always recommends the same language for all tasks, then they aren't a real programmer.
A real programmer says "oh, you don't want me to use Perl? Well, ok, that's not what I'd recommend...so give me the spec and I will do it in Java."
The cake is a pie
how much does this really matter for something that will take 30 seconds to actually run even as a slow interpreted language, aside from overhead from network interfacing that it would take anyway? You're just as bad as these people the article talks about.
In SOVIET RUSSIA... erm...NSA AMERICA, the Internet logs onto YOU!
Most people think that scripts cannot scale. It is hal true, because most scripters usually write fast and good code, but without documentation and modularity. But I believe that is because the problems usually assigned to them does not need it. If bosses treated scripters equally, I think they usually would have better professionals that always coffe breaking "programmers".
The thing that upsets IT management the most is who writes these code rather than what the code is written in.
At any company there are subject-matter experts who know all of the ins-and-outs of something (the business rules, the production workflow, the style guidelines, etc). These are things that the IT staff does NOT know and is at the mercy of these other departments to provide. If writing even the "simpler" tools in higher level languages was allowed or encouraged, then that could cut out a major portion of the work, control, and power that people depend and fund the IT department to do.
It's not because Perl, Visual Basic, and AppleScript aren't feasible alternatives; it's because in many cases they are.
I am unable to mention to my boss that I accomplished a certain task using Python instead of C++. The good thing is he doesn't check on non-production code much.
Sorry my bullshit sensor overloaded.
If speed were the issue, and everyone worked in C/C++/Java, then there'd still be a significant number of people doing things wrong. They'd just do it wrong very fast.
;)
Don't blame your language on your quality of code. Anyone can write really crappy java as well as write realyl great perl.
Python, well.. nevermind
-
ping -f 255.255.255.255 # if only
If scripters are regarded wish such a low level, why isnt perl considered a low level language?
Im dreaming ofa big bndwdth, That can resist the
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".
In a decent company, the language used is not a management decision; it's a decision that is left to the developer. The developer is (or should be) rewarded on his or her ability to get the job done, not for using this or that skill to do it. Most "scripters" of my acquaintence were hired as "coders" but use their scripting skills whenever it is appropriate. I've never seen a manager upset because a developer used a script instead of code, but I've seen a number impressed by a developer's productivity brought about by savvy use of scripting.
===== Murphy's Law is recursive. =====
I think the distinction between a scripted and a compiled program is made at runtime. C is compiled and at runtime is composed of assembly code/machine language. Scripted languages are not compiled into machine language, they are interpreted at runtime from their original source files.
Scripting, typically, does not protect the I.P. as the source can not be distributed. Even obfuscated source isn't enough.
... pending. And others intimate that the source is protected while merely being obfuscated.
It's hard to beat binary executables. Sure, you can try to reverse engineer them, but it's quite a bit more work than a de-obfuscator or cat'ing the Perl files.
I would love to use Perl. Or PHP. The state of the projects dealing with code that can be protected is still
Please.
So, yes, if I could use a scripting language for business, other than in-house service stuff, I'd go for it in a minute. Until then, it's C and others.
Yes there's a bias. Who cares if it can be accomplished faster if the source is unprotected?
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....
you wanna pick up somebody's perl code (or even your own) six months later?
My problem? I was perfectly gruntled, until some numbnuts came by and dissed me.
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?
Code you do for in-house projects can probably be a script. For QA projects, scripts are the rule rather than the exception for 2 reasons.
QA is never given enough time, so it's script, script, script.
Scripting, because of it's high level, is easier to modify quickly in response to changing requirements.
--
othermark
(!wired)?(coffee++):(wired);
Say you have a product-development task to do. (Create a little utility), and all your product-development developers are c++/java developers. Now lets say the utility is easily done in perl, but the only perl developer is the sysadmin for the company unix box.
If it's anything more than trivial, do you think the IT manager is going to give up his only unix sysadmin to do something for another department? Especially since IT and Product development probably fight like dogs.
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...
It always bugs me how I find job ads for "Query designer for MS Access".
The ease-of-use factor is preached to the suits and not the to short-changed developers.
This is why human resources skips over anyone who mentions something they don't understand like PHP or MySQL or Unix.
The message on the other side of this sig is false.
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!
Some good points in the parent post...
I'm still a little dubious on the whole concept of this gaping divide between coders/scripters (like a lot of you), but let's leave that alone for a sec.
If your coders have no idea about the capabilities of the scripting crew, and visa versa, projects will often be mismatched to technologies. At a bare minimum, you need to have a tech lead or head developer who fully understands the scope (and future scope) of the project, who can match it with the most suitable language and/or environment. They work with management (who will know if, for example, you have 4 coders who'll be on the bench in a week) to make the final decision.
Choosing the technology should never be a purely mgmt decision, though, nor decided by someone who only understands one path to the solution!
If there's an oversimplification in management thinking (i.e., big project == Java/C++), it's the responsibility of the people who know better to straighten them out.
--
Everything should be made as simple as possible, but not simpler. -Einstein
There are only 10 types of people: those who understand decimal, those who don't, and, uh, 8 other types I forget.
...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 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
Well, that sounds like poor management. There's an old saying, the proper tool for the job. There are definitely tasks that can be performed quicker and easier in scripting languages such as Perl or even VBScript (particularly in Office documents, if you have VBScript enabled outside of that your asking for trouble (figured Id head that troll off at the pass)) that can be performed quicker and easier than in C, C++, or whatever. We used to have discussion with professors about C++ vs. Visual Basic, and how some tasks could be performed better in VB than in C++. This is a generalization excluding things such as code size and such. But I would have to agree that there is definitely a distinction between "programmers" and "scripters" in the eyes of management and employers. I guess they see things such as automated memory management, interpreters and scalar variables as being weaker than declared typed variables and compiling. Kind of reminds me of the Artist vs. Inker/Tracer argument from Chasing Amy/J&SB Strike Back.
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.
Personally, I'm still pissed LISP machines never took off©
I've seen scripting lead to shortcuts or obvious breaks far too often. It's far too easy to miss details in scripting by making assumptions that are convenient for the fast paced development tool. For example, assuming that input is line oriented, or that all of the input can be held in memory at the same time. Yes, you can make the same mistakes in C/C++. It's not done nearly as often, because the rapid developement and general assumptions that make scripting so fast and easy are missing - you have to think about each piece.
Scripting is slower as well. First of all, it's interpreted, not compiled, and most scripting languages are not lightweight to parse - they have a very flexible syntax. Also, it's fairly common for these syntaxes to transparently support different data types - meaning your data gets converted from strings to numbers or whatnot in all sort of places you wouldn't normally do that in C/C++. Often, regular expression matches/rewriting are thrown in as an additional feature, and abused for doing very simple things - changing case, re-ordering terms. Yes you can use perl hash tables and write fast scripts. Yes, you can write very poorly performing C/C++ code. I have yet to see a case where a well written C program can't outperform a scripting language.
Yes, scripting can be done well. In practice, most of it is thrown together quickly, or maintained by multiple authors with varying degrees of skill, and it quickly looses its value as a reliable and efficient tool. I think this is why it is relegated to the "quick and dirty" prototype status.
I was a contractor at a bell company doing internal tools that screen scraped from the old mainframes that they had.
You could write in C, yacc, lex, sed, awk or ksh. Not Perl.
They didn't trust it.
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
As an ex IBM'er we used whatever language served the purpose the best. For things that took a lot of IO with test equipment we used C or C++. For parsing the 100meg HDL files for the circuits we tested I used PERL. I think that scripting does get a bad rap as it truly in NOT a real language but I think that in the end it only matters the task at hand get done.
And in what category will fall a C or C++ programmer if you have things like C/C++ interpreters ?
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 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?
if the grep function were to be available as a function in C, it would take you the same amount of time. The problem is that C code is more primitive and that the necessary libraries are not available.
If you want to be a scripter, but don't get no respect, perhaps you need to find the job that fits your skills. As a DBA, I find that employers always specify that I must know shell scripting and something else along the lines of Perl.
So I'm a BASH and Perl guru. I have to be not only to get my job done, but also to be employable and to get the respect a DBA gets.
fifth sigma, inc.
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
- They've got lots of lines of code
- The staff cost lots of money
- The technology cost lots of money
So, write a database front end with Perl and DBI in two weeks, and that's virtually an admin task. Get a team of five high-paid Java developers using Weblogic to do the same thing in six months, and that's worthy of respect!I'll admit - a lot of the little processes to do this and that (sync a database to LDAP, expire users, etc...) are scripts.
I think too many bosses have the idea that scripting consists of what they remember about Batch files and that's it.
Sad thing is the ones that think that perl or php is some toy scripting language have no trouble buying into a series of asp SCRIPTS written in VB.
At least I don't hit resistance, just "You can do that? Wow."
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.
"Not only are the two groups not-mutually exclusive, but both tools are used akimbo."
"Akimbo" means with your hands on your hips and elbows out point outward.
definition
I'm not sure, but in my building, there are three bathrooms -- Men, Women, and Scripters.
Bizarre assertions. My experience is that 'modern web techniques' rely less and less on IE -- the DOM is well-ratified, cross-browser support is ever improving (particularly if you force IE to behave in a compliant fashion), and single-browser-only stuff has fallen out of favour, at least from where I'm sitting.
CSS has no intrinsic relationship to anything like Dreamweaver - at any rate, to argue that it's 'weak compared with Flash' is to ignore much of its strength - that it degrades gracefully and provides an elegant approach to developing for multiple (present and future) web platforms, from traditional browsers to handhelds, projectors, printers, or whatever. CSS isn't 'about' graphical effects, either -- in fact, there are probably more parallels with something like Acrobat than with Flash.
I've no experience with CSS 'interacting badly with firewalls and proxy servers' -- what could be 'hostile' about CSS, which essentially just provides a text-based presentation layer?
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...
That is why its banned on most MUDs.
And if its not banned, it gets banned after I come on and write my scripts.
My manager doesn't even know the difference between scripting and programming. PS. I work as a sanitation engineer in LA.
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.
A project that mus be done, should be done what would be best whether in a scripting (Perl, TCL, PhP) or Programming Language (C, C++, Obj-C, Java). Though true that both C & Perl can be compile into run-level code, Perl isn't as optimised as C can be. And in the same way Scripting Languages that Haven become Programming Languages (ie. Visual Basic) has bcome a bane because of the amount of slow buggy crap that ends up out there because it's written in VB.
<RANT>
We use a system that is basically an Access Database manipulated by Visual Basic, and then compiled to make it look pretty. It's dog slow.. buggy as all hell and has slowed down a system that we use to be able to supply a quote in 5 to 10 minutes to taking almost half an hour. So I am biased against scripting turned into a programming language or compiling a script and calling it a program.
</RANT>
Mind you I have done both programming and a lot of scripting and I realize that there are strengths and weeknesses in both. But, and here's a big but, when a boss looks at the big picture they will look at costs in both training AND upkeep. Plus will look at what they know. They need a widget to access their database on a terminal... Use C/C++. Access the same daatabase from the web use Perl/PhP. It's not fair... it's just the way it goes.
Patrick Havens (Mr. 573333 to you.) Graphic Artist / Coder / Father / Journeler
The primary reason for such discrimination (which does happen, as a freelance contracter I've seen it repeatedly in many places, from both sides of the compiled/scripted fence) usually has very little to do with the view that one type of language system is a professional tool and that the other is amateurish.
In my experience, the main reasons tend to be simple departmental strategy and politics (the last two are inseparable), internal empire building and associated defensive stances, and management concern that lone or paired scripters are harder for them to control than the typically more cumbersome compiled development team which usually requires a management presence to even work.
There is alas also a secondary issue at work, namely that because scripting is "easy" (largely an illusion on non-trivial projects, but nevertheless also partly true), every Tom, Dick and Harry dabbles in it, and as a result there are an awful lot of pretty incompetent scripters around, in an engineering sense. And that is a valid consideration: when a scripter hasn't even heard of regression or unit testing let alone doesn't do any (as an example), you can see how questions can be raised regarding what else is lacking in his or her CompSci education.
Ultimately, there are no good or bad scripters or C, C++, or Java coders, there are just good and bad software engineers in the broadest sense of the term, and a good professional always uses the best tool for the job in hand. The trouble is, you can't become a software professional overnight, even if you are the world's most insightful Perl guru, because there is an awful lot more to creating solid systems than knowing a language inside out. It takes a solid background first, and it takes a lot of hard-earned experience as well. The coding is just the easy bit in the middle, and unfortunately the amount of non-language experience you get from sitting at home working on your own apps is minimal.
In summary, yes, the discrimination exists, and a lot of it stems from some pretty nasty internal politics in a lot of places. However, a little of it may be justified, as the average level of competence among scriptors seems to be a little lower than among compiled language programmers, probably owing to very few of the latter being self-taught.
"The question of whether machines can think is no more interesting than [] whether submarines can swim" - Dijkstra
How about +4 ignorance / flamebait.
I pick scripting/programming language based on what datatypes and datastructures I need. Script languages (Perl, VB) usually have no strict typing which is a good thing as long as you do not care. When I know that I will/might use things like byte-arrays, linked lists, multi-dimensional arrays etc I go for C/Java/C#.
;)
;)
Some things are fundamentally easier to write if you got full control (like with c), given that you are competent enough to handle the task and needed tools
First consider Perl: if in doubt consider Java: if still in doubt consider C. In the MS world I think it is slightly different: Only consider C#
I really should start using Python, right?
Harder tasks can be solved in real programming languages than in script languages, thus programmers solve harder problems than scripters... And scripters solving hard tasks using scripts (or worse: Excel) are obviously stupid.
If I may...
I don't see how that is the fault of Perl.
Several posts here have attempted to make the same flawed point: If it's a script, it is therefore unmaintainable and poorly written. That's absurd. A bad programmer could write C that would induce a coma, while a skilled Perl coder could write a script that their grandparents could love. The language is irrelevant.
Don't blame the language for the mistakes of it's users. English is an excellent example of this principle.
Is it true that some people are so overcome with bias that they must categorize everyone into a "coder" or a "scripter"?
I look at it this way. Scripters of the world are kit bashers, they take all kinds of bit and pieces and assemble something to do a job quickly. Programers are more engineers, creating a solution to fit the design goals. Both solutions have their place. Just as it's costly to build a bridge everytime you want to get your tank company across a river it's also kind of short sighted to demand that the pontoon bridge you put in place goes on to serve as a permenant bridge.
Personally I've never seen much friction, usually because the scripters are also the SysAdmins and lord knows we don't want to have to actually support our own code, unless it makes us look more productive.
What if it is just turtles all the way down?
I am in a large "initech" like corporation and yes, we are forced to write slow bloated java apps instead of small fast perl/php scripts. So much so that people get fired for still doing it. It is a damn shame. I guess that "100% j2EE enterprise architecture" is a buzzword that no VP or higher can live without.
I have a thing that I tell people when this comes up: At one time I thought I knew UNIX. Then I programmed in C. At that point I learned I was only beginning to understand Unix.
I use both Perl/Shell/JavaScript/C/Java/Makefile, and etc int my development duties. Many of these scripting langauges do not fit in embedded systems so 99% of the time I stuck to C or I can do the extreme and do assembler.
In my dev enviroment, I use scripting for building code, server emulation, testing embedded devices real fast (expect). And for day to day UNIX server managment. But when it comes down to management of those devices, I usually allways rely on what I learned of Unix Internals to understand what is going on.
I think it is not Scripters Vs. Coders but more
Internalist Vs. Enthusiasts. Where the Enthusiasts may not fully understand the interals of th OS. To me it is more like the coders that did CICS and those that did Mainframe Assembly. The CICS codes knew just enough about the hardware to write CICS code where the assembly programmers knew enough for the hardware.
In the competive job market I believe the more you know the better. So learn scripting learn prgramming and learn your OS from the kernel outward. Market yourself as a well-rounded person that knows computers. Not just perl and not just C. You never know when you might need the other.
These are just my opinions.
Do Scripters Suffer Discrimination?
Who cares?
Doesn't gcc now have the ability to compile Java into assembly?
Sure you can come up with some computational program in Python etc. in a few hours as opposed to 2 weeks with C++/Java. Is that Pyton app going to be as easy to use for Joe Smith in shipping with a GED? Or will he have to go to night classes to learn how to use a command line with a config file?
And rightfully so,
The rise of the scripting languages has caused a loss in those who worship the tin god.
On any decent sized project I can code it just as fast in C with the core routines in assembly than most could do it in perl. On a small project, it depends on how many times it is going to be executed what route I would take (only once a day or so, I'd probably script it, very very frequently and I'll hard code it in something else). ANSI C is portable, faster than Perl (by FAR), faster than Java, etc.
No, scripters aren't programmers, you don't get close enough to the machine to qualify. You script, and it's closer to programming than say IRC scripting, which is probably what caused this entire debacle in the first place.
A language that was written in another language is always going to be more limited than the original language. Scipters cause bloat, execution time is important, hardware is getting cheaper but damnit you people need standards.
Looking over these comments I'm disgusted at what passes for a software developer these days. Efficiency doesn't matter... No wonder there's so much bad code and scripts out there. If you have developed any kind of libraries over the years you even put CPAN's perl modules to shame with the pre-optimized stuff you can pull off a disk.
The tin god will come to claim sacrifice soon enough... don't you worry.
I used to work for a majoring outsourcer (think elephants). I was called in to review a project that was way over time and budget. An outside contractor had been brought in to develop a steady-state monitoring system for a large distributed system over many UNIX and NT boxes. He had tried to implement it in C++, because that's what he knew, and had been at it for over 6 months without anything usable coming out. My analysis was that the code was crap, and could be replaced by an experienced Perl programmer using standard UNIX tools in a matter of a few days. In fact, a quick web search located code that could easily have been adapted in a matter of hours. The guy was terminated, his file marked never to be hired again.
His user manual was beautiful, though. Best description of how to click a gui button I've ever read. Shame the 150 pages never actually got around to describing the what or how of the system, but then I guess he never really figured it out himself.
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.
now that is funny!
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
I've seen a lot of good points here, but nobody's delved deeply enough into the "right tool for the right job" aspect. If you're doing something for config scripts or run-once or ad-hoc jobs, you're a fool to choose C++ or some other code-intensive, highly optimizable language. If you need something that's optimized for UI considerations (execution time, bandwidth, CPU) or for a tight batch, or you expect these considerations to be a factor in the future, the case for a tighter, lower-order (more Assembly-like) language becomes a lot stronger. You'll never convince me a strong C++ coder shouldn't make more than a strong Perl guy (unless we're talking about the kind of DBI/CGI/Shell Scripting monster who can be the one System Admin, Web Admin, and DBA in a small to medium-sized shop), but your company's only hurting itself if it doesn't see the value in employing both and having the pathways in place to funnel appropriate tasks to each of them.
If a co-worker or subordinate comes to you proclaiming that perl or php will meet the organizations needs just fine for all projects, yet he or she can't even program in c/++/#/java you have to question whether there is a conflict of interest. Is the person simply acting in the interests of self-preservation.
-= alphaFlight =-
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.
Those are issues to concider before starting a tool. If I could have a scripter spit out a tool that will serve my purpose for that day, but end up taking ten times the effort to maintain/extend it, I would rather have it done in a more formal method.
The fact is that scripting languages take on dramatic changes, which would mean you'd end up haveing three versions of the executation engine on your system.
Scripting languages provide a lot more flexibility in expressing those rules. If there are ten ways to say something easily then you will see all 10 ways used at some point, and you will have to deal with all 10 ways.
Also, often times, scripters are craftsmen and not formally educated in the art of software developement. While they come up with means and methods to get the job done, those means and methods are sometimes not the best route (complexity, flexibility of tool, speed, resource usage). So yes, craftsmen vs. engineers, engineers are more highly valued. I'm not saying just because you're educated you're good, it's my belif that one needs to evolve from craftsmen to engineer early in ones profession to be good. Not just become a programmer "because the pay is good" (somebody should have told them the hours and demands)
I'm not going to get into speed to execute instructions/p-code, it should be obvious, but this is much less of an issue to me, as the resulting internal quality of the tool.
system("sort list2");
Now, how do you write a realtime system with Perl? Answer: you don't.
I think any management team that would look down upon a solution that could possibly save time and therefore money is a bad management team.
All possible resources on hand should be evaluated before beginning a project. That's what a project plan's for!
If they are just rejecting a language out of hand because of the reputation of the language, they're not doing their collective jobs as one of the core components of systems design happens to be evaluation of all alternative solutions - both pros and cons.
Now if they actually did honestly evaluate to the full extent and still rejected your perl script.. well that's another thing entirely.
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.
Except for the part where he lumps Java in with C++. Has he used both of them? :)
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...
We sell a transaction processing application that has a CGI based GUI. It's written entirely in C++ because management doesn't believe in scripting languages, and doesn't understand what can be done to protect scripted code from prying eyes. As a result, our GUI is horribly slow, error riddled, platform dependant (HP, Solaris, & Win32), and extremely inflexible. Our customers hate it, and it has lead me to start an open-source project to replace our CGI GUI with an open-sourced PHP GUI. (Done as an un-official external project of course)
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.
You're right, static type checking is great for just that, making sure your program is type correct. But that doesn't at all mean your program really is correct.
Granted, un-tested scripting code is more dangerous than compiled, un-tested compilable code because of potential type snafus.
However, tested scripting code is better than compiled, un-tested compilable code.
And tested scripting code is, assuming you've written good unit tests, just as good as compiled, tested compilable code.
In scripting code, unit tests take care of psuedo-type checking, plus actual functionality testing which is much more important, to the point where the simple type checking that compilers do isn't really needed.
Of course the problem is that hardly anybody writes unit tests for scripting code.
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
Not called S'Kiddies for nuthin'. Scripts are for kids, and for things that any idiot can do. If they bring in the big guns it's because the job needs a real man, not a s'kiddie.
You use the right tool for the job. Period. End of discussion.
Yup. It's all because of the name, I think: people hear 'cascading' and immediately think of pull-down menu effects and the like..
Any medicine (programming language) that is held to be a cure for all ills, isn't. This has been documented long ago (in the 19th century already?) in the form of the song 'Lily the Pink' and her medicinal compound, that saved the world from misery by killing everyone that used it. "You have to use the appropriate hammer for a screw of a given size." ;-)
I think the larger the company becomes, the more removed from reality management becomes. Smaller companies happily use script languages because thier programmer/scripter guy told them to. When you put another layer or two of management in there, the guy who decides and the guy who implements are too far apart to have that shared sense of purpose. Upper management makes a decision without the input of the person or department that will implement that decision, leading to possible bad choices when it comes to the tools used to solve the problem. I'm probably wrong but would argue it over beers anyday.
an incompetent C programmer probably is the most likely to create unmaintainable code
A disgruntled GREAT C programmer will make completely unrecognizable and therefore unmaintainable code better than any incompetent C programmer (e.g. tuples vs. intermediary variable)
is like a baterical infestation. I worked on a large perl based ecommerce project and a large Java based Ecommerce project. In the end, to insure quality code we had 100% make sure use strict was used, we had to forbid many things Perl programmers pride themselves on in order to get 8 delveopers to stop duplicating work, stepping on each others code and make our code maleble to changes in specs.
In Java project it was sooo much easier. Sure it took a little longer to start up, creating the Beans, the database layer etc, but once we were going everyone used the code we created, adding features and dealing with changing specs were SOO much easier.
Now comes to the point of the title, we were on a tight deadline, so the bosses got a team from another part of the company to write a PDF generator. That piece came in Perl. Now the piece was writen by good, skilled programers, but dealing with different error log locations, creating processes for the perl interperator to live in etc was a nightmare. If we paid the $$ for a 3rd Party Java PDF writer or developed our own we could have saved a good 2-3 man months off of the code. I learned pretty quickly as the only 'Perl' guy on the Java side of the project, You should NEVER, EVER mix languages in a project.
Scripting languages are fine for small one-two page cgi programs, but unless you can crack a whip and get the programmers to fall in line, you'd better let the language and enviroment do that.
btw, J2EE are frustrating to Script Programmers because they were DESIGNED to be. But if you were ever in charge of divying out tasks in a large project you'll realize how J2EE was designed for you.
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 would love to hear an example of this. Off the top of my head I can't think of anything that takes weeks or programming in Java or C++ that you can do in Perl or Python in a few hours. Of course, I'm not fluent in Python really (ENFORCED formatted whitespace in a modern programming language???? What was he thinking?) but I am in Java, C++, and Perl, and although I will usually lean on perl to do my text processing I know from experience that I can do the same tasks in Java or C++ (especially given the now-ubiquitous regexp libraries) with only a little more effort, usually related to the extra work required setting up user interface and file I/O in the other languages.
Just an interesting instance:
The latest web based Yahoo! Chat client is DHTML based as opposed to its Java predecessor.
Yet another signature that refers to itself. The irony and humor is dead.
back in my day we didn't use nothing but assembly language-up hill both ways-in the snow.
CSS is fine, but it's positioning attributes are hacky and moronic. I'm bitter and unhappy about it, and continue to use tables which render faster, on more browsers, and in less code than the CSS. Not that you can actually implement the full functionality of standard HTML tables in CSS.
...knows how to do both.
At my former job I was not allowed to code in C because the other System Admins (except 1) only knew shell programming, so everything was done via scripting, including some not-so-trivial EDI stuff that would have been much better done in C.
As soon as management gets involved with decisions like choice of development environment, politics and perceptions of cost (accurate or otherwise) become infinitely more important than applicability to the situation or efficiency of use.
Programming lenguages can be either interpreted or compiled, but they are still programming lenguages.
/.ers said you need to know where and how use the right tools.
I don't think that because python is a interpreted lenguage you can say I write "scripts" in python.
Or haskell (nice functional lenguage).
I wouldn't call bash scripting lenguage a "programming lenguage", it has limited usage.
I believe there is a confusion here. Maybe WE have to check our concepts.
If there is a bias towards using a interpreted or compiled lenguage, maybe the software engneers are
doing their jobs right.
Like many
Another non-CS comment here. Machine code (ones and zeros) is considered to be a first generation language, whereas assembler opcodes are a 2GL. 3GLs are historically common; C, Pascal and Basic being typical examples used.
I don't quite agree with this, personally I would consider 'English' (SQL, COBOL) as well as other 'do more in less' (Delphi [components], Perl [regex]) to all be 4th generation. This is because 5GL has been considered to be real AI (as in "tell me if anything worthwhile has been posted on slashdot").
Everybody is SCRIPTING!!!
Isn't the CPU itself an interpreter?
I like to write everything in shell script, because then I can use lots of sed/awk one-liners. I don't have any problem developing in Java, I just use Runtime.getRuntime ().exec ("/bin/sh") and write the shell script I need to the output stream of the resulting Process. You can do something similar with C++, or a lot of times you can just call the same unix commands as C functions. Sometimes you get iowait problems 'n' have to add another rack sooner than you might have, but...shrug.
If my title says I'm a Programmer/Analyst then by gum it, I'm a Programmer/Analyst.
So far this year I've used C++, VB and VBScript at work. If my bosses insist that a program be written in C++, it's not me they're discriminating against.
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.
Welcome to our future. Get your $$$ while the gettin is good.
Outsource everything so no one can afford our product is the way our country is going. Good for the rest of the world, not yet sure if it's good for us, bad for us or makes no real difference.
Of course, I am the IT department, so it's pretty easy for my opinions to hold sway.
Miko O'Sullivan
How the hell did this post get modded up?
Going off the subject here but CSS/XHTML and Flash are two completely different things. You're thinking of DHTML which in itself is a combination of Javascript and CSS and a totally different subject. CSS has been relatively well supported since the generation 4 browsers. Especially in the layout and font manipulation areas.
The orginal post was right Tables especially on a site of this size is a mess and slows redering time incredibly.
"Not all chemicals are bad. Without chemicals such as hydrogen and oxygen, for example, there would be no way to m
If your programmers are doing 'weeks of unnecessary work' get new programmers.... and management. Perl/PHP etc are no slower to code in than Java/C++/Lisp etc. If you have good libraries and good coders, you have a good product. Process and management mean sooooo much more than programming language. Most projects fail because of bad management not bad programming.
You're not supposed to: HTML tables still exsist, and can be manipulated via CSS. Just don't use tables when the data isn't tabluar... (Like using it for layout.)
There are a few table-based layouts that you cannot duplicate with CSS, but very few, and there would be less if certain browsers *cough*IE*cough* would fix their CSS support.
'Sensible' is a curse word.
I've seen more cases of people bein biased towards scripting languages. If it were up to me I probably wouldn't hire someone who didn't know C or someother language at a similar level. And thats not because I'm against scripting languages, I just feel that learning to deal with languages which don't hold your hand is good mental training. I've found different languages encourage different ways of thinking. The more ways of thinking someone encounters the better their chances of solving a problem.
That having been said I find that Perl is more that sufficient for most tasks. And CPAN is the best thing since sliced bread.
Have you ever heard of the English "lenguage"?
I have a manager-type who also knows javascript. He knows it pretty good, too.
Unfortunately, because of this, it seems every problem in the universe can be solved with a little javascript. Perl? Java? No. It's allllll client side. Server side session manangement? Nope. Custom mod_perl handlers for authentication and authorization? Nah. Just one cgi script (not mod_perl-ized) and a bunch of javascript will do anything.
And everytime one of these scripts run, it spits out half a dozen warnings.
I won't go into the horror stories, because I'd have to get too specific. But's its pretty disgusting.
And he's not even a development manager!!! He's on the business side!
In real business programming, executive-level anything are so out of touch with any sort of programming or scripting that it all appears the same. Our VP of finance described once a project where an excel spreadsheet was modified as a programming project. To him, it was. To me, it was just a spreadsheet, and no more programming than typing a letter in word.
The bottom line should always be -- does the program do the thing that the user needs it to do, thereby making their job easier, or even possible?
The rest is just fluff.
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."
One thought that I have been bouncing around my head for quite some while is what differentiates scripting from programming. It seems like many people use whether the language is interpreted at runtime or executed by the hardware/VM to differentiate. I feel that this is not a good way to make the distinction.
My thought is that the issue isn't the language, but the "process model." The idea is that a program that does most of its work by invoking external executables is a script while a program that does most of its work by internals is not.
So, code that directly reads the underlying directory is a program while one that invokes "ls" is a script.
One of the things I like about this definition is that it fits the non-technical use of script as well. A script is a description of what the actors should do. If you consider the external excutables as actors, then this fits nicely.
An interesting side-effect of this is that a language itself is no longer a scripting or programming language. For example, if you have a
C program that looks like:
main()
{
system("...");
system("...");
system("...");
return 0;
}
then this is a script even though it is written in C.
That said, some languages will definitely promote scripting by automatically taking an unrecognized word and trying to invoke it as an external process (sh, csh, bash and sometimes tcl). But just because a language might be designed for one style or not, it is the program that matters.
First of all, he was referring to XHTML, which is not the same thing as talking about XML in general.
:)
XML, as originally envisioned, was a way to send structured data from one database to another (i.e. "in situations where no human looks at the content"). It's being used exactly as it was intended.
It makes no sense to anyone to send generic XML down to the client, unless it's in the form of HTML (i.e. XHTML). You send XML to another server, and it generates some pretty output to send down to the client. CSS is used to determine appearance, as it makes the HTML far easier to generate and less dependent on the program generating the HTML to make appearance decisions.
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?
Here's a hint : people who sell things generally don't like having thier prices compared en masse to a whole bunch of other people who sell the same things
Change the way you think.
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 think its easy to compare your statement to a troll.
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.
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.
You, sir, are mistaken. The original poster was talking about using modern web standards in place of kludgy code, and Microsoft is notorious for not supporting OR promoting those "real" standards. Their home page doesn't validate. I've yet to see any of their applications produce clean HTML or CSS. In fact, the only things that DO work consistently in Internet Explorer are things that break the W3C standards -- the flashy, IE-only effects that few people use but many people deride. Besides which, Mozilla supports those "modern web standards" much better than IE ever has. It boasts full CSS compatibility for Level 1 and most of Level 2; IE doesn't even support a subset of Level 1 correctly. I won't get into DOM support here, but Mozilla and other browsers beat the hell out of IE there, too.
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.
Again, you don't know what you're talking about. CSS dramatically reduces coding time, bandwidth usage, and maintenance problems to the point that stylistic changes are no longer a headache. Most browsers now support the majority of CSS L1 -- including IE 5.0+ -- and the sheer savings of selectors versus font tags is incredible. Even on "simple" pages, CSS is more efficient. I've never seen it interact badly with firewalls and/or a proxy server, since when it's done right it's linked as an external file just like an external script.
You're also wrong to compare it to Flash. CSS is about styling content, not "exciting animated graphical effects." That's what SVG is for, and I suggest you read up on that. CSS has nothing to do with vector animation.
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 [downside.com] 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.
False. XML is not intended to be the de facto standard for web communication. It's intended to be a standard data format that multiple, different applications can understand (including human readers.) If XML were the be-all, end-all of a user's browsing experience, the W3C wouldn't be working on another version of XHTML. Moreover, just because you're not seeing XML data doesn't mean it's not useful. Sometimes, companies don't want consumers (or their competitors!) to have access to their inventories and prices. As for XML receipts, I've yet to see a program that does what you're talking about, to say nothing of one that a consumer could use without requesting help from a geek friend.
Please, get your facts straight.
got standards? --- http://www.w3.org/
I have never personally seen any positive or negative bias toward "scripters" (a loaded term). I have seen close-mindedness on the part of C++ coders, though. There's a tendency to plead Turing completeness, deciding that Python is just a subset of C++, so what's the difference?
At the same time, I've noticed that the communities and forums involving languages that are easier to learn than C have a different flavor about them. For example, go through Usenet groups or forums about Delphi and Power Basic. Even though they're fine languages for Windows programming, there's the definite feeling that there are many more newbies and much less general programming knowledge.
I also think this question is a bit loaded, in that it appears to come from a scripting language programmer who feels he should be on equal footing with C++ programmers. It's not "C++ is awesome! " so much as that you can't write embedded code in Python, or that Python is the wrong choice for the Palm environment, or that you wouldn't write a Game Cube game in Python. So, yes, the C programmer has more doors open to him than the "scripter."
Even so, I remember when there was an Ask Slashdot about writing CGI scripts, and an appalling number of people said you should use C because "it is much faster."
The 'scripters' who are just sucky programmers in disguise ruined it for everyone.
Scripting languages tend to be powerfull and easy enough to use that they allow people who know hardly anything about programming to 'pretend'. All the ABSOLUTELY horrible code they continue to write has ruined it for everyone else.
If you don't know C/C++/Java you are a serf. Management asks: did you really decide to use Python because it is the best tool for the job, or is it because you are a fucking incompetent? Usually its the latter.
I can see how a discriminatory setup is established by those who really do not understand the engineering side of software systems. To them, the importance is getting that pretty buzzword class library or the actual implementation down so that they can say "they did that." Use what works. I have seen enough bad code, horrible (or none at all) planning, lack of clear architecture and just plain ol' bad development habits to make Bourne Shell seem a better alternative to whatever language these amateurs implemented. Remember that if you take a trained fighter pilot in a biplane and put him against a modern fighter jet with an incompetent fool... that fool is only going to win by severe waste of resources and perhaps only through a suicide run. The fighter ace will know how to get around their technical limitations and at least make the other idiot pay for any victory. I think before these organizations start barking about "scripters" being lower on the totem pole, they need to really figure out what it is they are wanting to accomplish. Buzz words do not a stable and secure (much less requirements satisfying) system make.
The people who think that way usually haven't a clue what tools you used to do it.
Just write it in Perl in 20 minutes, use a compiler like Perl2Exe to compile it, then give yourself a 2 week vacation, come back and tell them you spent the whole time heads down doing it in C++.
Remember, Ed is the standard editor.
first of all, scripting and programming are not synonymous. you can "do programming" in an interpreted as well as a compiled language.
now, i have a problem with people referring to java as being different than perl because perl is "a scripting language" and java is not. java is certainly not compiled. in fact, its bytecode stack VM is very similar to Perl's and Python's, the difference being that it's a bit more low level. java also has a much larger memory footprint than perl and an immensely larger startup time, (even _after_ bytecode generation, as the bytecode must be dumped to disk before the VM gets a chance to run) so it doesn't win there either.
so what's the difference between 'scripting' and 'not scripting' here? static vs dynamic typing? heh. it just shows that this whole issue is bullshit to begin with. people are stupid.
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 think this is becoming less and less of an issue as the scripting languages mature.
I've been using OOP design in PHP for several years now, and PHP 5 will have even better objectified design principles behind it.
Python as a language is extremely modular, easy to read, and very maintainable.
Traditionaly this hasn't been the case with scripting languages, as the code grew it bloated and was hard to work with(anyone here care to work with a 100k line bash or perl script?). And I think it'll be awhile before the new languages shake off that old stigma.
But really about the only different between, say, php or python today and java is that the scripting languages don't force you to use a particular design principle. You're free to be as sloppy or clean as you like.
And in a really big project there should be design constraints no matter what the language will allow you to do.
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.
Perl or Python = anyone can maintain
Obfuscated Java and/or C++ = job security
'Nuff said
Spread the RC luvin'
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
I agree that differences in browser support for CSS can be troublesome, but there's a large majority of CSS techniques (even positioning) that work across most browsers. There are also a few clever hacks that can give you broad browser support. The only thing you really have to leave behind is the 4.x browsers -- and the page data will still be accessible (sans presentation) if you've done it right. Saying only IE supports CSS is nearly completely wrong.
CSS is in a wierd niche - unneeded for simple pages, and too weak to do what Flash can do. If you really need exciting animated graphical effects (and you usually don't), Flash has far better capabilities.
While CSS can be used to do animation and effects, that's not what it's really about at all. Comparing CSS and Flash is sortof like comparing a power saw and cordless drill.
Most of what CSS is usually used for can be done on the authoring side, with Dreamweaver templates or something similar.
With Dreamweaver? Hardly. Maybe the being able to change the whole appearance of a site at once bit. That's a nice side effect of CSS, but CSS is at core the second half of a semantic/accessible web philosophy. The first half is using XHTML/XML -- make your markup semantic. The second half is making presentation of markup purty and accessible in/across different browsers using styles. With Dreamweaver, semanticity isn't even a concern because it's all about visual manipulation of presentation. Not to mention you'll end up making a different version of each page for different browsers (or embedding conditional scripting) andyway.
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 [downside.com] to do just that for SEC filings, but apart from one obscure client program nobody uses, nobody downloads data that way.
RSS feeds. XML-RPC. I agree that XML isn't used at all as a human readable format, but disagree that means it has failed (or that it was meant for that purpose). XML is a data exchange format for heirarchical data. It's working to exchange data between websites, outside of organizations somewhat, but more inside because most commercial orgs are a little iffy about just giving away their information in an uncontrolled way. We'll see more of inside and outside exchange (though again, more of the former) as web-service enabled applications become more commonplace.
Libertarianism is rich wolves and poor sheep playing gambler's ruin for dinner.
That said, I use Perl and consider myself a programmer, and I deeply shun Visual Basic users, those dirty little scripters. I suppose the bias runs deeper than logic can defeat, after all, everyone has to have an enemy. It's human nature to need someone to look down on.
-Joe
I use C, PHP, and BASH. At first, the managers did not know anything about scripting. Once I showed them how well you can automate labor intensive tasks, they fell in love with it.
Teach your managers when and when not to use scripting. They will see saved $$$ and love you for it. If you can't do that, you're not right for the job (or vice-versa.)
I totally mistook the question for "Do strippers suffer discrimination?"
I know it when I see it.
You keep using that word. I do not think it means what you think it means.
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."
My Apple II+ came with a reference manual that contained all of the firmware's assembly source code (not including AppleSoft BASIC, which was copyrighted by MS).
Apple wanted to ship MacBASIC with the Mac 128K, but MS held a gun to the company's head (kill MacBASIC or no business apps) and Apple complied.
Apple shipped many Macs during the '80s and '90s with HyperCard, a tool that turned tons of people into Mac software developers.
In the mid '90s, Apple shipped every Mac with tools for writing programs in AppleScript, a language that uses the Open Scripting Architecture to allow people to with relatively little pain fully automate OSA-compliant applications.
OS X 10.0 and later shipped with a developer tools CD that contained classic Unix development tools as well as Interface Builder, Project Builder, and everything else necessary to create world-class applications for OS X.
Once upon a time, a very competent software architect I worked with warned me about this evil thing called PERL - a scripting language that was inherently unstructured and unmaintainable, and that tempted the impressionable from the path of good coding with the temptation of instant results.
This input influenced my attitude and aligned nicely with personal exposure to shell scripting back when I actually coded in a meaningful way. I think that much of the negativity at senior levels in some companies relates to memories of the days when a few fools tried to do way too much in the shell.
In reality, dynamic languages like PERL and Python aren't really 'scripting languages' in the sense that the C shell was/is. But they are hard to comprehend if your mindset is "compiled" versus "script". There is a weird beauty to what "my" does that is hard to grok if you come at it from a statically compiled perspective. So it may take some explaining to persuade the skeptical.
At the end of the day, if senior management hears that you have a better approach that isn't going to bite in the long run it will probably be sanctioned.
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'm a "real" developer. Frankly, I have no idea what a "scripter" is.
When I decide which language to use for a problem, I very rarely ask "which language will make this problem the easiest to solve."
I almost always ask "which language will make this solution the easiest to support."
Sometimes I reach into my toolbox and find a "scripting language" to do the job at hand. Sometimes I reach into the toolbox and find a "real languages" to do a job at hand. But, the language chosen is hardly ever a barrier to solving a problem.
I have to wonder what a "scripter" is. Is it someone who doesn't think about "supporting solutions" but instead thinks about "solving problems?" Then certainly there would be a difference between the type of job given to a "developer" versus the type of job given to a "scripter", although I can't see how the difference would be negative.
Or, is a "scripter" someone who's so incompentent that they only know one or two languages, and couldn't be bothered to learn more even if the job at hand demanded it? Then, I can't see what good a scripter is at all. I guess they could have the shit jobs that real programmers don't have the time to do, or something.
Slashdot is jumping the shark. I'm just driving the boat.
as scripting languages require less total code
Tell that to the ravenous VBScript/ASP f*cktards I work with. Jesus Christ, I think these guys have exhausted every possible variable name of all time in their code, in every application they write! The mere mention of instrinsic functions and they get that glassy-eyed stare. And, trying to get these people to write code using VBScript classes (for re-use) is like trying to pull teeth from a Gundark. MIS majors should NOT be allowed to code. (I didn't hire them).
Spread the RC luvin'
I think the elitism arises because scripting languages tend to be so easy to learn. Aside from basic technical intelligence, what really differentiates a good programmer is a lot of experience with the various algorithms, security issues, and obscure interrelations between various components.
The easier a language is to learn, the sooner someone can start writing code, and the more ignorant they likely are to important issues that could affect their program. So the elitism is based in the statistical reality of the relative low quality of scripts out there.
Of course, a programmer who discounts the usefulness of scripting languages or the skill of scripters outright due to that fact is incredibly ignorant and possibly has self-esteem related to others who have done more than just program computers in their past.
I'm learning C++, Perl, and UNIX shell scripting.
For my class projects, I find C++ easy to program in (a little harder now that I'm learning various data structures/ADT's, but still...).
Perl seems to be a very "sensitive" language - meaning I touch the program and it breaks.
Shell scripting is a fucking nightmare! It takes days to do anything whereas all my C++ projects are usually done in one day, two at the most.
My conclusion: it depends on whether the language is a "well-formed" language with consistent syntax and semantics and a decent selection of basic data types and operators and functions. C++ is the most mature and well developed of the languages. Perl has some things I'd like to see C++ get, but otherwise I'm starting not to like it. And UNIX shells are a barnacle-like accretion of twenty-year-old shit...which needs to be totally redesigned (or better, scrapped altogether in favor of more modern scripting languages like Python or even Perl... It's no surprise to me that many sys admins use Perl over shell scripting these days...)
One problem which affects this is the quality of the teaching materials. C++ has a wealth of books and teachers who know the language and can communicate it with some precision.
Perl has a number of books but they aren't deep or precise and rely on "learning by example" which is okay for getting up to speed but useless as a reference when you run into the details of the language that fell between the cracks - like keyboard buffer handling...
Shell scripts apparently depend entirely on "trial and error" learning and until you have at least five years of experience using it, you can't know it well enough to be sure you're using it correctly. And the teachers are all UNIX geeks who think this is the way it should be...
Richard Steven Hack - This sig is TOO GODDAMN SHORT TO DO ANYTHING USEFUL WITH! MORONS!
This goes both ways. I work on a team of SysAdmins and DBA's, and I use shell, perl, C, C++, and even Java for various things. On my team, I'm the only guy who knows C++ and Java, and one of two who knows C. Everyone else gets by with shell and perl (which is fine).
Now, I'm guilty of discriminating against the "script kiddies", but they started it. Some of them believe that perl is the end-all be-all language, and anything else is crap. You should especially hear them moan about Java. So, when they started bagging on me about writing some things in Java, I started bagging on them about trying to do everything in perl. I'm all about using the right tool for the job, but when I'm attacked because I'm not using someone's pet language, I fight back, and I fight dirty.
I've taken to referring to them as "script kiddies" and "knuckle-dragging perl programmers", even though I use perl myself.
As you might guess, I'm real popular around here. But like I said, it goes both ways. And they started it, dammit... =)
-BK
Chemical Blog
I learnt the basics of coding through scripting, and I still use it both at home and in my job. That is, Perl, shell scripting, python etc. However, anyone who understands C can certainly appreciate and love the power of the language in most environments.
;)
IMHO, it depends on what you're developing. For some things... scripting is just a better choice, and often, people are _told_ what to use, it's not a choice.
Yes, coding C probably does require more intelligence then coding PHP, it probably takes double the time to learn and implement for most people as well. Most people who use C out of choice are control freaks
I know I'm not supposed to, but I do anyway. That said, MOST of the time, I'm using it for tabular data anyway, so I don't worry too much about it. CSS works fine for simple things like the proto-typical sidebar + content layout. It's crappy with any sort of complex positioning, though.
Loosers feel discriminated because they are loosers, that's funny :-)
So we write code that people's lives depend upon. Realtime systems have huge safety requirements.
;)
We have taken scripts written in PERL and painstakingly moved them to C for this very reason.
P.S.- getopts() sucks equally in PERL and C!
I just wrote code around it.
In the future, I would want to not be isolated from my friends in the Space Station.
While any scripting language offers advantage over other languages with respect to parsing et al., any Programmer that takes weeks to do something in ANY language when it would only take a few hours in another language is not worth his salt. It's a matter of how well you know the libraries in the language you implement that makes the differece. While something might be quicker and easier in Perl, if it takes you weeks in Java, then the chances are you learned Java from either "Java Programming for Dummies" or the "Java in 14 Days" series.
All your base are belong to us!
java *can* be compiled into assembly language.
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
-Dom
I've found this true to a certain extent where I work. I'm mainly a C++ developer, but in the past have used PHP, Perl, Tcl, and various shell scripting languages. My current company writes server-side software for mid-sized businesses.
A good example was a couple of months ago, when we needed to process a not-quite-XML file into a well-formed XML document. I suggested a Perl script with a very simple regex that would solve the problem. The Powers That Be decided it would be better to have a different developer (who had the time) spend days building and testing a custom C++ reformatter application rather than less than an hour building and testing a Perl script.
To be fair, some are reluctant to ship scripts because not all clients might want to install the scripting interpreter, but some of this is from FUD about scripting being some kind of back-door into the system.
Yes programmers get more prestige... so I became one. Employers provided the opportunity to learn Java, so I did. Nonetheless, although the "programmer" tag gets me in the door for jobs, the additional scripting stuff (Perl, Javascript) often adds real value.
But good code is good code. A good scripter is more valuable than a bad programmer.
What really gets me is how out of the vaunted realms of "programming" has come some godawful bastards like XSL syntax and struts logic tags. They are seriously fucked up.
I don't see how that is the fault of Perl.
How about because Perl allows it?
Yes, other languages allow someone to produce unmaintainable code, but Perl takes this to the nth degree (motto: "there's more than one way to do it"), resulting in each programmer having his/her own style - a style which is going to give anyone else an aneurism.
Other high-level languages enforce some degree of structure on the programmer. Perl seems to allow pretty much anything (how about the ability to do an if-then, but putting the then at the beginning?)
If Perl didn't allow some of it's more brain-dead constructs, maybe it wouldn't have such a bad rap.
As a VB6 programmer, I find that a lot of other programmers look down on what I do. They say that it's not real programming because it's not "object oriented" and it "leaks memory like a sieve".
If you want to talk about language bigotry, start with those nasty nasty Lisp Programmers!
</sarcasm>
In all honesty, a lot of the problem is that scripting languages have a history of resulting in code that isn't well written and therefore isn't maintainable (like VBScript). While this doesn't matter for a lot of us -- we have to adjust to the needs of the business so an archaic code base is as much of a liability as an unreadable one -- it does make it difficult to sell to the program managers... "We could get this project up to date using Python in half the code, bugs and time." "What's it in now?" "VBScript." "Bah, just another scripting language we'd have to support."
It only make sense to solve a problem on as high level as possible while still getting a satisfactory result. Scripting is on a higher level since it uses more of the system at hand. "Ordinary" programming is on a lower level and therefor (most of the time) more efficient but it takes more time to write it. So if you don't need the extra performance; go scripting!
After all, if technology selection was rational, everyone would be using Lisp or Smalltalk.
That is all.
I wrote an entire accounts payable/payroll program which was run by six different organizations for over ten years and accounted for 1/4 billion dollars over that time--in dBase. It had many dozens of tables and thousands of lines of code, but it 'wasn't a real program.'
How about a moderation of -1 pedantic.
Certainly perl is a programming language not a "scripting" language. Maybe at some pointin the far distant past, it was just a scripting language since then it's become a full language (for the LOG -- use strict!!!!!)
;-)
;-)
Then of course there's languages like XSLT, that are considered "doable" for beginners. In fact, a lot of experience shows that beginners have an easier time picking up XSLT than most programmers. Because, as a functional language it takes a totally differnt programming style, one that newbies can pick up pretty easily (XSLT really is pretty simple language) but people flush with the paradigms of procedural programming can go down the garden path and wind up with broken, broken code really easily.
So are people who only program in XSLT programmers? I know a few who feel like they aren't, even though they're perfectly handy with functional programming, because they've never done procedural. IMHO that's BS, they're just as much of a programmer as someone who only does C++. IMHO more since C++ is such junk
simon
PS Use Objective-C
home page
Duh.... you write the parts that have to be fast in code that compiles to assembly. You write the code that binds it all together in scripts. That way you end up with fast little nuggets and reconfigurability!
Aside from the usual compiled vs. interpreted divide, a lot of the differences between programming and scripting languages boils down to strong vs. weak typing. A recent Guido van Rossum (of Python fame) interview was a real eye opener for this primarily programming language coder. For instance:
He goes on to talk about how, as a consequence of this, your scripts are much shorter and easier to read. Of course, one man's flexibility is another man's "coding without a net", but van Rossum makes an important point here that I think gives a huge advantage to scripting languages like Python.
Four fifths of all our troubles in this life would disappear if we would just sit down and keep still. -C. Coolidge
Of course, I have the luxury of working for a small company where we can choose to use what works, not what's dictated by some myopic corporate standard.
But anyone who discriminates against a "scripter" -- (first time I've even heard the term) -- is an idiot. It's pathetic how much time is wasted on handcrafted "real programs" which are 90% wheel reinventions, when a competent programmer could whip together a script in 10% of the time.
Your friend is right. PHP is a STEAMING PILE! It won't last the test of time.
He missed a closing parenthesis in the first sentence.
I believe that in overall this is true, but in my experience it has to do more with configuration management (CM) than with programming. Usually, scripts are used to perform a given task on a system/network without any documentation, and sometimes without anyone but the author knowing about it. I've been in situations were a group of systems is performing a bunch of different tasks using scripts, including modified systems scripts, based on different scripting languages and if you touch one script the whole overall system crashes, and the authors of the scripts were long time gone. I think that if scripters would formally document their code and follow a sort of CM process, things would be completely different. But that's usually not the case!
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 came to the same conclusion with my current project (online database/data editing/analysis system). It's written in 98% Perl with some pieces in C++. Perl+Inline is perfect for this.
We had the following tasks to perform:
- Web interface for upload/editing/etc.
- Store fairly large amounts of data in XML format
- Create analysis in PDF format for download and HTML for viewing
- Create images of analysis for PDFs and web site
We decided the best solution was to use existing, proven tools as much as possible, and glue them together in Perl. MSIE as our 'client app', PS2PDF to create PDF files, gzip to conserve disk space, and a host of other common linux command-line tools for various minor tasks.
The only real problem was image creation. We had very specific requirements, so we wrote custom code for this. However, as Perl lacks adequate memory management, not to mention SPEED, those parts were written as a standalone C++ app. I later learned how to use Perl Inline, so it's now a library of subroutines. Same speed (faster even), and more flexibility.
Programming languages are a toolbox. The situation disctates what is the most appropriate tool for the job:
Need rapid development, and frequent changes? Web interface OK? Need complex data structures native to the language (hashes for example)? Use Perl or some other scripting language.
Massive memory requirements and speed a priority? USe Assembly, C++ or some other compiled language.
Someone already made a tool (or combination) that will work -- write a shell script.
I've built up so much character I have an alter-ego
http://www.faqs.org/faqs/unix-faq/shell/csh-whynot /
Author, Shell Scripting : Expert Re
The "real programing languages" Like Java, C++, and even (cring) are taught in colleges and will be for a long time to come.. Okay maybe not VB. Scripting tends not to be. It is something that talented people tend to pick up on there own.
In a big company you have to think long term. What if perl goes out of style? What if Python sort of goes away over time? Where will I find someone to update this cool but critial script?
My company does use perl for a few utils here. I wrote most of them. I had a person that wanted to do a project in Foxbase. I told him no. He could do it in Java. I can not depend on him being here and I do not want to learn Foxbase.
Scripts are great of one offs and small utilities. I agree that for big projects the standard languages like C++ and Java are the way to go.Each tool has it's use. besides if you are a hot perl programer than you should beable to pick up java or c++ pretty quick.
Where in Hell did many people here learn that the delineation between what is a scripting language and what is not, is whether it is interpreted or not??? I *may* give you that most or all scripting languages are interpreted, but just because a language is interpreted does make it a scripting language. I wouldn't consider Java, Lisp, Basic, Prologue, et. al., scripting languages by any stretch of the imagination! And the fact that these languages now have compilers that generate native code makes no difference.
Anonymous Cowards suck.
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.
When I was in a contest in our Senior Project, we had a fight. And the source of the fight was really that we weren't going anywhere -- we didn't know where to go. A major part of the problem was that our leadership and our development model [that is, how *we* interacted] wasn't right for the task. Anyhow, we went to our prof, and said "We can't work together." So he asked about what brought this out, and we argued in front of him for a while. Then he said "Pick a new leader. I'm sending you back to work together, because the team that fights first usually wins." Anyhow, our leader before had been a free-wheelin car-salesman kindof a guy. I feel good, you feel good, let's all get along and somehow make this come out. So for our next leader, we picked someone who was in the ROTC, and just a little bit of a jerk. It was perfect. We needed a jerk at that moment, and he stepped up to the plate, and we *all* hit a home run. Anyhow, good luck. Don't be discouraged. Maybe after the current round of fights, things will settle down in a *good* direction. And maybe you'll see that, and rejoin, but realize "hey, I'm not cut out for the directorate. I'm happiest on the sidelines." Who knows.
Of course, you can write unmaintainable code in any language; but some scripting languages can make this much easier, which is why they're sometimes a poor choice. Since (IIRC) on average, something like three times as long is spent maintaining code as writing it, bashing something out quickly is often a false economy.
And of course Real Programmers care about the quality of their code. Don't we?!
Ceterum censeo subscriptionem esse delendam.
...we're talking about things like Python, Perl, etc. They are sort-of replacements for "real" programming languages in certain situations.
Scripting is interfacing, tying things together on a higher level. Programming is functionality, algorithms and such
/programs/ without implenting a single algorithm. Take the Cocoa/Objective-C combination. Are you telling me that people write in ObjC to tie together some classes, call some command-line commands and show the results in friendly UI are scripting?
What? No, you're wrong. Scripting is programming with loose typing, non-declared variables, interpreting instead of compiling, and plenty of syntactic sugar to make common tasks easy to type. It has nothing to do with, well, whatever you're talking about.
Lots of good programmers stick to glue code. Heck, if you've got a good API, you can write highly sophisticated
The smartest programmers write as little code themselves as possible because they know it's better to leave that to the specialists. That's laziness -- spend your time researching the APIs you can use, not coding, and you'll get a better impementation because the API owner is far more knowledgeable about the specific problem than you are. Also, that shifts responsibility for updates to someone else and gives youthe benefits of free fixes and updates without doing any coding yourself.
Of course, the laziest programmers are also the most efficient and productive because they're using leverage, instead of doing all the heavy lifting themselves. They're also using languages like perl, that has CPAN, the huge library of easy-to integrate modules. There's a good reason why "laziness" is a part of the perl motto, "laziness, impatience, hubris"
simon
home page
So true. So often I've seen one page perl scripts declined for hundreds of lines of Java. It is insane and wasteful.
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.
CM is used by any professional organization (defined not by whether they get paid or not, but by the standards and ethics in place) but to say that "Usually" in your statement is incorrect from my experience. Actually it is quite the opposite. Good program managers realize that regardless of the specific implements used, the importance of maintaining a good team environment through coordination and communication is what is the key here. I would love to be on a "team" that is not full of incompetent buffoons regardless of the language they abuse.
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).
Well, I dunno about Python, but it's pretty easy to write 3 lines of Perl that can't be decoded even by someone with years of experience in perl, much less someone who doesn't know it at all. You can do the same in C/C++ and many other languages, of course.
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//
And then there's C... Come on... void * anyone? C++ template syntax, unhelpful compile-time errors related to templates, ABI incompatibilities, etc. For every maintainability problem in any scripting language, there's another to be found in a compiled language.
Languages are different, and lend themselves to (un)maintainability in many different ways. There's more to maintainability than type checking and OO. In fact, type checking is so overly rated by "compiled language bigots"; I can't count how many times I've see code passing the right type, but the totally wrong thing, and I can count really high! :) Furthermore, many scripting languages have a so much more elegant OO approach than C++ et al`.
I never said Perl, or even scripting languages in general are fit for every job, quite the contrary.
Just because everyone and their mother started doing scripting when the WWW became popular, writing the most awful code ever, doesn't mean scripting languages are inherently less maintainable than compiled languages.
Sticking feathers up your butt does not make you a chicken - Tyler Durden
Really I think you are hitting on an aspect of a more widespread problem. The closer you work to the machine and the more abstracted you are from the business the more "hard core" you are considered. Business analysts often program, as do system administrators; and in many companies the business analysts spend more time doing it. OTOH which group is considered the best of the best programmers (if in your company business analysts never code replace with the correct title for most user oriented coding)?
"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
I'm guessing anyone who believes this also believes that stored proc's, triggers, and views are all toys. Stay away from my database!
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.
Since I have a large amount of leeway in my own project's implementation, I decide whether a script or C is the right approach to solving a particular problem. It helps that my main project has a TCL interpreter built in and was designed that way from the beginning. Coding is coding no matter what the language is.
Don't drive a nail with a screwdriver.
The company where I work is primarily a Java shop. However, we used a search engine (InktomiSearch) that forced us to code pages in python.
The problem was never deciphering the python code...as you said, that's simple and any developer can do that. Hell...before I learned assembly, I could read it and tell what it was doing. The problem comes when you're forced to write it. When you have no experience writing in a particular language, you write bad code. You also take longer to write that bad code. With us, everytime a developer had to make changes to the python code on our search engine, they not only had to decipher what was already there, they had to learn (or re-learn) python to the point where they can make the necessary changes.
When a Java API became available, we implemented the same thing in Java (2 weeks work) and now it takes far less of our energy to maintain.
I worked at a company so pig-headed once they wouldn't let me write what would've taken me about 2 hours in PERL a simple reorganization and tabulation program. They said PERL is unstable and innapropriate. All of "OUR" code should be compiled and in industrial strength languages.
I was so angry, I called them a bunch of idiot morons, walked to my desk, grabbed my valuables (Picture of wife, r00t mug) and walked out.
"It's not stealing if you don't get caught!"
I recall the shock, horror, and derision heaped on someone we discovered had written a program to do something the system file copy command could do simply, correctly, and faster. This was on VM/CMS in the 1980's and the poor sucker had written in COBOL.
It's precisely the fact that you can use scripting to make some tasks drastically faster that it gets so little respect. For many people you cant get any respect unless you have "paid your dues" and done it the hard way. "Blood sweat and tears"=respect. If a task requires less sacrifice people view it with less respect.
"There's no way to rule innocent men. The only power any government has is the power to crack down on criminals."
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?
I personally believe it would do everyone -- whether you call yourself a programmer, scripter, engineer, etc. -- a lot of good if you learn as many languages as feasible, with as much variety as possible. I recently started looking for a job and when I started the search, I only wanted a job in my area where I would use Java as my primary programming language. Much to my chagrin, every job search I would conduct repeatedly produced no results. Only when I generalized the programming languages in my job searches did I start finding job listings. It was big wake up call for me, because I thought Java was a safe language to become an expert in because everyone was using it and there would plenty of jobs out there if I became disenchanted with my current job. Boy was I wrong.
Companies these days are only interested in a programming language that will get the job done. If they are progressive enough, they won't care which one it is. In an environment where one or two languages are king and all others are treasonous, if you can put up a solid case for your language of choice (and have the time & energy to evangelize it), then do it. Otherwise, get familiar with as many languages as you can and broaden your knowledge base. Because the days of one-language-fits-all (like COBOL or FORTRAN) are gone forever. Money is quickly becoming the deciding factor in choosing languages, and if one language (scripting or programming) can get the job done cheaper and with less effort,, then the bottom line may have more to say about which language you use than anything else.
"What luck for the rulers that men do not think." Adolf Hitler
I worked as a Perl scripter at a E-Book company. One of the projects that company was doing was to tag and cross-reference a foreign language dictionary/encyclopedia with all of the foreign languages that were used. They had a PhD in foreign languages who had been working on that project for 1.5 years. I wrote a Perl script that automated the search functions through a multilingual dictionary and grammar subroutine that allowed her to finish the set in a matter of days (she was only about 1/5 of the way through at that point). I probably saved the company a few hundred thousand dollars in manpower ... all while making under $5 per hour.
I worked for a large lab charged with doing performance testing - testing applications under extremely high load to see if anything broke. A lot of the work we did required code that ran extremely lean and fast, so there was a natural bias towards C and assembler amongst management.
However a lot of code in that environment either doesn't have to be fast, or scripting languages are going to be as fast as compiled languages under some circumstances. I got a lot of push back against using Perl and Python, although luckily I was brought in as a relatively senior "expert" and was able to push back myself.
The issue was finally resolved when I was able to bang together a Perl testing solution to meet an extremely short deadline, and get praise from the customer where we were expecting to get a rap on the knuckles and probably some sort of financial penalty. I was then asked to present to the rest of the group on the advantages of scripting languages vs. C (i.e. speed of development, much less cross-platform issues, low cost of software, freely-downloadable modules from CPAN, and so on), and acquired quite a few converts. A month or so later, Perl books started appearing on peoples' bookshelves and the change had happened. However, it took a near-disaster to get to the point where people were willing to accept that alternatives exist and that (in particular) C isn't the perfect tool for every coding task.
You know it's funny that a lot of these companies that turn their nosees up at Python or Perl endorse VB or PowerBuilder which are essentially scripting languages...
... -exec rm -f {} \;" to the cron ;-)
OTOH I've seen people write a program in Java to locate files > n days old and delete them...First time it had a bug, I deleted it and added "find -ctime
Some scripting languages, like Perl or Python, have gone to greater lengths to provide the necessary tools for building large programs. These usually center around OOP. Inexperienced programmers using those languages may not be familiar with these features or concepts and thus will tend to write less maintainable code. It's not because the features aren't there.
Working with 100+ developers on a project in any language is going to be pretty painful. It's no worse in a good scripting language than it is in Java/C++/C#.
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.
hey, I do c++ for a living and I got a perl developer who does some *really* weird black magic shit with perl. Got the deepest respect for them.
Wasn't sure about php, ASP, et, al. but php is pretty much growing into some kind of perl lite, you can do pretty much whatever you want with it.
all our parsing and natural language intepretation at work is done in perl. we tried a c++ solution and it sucked basically (might have been because the company tried to force the poor perl developers to rewrite it in c++, which they despised before lunch the first day). I would say, use the right tool for the job
if (!signature) { throw std::runtime_error("No sig!"); }
This is basically a procedural vs. modular question. Scripting languages are generally perceived as being great for doing one task but useless for doing multiple ones.
.NET, and script execution classes for .NET. The leader here of course is the web. With the need to change things quickly without the need for instant gratification, suddenly scripts made MORE sense than compiled code.
That is of course bullshit -- Perl, Python and WSH may have messy syntaxes (IMO) for performing OOP operations but they're obviously very good at it, and in some cases can be faster than "high level" languages. But I still prefer to use a more structured, accepted language to code things. Why? The IDE! If you're writing a massive application, it's great to be able to see things graphically. Scripting language IDEs (mostly because of the stigma against them) tend to be "syntax-highlight only."
Part of this is also the "right tool for the right job" mentality. Since scripting languages are used for automating daily tasks, many managers assume they're not up to par for designing larger, more critical systems. Once again, this is bullshit (i'd trust Perl for speed, reliability and fault tolerance over VB 6 any day), but the stigma exists. After all, if you say "I can do that 1 week app in a day," it sounds like you're cutting corners somewhere. Nobody realises the corners you're cutting are mostly syntactical "accounting" overhead.
I think scripting languages are gaining in popularity though. Notice the inclusion of regular expressions in Java 1.4 and
Hey freaks: now you're ju
Scripting is interfacing, tying things together on a higher level. Programming is functionality, algorithms and such.
Have you really thought this through or do you believe that assessment of what programming is?
Coding is either programming or it is slop. In other words, programming has everything to do with how you do it, not why you do it.
Visual Basic, the ease of a scripting language, make binaries to hide your code, and now even does .net if you like.
It may not be a "REAL" language by some peoples definitions, but of course those people don't get to decide - individual developers and companies do.
In *MY* experience. (Note the emphasis on MY! :) I found that there are a lot of people who came from Web Design and are NOT programmers that join the ranks of so called programming after they've learned how to handle a form in perl/cgi. Then they continue on, with no formal knowledge of simple data structures, for example, and tackle bigger projects. It's THESE people that the managers should be scared of. I know I sure am! I've had my share of going through ugly code, and I must say, the worst comes from these types of people. Generally, programmers that program in a more structured language like Java/C have better background/training. It's not to say that there aren't great scripters. There most certainly are, and I love working with these people. The problem I see is the ones with no theory that "pick up" programming working on larger projects!
My $0.02 CDN
AirSpeak - http://itunes.com/apps/AirSpeak
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'
... and get outside a bit more.
Yes of course, if it didn't take a long time and allow our consulting firm to charge more billable hours, what would be the point?
But, when does a project suited for scripting become a project suited for a more powerful language? For instance a database script that pulls data , parses a few things and spits them out...what is the point at which the code becomes so big that a scripting language is no longer suited to the task? What will happen in a business environment is that your code will become more and more bloated with code on top of code to do new revisions...adding calculations for new things, sorting, etc...
What's moreso, how does one go about communicating the need for a change and the difficulty in implimenting it?
I've had that very thing happen to me...
Perl is a kludge language. It may have started out as a decent language, but there was a definate snowball effect as new versions were released.
The result? Scripts that can bring any webserver to its knees.
Let's dispell a myth right now before it spreads. Scripts do not provide a less accurate solution than 'regular' languages.
And secondly, what makes you think a scripter understands the 'nature' of a solution less than a coder? What exactly is the 'nature' of a programming task that wouldn't be given to both a scripter and/or coder as a requirement in the first place?
As a BASIC programmer from way back, I relish the opportunity of someone else being kicked around for not coding in a "real" language :-)
Face it, with modern languages, no one is a "real" coder any more. There are probably sixteen guys in the world that can manually convert their source code into binary executable.
THESE guys are the real coders, since they actually can optimise their code in terms of processor ops.
Err lets see.... I'd use JNDI which does all the work for me. So in Java a LDAP replicator would take....
A couple of minutes (and yes I've written one). Because JNDI makes all that work totally trivial.
No CSV, no intermediate phases. Give me one ldap URL and I'll copy everything over into another.
NB. This proves nothing but the fact that you don't know what you are talking about.
An Eye for an Eye will make the whole world blind - Gandhi
"Reality Master"? You better get your feet back on the ground of 'reality' and stop over-romanticizing the craft of programming. How does the touchy-feeling immeasurable 'nature of the answer' you refer to relate to programming?
only smart thing said
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.
I love how when people hear the word 'discrimination' they automatially think of some sort of unjust predjudices... One of the deffinitions of 'discrimination' is:
The ability or power to see or make fine distinctions; discernment.
You consider "C" strongly typed?
Did you study at the University of Baghdad or something?
C is loosely typed.
...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
These are pussy boy comments.
Back in the days of real programmers, we would have taken you out back and beaten the snot out of you.
But now you pussy boys run rampant and we'd end up beating up 3/4's of our employees.
So your girly-man view eventually will take over.
Sad. Glad I'll be retired before then.
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.
First right off the bat: I'm a Java programmer but also script in a few scripting languages.
Now that that's out of the way...
The problem with scripting large enterprise-class applications has nothing to do with being productive right off the bat, but rather with maintenance in the future. I'm sure many here can remember at least once in their lives glancing over someone else's Perl code, just to see a whole bunch of confusing syntax being used.
Don't get me wrong, there *is* a role for scripting jobs (like for example, for gluing executables in different languages quickly), but I just don't see it at the enterprise level.
Note also that scripters (remember, I am one of them also) also suffer from "script coolness", which translates to "doing the job in the fewest amount of lines of code and keyboard strokes", thus making the code difficult to read for others.
Similarly, in languages like Perl, there's countless ways of doing the same thing, and although in some areas this is good, when it comes for someone else reading your code that can become a nightmare, since maybe ther're used to doing things in a different ways. This is something that is much more restricted in "traditional" languages like C, C++, VB, Java, Delphi, etc (side note, YES, I know the obsfucated C contest, but that's usually the exception).
Note that I'm not saying that *everyone* who scripts does it in a way hard for others to undertand, I'm just saying that it is much more common to see this behavior in scripts than in traditional code (where we also find many cases of obsfucation).
So maybe what we need is a scripting tool that is very simple and fast, as opposed to extremelly powerful and complex. However, by doing so then script writers could probably no longer do a million things in a few lines of code, so maybe this is unlikely to happen (or doom to fail), since it will kill the spirit of scripting languages in the first place.
Botton line: Use object-orientes languages for large, complex apps, and scripts for small and self-contained tasks.
And the spelling...
This often heard argument simply doesn't hold. Perhaps some script that looks like skjhsd ~/skjh /%askf a $$ kjs hf$"$ s
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.
I think that's totally wrong. Get familiar with Perl or Python(or any other similar language) and write something that's semi-complex, and then write it in C. You'll find that your C program is at least 2 - 4 times as large.
Not that I think Scripting languages should be discriinating against. I can relate to comapnies who want to focus on one language, though.
I won't argue with that. Sticking to one language _can_ be a good thing, especially if all the company's developers are familiar with said language.
What it boils down to is needing a good manager to make good decisions.
Sticking feathers up your butt does not make you a chicken - Tyler Durden
If I was starting a company from butt scratch, I would choose a language such as C, C++, or Java for doing application programming. For sys admin type of things I would definitely choose Perl, regardless if every machine was Windows, Linux or whatever.
I have built applications in Perl that are consumed by many to this day. I like it. I know Perl very well and very quickly tap out what I think is very good code. Even so, I am disappointed in the flexibility of these apps. Perl sage say: learn an OO approach in Perl. But once I started to learn Perl OO, I wanted to use something like C++ or Java... something OO by design... something that forced me to think OO, not translate to OO. FTR, I HAVE learned Perl OO. I have jumped to Java. My flirtation with it has become an all out interest. It might take me longer to get rolling with Java on a project, but I have already saved a bunch of time reusing code.
Anyway, if I built apps in Java in my company, I would also design a framework that, if at all possible, would apply to ALL projects. Given that, you have people speaking the same language at design time. You have people using the same style for coding (and you don't even have to make them use the same coding environment or IDE). You have a large number of people to choose from out in the world that would not find it difficult to jump in, feet on the ground, running. You have a product built on concepts that are easy to sell, such as J2EE. And so on.
On the Perl side. I can't imagine why I wouldn't use it for sys admin work. I know of a company that has a scheduler that launches VB, Perl, DOS, Korn, and all varieties of scripts. No surprise, there is no handle AT ALL on messaging. Did it succeed? Did it fail? Why did it fail? Well, good luck answering those questions. Sys admin sage says: standardize message handling in these scripts. No-one wants to mess with a script that works, especially when it's dealing with millions of dollars worth of transactions. Anyone here know who made this Korn script? DOS? *gag* With Perl you can run all of the other stuff anyway. You can hook up to a database to run a stored procedure, check the drive space, move a file from disk to disk, move a file from host to host. And so on.
That's how I break these down in my world. Perl is very important in my world. Java is as well. I have a place for both of them in my ideal company.
-Slo
Strict obedience to the law is the key to liberty.
Are the ones who implement their programs in postscript. There's something about using your printer to do computational problems and render the answers that I have to admit is pretty damn cool. Good for balancing checkbooks. Bad for interactive cad apps though. :)
I'd put my c++ STL code up against any scripting language for execution speed, amount of code, and portability...any day.
Oh and I saw a comment earlier. An hour of computing time IS more valuable than a programmer's hour of coding. A lot of software runs on servers more expensive than your company's net worth!
Nice article. Perl and Python are catching up with the big, compiled languages, especially Python... It's object oriented like C++ and java, but it's much easier to pick up and actually use. With Python, you can get right to programming and forget about the crazy syntax rules in C++ and Java. The only downside to it is that it's interpreted, but that doesn't matter so much now-a-days with 3 Ghz CPUs.
I'd have to agree about the bias. I can cite one case in the company I work for, this is an example of more than just anti-scripting bias.
When I joined the company they had just spent $US100+k on a highlight redundent sun server and another $US25k on a radius server (because "you get what you pay for"). The solution was to put it kindly crap. The server looked like it had been written on a windoze machine and ported to unix. They been taken for a ride by their supplier.
I tried to convince them to switch to another radius server (radiator), but they claimed it was too cheap so it couldn't be any good. Further because it was written in perl it must be slow and a toy, it couldn't be a possible be a serious program. It wasn't until the management of the server was handed over to another dept that the server got replaced with 3 sun t1s running radiator and mysql. Total price approx $uS15k!
I've since written a custom authentication module for one of our projects. Something that would have been impossible with the previous solution.
Get familiar with Perl or Python(or any other similar language) and write something that's semi-complex, and then write it in C. You'll find that your C program is at least 2 - 4 times as large.
I didn't deny that, I only don't think that shorter code doesn't equate better maintainability. I know some Perl, evaluated Python once, but dismissed it for reasons I forgot. Might try it again, it certainly has some appeal.
Do you know what the w3c is? Its a group of control freaks that wanted to be in charge but the industry chose to ignore them. So far it looks like the industry has suppored 0% of their standards even when the standards were based on what the major web browsers were doing. Maybe if w3c adjsuts their standards to the industry they can improve on that 0% a bit. They are irrelevant except for buzword bingo.
I think that's being too generous! :)
note to /. editors, j/k
Sticking feathers up your butt does not make you a chicken - Tyler Durden
the two groups that I've encountered w/ the greatest bias towards scripting are managers w/ a superficial knowledge of programming languages and newbie CS grads ( usually java zealots ). Neither really seems to understand what the distinctions of a scripting language are. Frankly I'd prefer that some of our newbie java guys knew scripting because they're largely useless w/ java.
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.
Just because I can script something in an hour doesn't mean I can provide it to end users as a solution for them.
Most of the development effort in an application has little to do with the required process and data manipulation, but everything to do with user interface to it.
Another thing I have found interesting is the amount of 'glue' that needed in complex and crufty systems alike.
Perhaps your company has an old Cobol or Fortran application that runs to hundreds of thousands of lines of code. Do you rebuild it in GCC? (shameless OSS plug) Or, do you interface it with more modern systems using relatively cheap scripting code?
As you say, this usually comes down to a situation of money and time. If you don't have the money or the time to rebuild it, you will end up creating something that will make it interface with new systems as painlessly as possible - aka 'glue'.
Some especially useful glue:
*Unix shell pipes and output redirection
*Perl and expect.pm - allows you to manage socket connections - and link multiple applications on the same platform or across the network easily (handles all the socket creation/breakdown stuff seamlessly) and automate the handling of normally interactive interfaces via 'expect' 'send' functionality.
*TCL and Expect - see above...expect was originally developed as part of TCL (much as the Tk widget set) - but has evolved to perl as well (not sure if there are any other language implementations atm).
*Any language you can embed into an application (Lisp macros in EMACS for example).
Again, I think the Unix/Linux culture has more of a propensity to embrace this technique as opposed to 'C++' or 'Java' programming cultures.
Another thing I have not seen anyone touch on is the methodology and philosophy of the software lifecycle. I see shops that only work with the waterfall lifecycle - and they have a tendency to produce code that is minimally useful (or not useful at all for real end users) and horrid to maintain (regardless of the ease of maintaining a consistent code base; if the concept itself is all wrong you are going to end up rebuilding it anyway - and through a series of enhancement requests - that takes months or years to implement; what was originally desired!). These shops have a tendency to only do one or two languages (C++ and Java usually) well.
There is a more progressive philosophy that views the project, and its lifecycle as an ever expanding spiral that allows iterative design, code, test, evaluate results and schedule, rinse and repeat. These projects tend to have frequent code releases, multiple mockups, and encompass the real needs of your end user community when all is said and done. Maintenance is a snap because: A) The users get what they need, thus don't put in change/enhancement requests right off the bat, and B) Most maintenance activities center around fixing bugs as opposed to recreating the application. This methodology lends itself to multiple languages and scripting - since the main focus is to get the job done right.
I have witnessed several waterfall projects that extended over 5 or more years and to this day do not fill the needs of the user base (most of which ended up using glue - like embedded macro languages or scripting to fill in the gaps). It seems to me that more than any other, this is a method of ensuring large numbers of mediocre programmers employment over extended periods of time.
On the other hand, I have used iterative design, and have had success upon success, with a minimal cost in time and resources - since I am free to utilize the right tool for each job as needed based upon an solid risk accessment.
Lodragan Draoidh
The more you explain it, the more I don't understand it. - Mark Twain
I place this idea under the GPL. Take it, use it, extend it, or print it out and use it for toilet paper.
I shall use it to wipe my ass :)
Sticking feathers up your butt does not make you a chicken - Tyler Durden
My company is hell bent on using java for web based dB apps. I devel'd a couple prj's in perl in about 4 months, 1 person. These others are multiple people, over a 1.5 years! - same complexity - and still not done. I don't get it. Its just not that hard!.
Anyways the Q is: what happens to Java when Sun bites the dust. I predict the death of Java within 3 years.
http://saveie6.com/
As always, use the wrong tool, get a cruddy result.
On the other hand, if you go around calling yourself a "scripter" instead of a "programmer" you get what you diserve.
I am a programmer. I program in many different languages. Some better than others. If someone gives me a task I do a quick analysis and pick the right language. If there is someone better suited to the task or language, I pawn the problem off on them.
If someone *only* knows how to script I do consider them lower on the programming food chain. The typical "scripter" doesn't necessarily understand the cost of their solutions. A (properly trained/talented) programmer usually does. (If he doesn't he isn't properly trained.)
(If your only language is Visual Basic, you need not apply, you are "a dragger and a dropper". 8-)
On the other hand there are many reasons that a job that could be done in perl in a few hours might be better given to a C++ developer for a few days. For example, if I am sending this code out into the wild where I know nosy system admins or web weasels might edit the code but then call me for support, they are getting a bound executable, period.
Similarly, I will not give to a perl "scripter" a program that I know can be written in three lines of bash because they *WILL* write it in perl no matter what.
"To a man with only a hammer, every problem looks like a nail." -- know the aphorisim, live the aphorisim, be the aphorisim...
Innocent people shouldn't be forced to pay for inferior software development.
--"Code Complete" Microsoft Press
A good programmer is language-neutral. He knows more than just one grammar; he knows how to program. He has a big bag of tools that includes a lot of languages, including scripting systems. And tries to use the best tool for the job.
When someone gets religious about any one system, and believes that their one way is the solution to all of life's problems, then he loses value to the business and to himself.
I have not seen anyone touch on the methodology and philosophy of the software lifecycle as a determining factor in this so-called 'scripting bias':
I see shops that only work with the waterfall lifecycle - and they have a tendency to produce code that is minimally useful, particularly if their discovery techniques with key users is inadequate. While lip service is given to 'maintainable code', it is usually horrid to maintain, regardless of the ease of maintaining a consistent code base - particularly since the design itself is flawed. Rebuilding a flawed design is not maintenance. Corrections can take months or years as each request undergoes the scrutiny of the revision control process (a truely draconian process in some organizations). These shops have a tendency to only do one or two languages (C++ and Java usually) well.
There is a more progressive philosophy that views the project, and its lifecycle as an ever expanding spiral that allows iterative design, code, test, evaluate results and schedule, rinse and repeat. These projects tend to have frequent code releases, multiple mockups, and encompass the real needs of the end user community, when all is said and done. Maintenance is a snap because: A) The users get what they need, thus don't put in change/enhancement requests right off the bat, and B) Most maintenance activities center around fixing bugs as opposed to recreating the application. This methodology lends itself to multiple languages and scripting - since the main focus is to get the job done right.
~~
I have witnessed several waterfall projects that extended over 5 or more years and to this day do not fill the needs of the user base (most of which ended up using glue - like embedded macro languages or scripting to fill in the gaps). It seems to me that more than any other, this is a method of ensuring large numbers of mediocre programmers employment over extended periods of time.
On the other hand, I have used iterative design, and have had success upon success, with a minimal cost in time and resources - since I am free to utilize the right tool for each job as needed based upon an solid risk accessment. I think this methodology is rarely used in most established 'code factories'.
This also manifests itself in how we think of our end user communities. Just as the BOFH complains about stupid 'Lusers', I think there is a lack of respect for the people who have to actually live with the products we produce. This is getting the cart before the horse, for without the users there would be no need for programmers or 'scripters' for that matter.
Of course, I could be completely off base, biased by my limited view of the world. Right.
Lodragan Draoidh
The more you explain it, the more I don't understand it. - Mark Twain
Insane compile times are largely a C++ issue. Since each class is a separate compiled file in java, you don't have to worry about recompiling the whole thing, unlike C++. And you don't need to link at all. I honestly don't understand how people can deal with that insane compile/link cycles in large C++ programs.
autopr0n is like, down and stuff.
Seriously, they don't. Some scripting is easy as hell, while some things can be a bitch to implement. I've done scripts that would've been better as actual compiled code, and code that would've been better as a simple tcl script. Unfortunately, management gets what they want. If some manager says that he wants X done with a script, he gets X with a script. Even if it would be easier, better and faster to do it with code. And the same for coding. If one of the users says that he wants a program to do some simple function, my manager makes us write a program to do that function. Even if all it is is a fucking file copy from one server to another.
I'd say that usually the difference is in which OS you're writing for.
.ini file. Moving beyond it requires installing extra programming tools, be it Perl or Python or c++ or whatever. Also, scripted programs under Windows are treated like second-class citizens by the OS. You don't get the equivalent of "#!/python" under Windows, you have to execute scripts by executing the interpreter and giving it the name of your script on the command line. Anything but native executables wind up looking cheesy because of this.
/dev directory), and hard-to-do access to configuration data (hooray for the registry).
Under Windows, the scripting language of choice is the cmd.exe language, whatever that is. It allows about as much expression as a
Under most other OS's (especially UNIX-like ones), you have real choice right out of the box. You can choose the best language for the job based on its merits and nothing else. With so many languages available, you rarely have install extra packages to get the work done, and even more rarely to allow a client to use your software. And since a script file appears the exact same as a native executable file (unless you look at it in a text editor), you can write serious software in any scripting language you choose and not have to worry about that cheesy look.
Also, under Windows there is a much higher chance that you'll run into something you just can't do with a scripting language, because of such things as hard-to-do access to devices (no
There are other problems under Windows too. So, if your target platform is Windows, by the time you add up all the little barriers, it almost never makes good sense to use a scripting language.
You're an idiot who doesn't know anything about modern web design. CSS is about formatting pages of information, now showing pretty pictures and graphics like flash. You can do some of what you can do with CSS with table layout (the only alternative) but it's stupid.
Netscape 4's CSS is fucked up, but people using Netscape 4 should stop. The browser should not be supported.
autopr0n is like, down and stuff.
"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 haven't seen much bias in favor of C over scripts.
However, I have often seen insistence on either buying prepackaged commercial solutions, or doing all the work by hand. Sometimes they standardize on prepackaged commercial solutions that don't have a text interface, forcing everything else to be done manually.
What they would think of the fact that I do tons of automation with AppleScript!
My thoughts on the subject, "scripting languages" are languages that tend to have all the rapid development features and code reuse that c++/java programmers have been talking about for years.
I most definately see the bias personally, but there are some major points not to be missed.
the term script is highly overloaded, however most people consider a script something that branches often and has top to bottom flow. They also tend to be heavily on application specific logic, and have poor error management features. ( the scripts not the language )
Algorithm use useally falls into the generic catagory.
Something with specific logic tends to break horribly with a new or revised problem. Taking the time to build a better structure is often a good idea, however the assumption is that it is a language problem.
In real life what is a script and what is a program is beyond grey.
The myth that "only scripting languages produce scripts" is in error. Perl/python and other major languages can produce a script, as well as a full blown application. The bias has always been towards natively compiled languages, due to the false sense of removing dependency.
If java has done anything well, it has helped break the homogeny of compiled binary programs.
http://www.perl.com/pub/a/2001/10/17/etoys.html
home page
Say it Loud "I script and I'm Proud!"
A good coder would have seperated the markup phase of the page generation code from the rest, so it could be easily upgraded, or simply changed.
autopr0n is like, down and stuff.
...Use the right tool for the job. Amen.
"By the time most small orgs double in size, I'm sure PC hardware would have doubled in power or more, and they would need to replace aging hardware anyway. They probably won't even need to upgrade for the first few doublings"
in short:
Sure its slow, but the hardware will cover that up.
The Kruger Dunning explains most post on
There is no link to Gator on that page. There is no drive-by Gator install on that page. Perhaps you'd like to fuck off and bury yourself.
Pick your favorite version of perl. Instead of calling it perl, call it my_favorite_perl_version_that_will_live_forever. Instead of programming in perl, program in my_favorite_perl_version_that_will_live_forever, so that you don't have to worry about the langauge changing.
:).
Honestly, managing a 5 year old version of Python code is likely a lot less painful than maintaining a 5 year old piece of C++ code. If they are performing similiar tasks, I'd bet the Python code is much shorter (factor of 5 is within reason). I'd say the same about the maintainability of perl... except that I've seen perl code
Furthermore, while langauges that have one main implementation (perl, python, etc) change frequently, they rarely drop backwards compatibility, so it's likely the old code can run on a new interpretter. In the worst case, bringing it up to date won't be excessively painful.
What would take weeks to cod that script could do in hours?
I do very small (and silly) Perl scripts to break up the day. I can't imagine that any of the log reading, HTML producing, things I do have a week long equivalent in C, C+, Java.
But I could be very wrong.
Anyone?
This
You realize, right, that 'start' can open URLs with the system default browser automatically?
autopr0n is like, down and stuff.
I've got about equivalent amounts of Java and Perl under my belt, but I use Perl literally 20-30 times more often. I haven't experienced any anti-scripting bias, what I've experienced more is people who only know "programming" languages asking me for help with scripting chunks of their research.
I should mention that what I do is pretty much bioinformatics.
only real or fake programmers.
d ability)
;)
almost every complaint come down to these things:
1)speed
2)re-use
3)maintainability(rea
1 is a real issue that needs to be properly evaluted.
2,3 are a result of poor programming techniques.
*except latin, clearly that is a fake program created by some smart ass 3000 years ago.
The Kruger Dunning explains most post on
ok, i'll weigh in:
;-P
scripters rool because "Go away or I will replace you with a very small shell script" sounds kewler than "Go away or I will replace you with a heavy memory intensive java applet"
it's all about meta baby... and scripters are more meta than coders... disagree? what KIND OF website are you reading right now? hint: rhymes with beta.
meta is all about the next level. in every aspect of life. scripting the building blocks is a level above building the blocks. reading the meta site is a step above browsing the websites. life is more peaceful in the airplane at 20,000 feet than it is in the office tower at 2,000 feet. drinking the beer is better than drinking the water and eating the barley and snorting the yeast... er... you get my drift.
intellectual property law is philosophically incoherent. it is your moral duty to ignore it or sabotage it
Can anyone point me to some links discussing the difference between scripting vs programming in layman's terms. This is not a troll; I really don't know the difference (the last computer class I had was in HS in the late 80's).
> Flame away...
;->
OK
You seem to be equating "scripters" with self-taught d00ds who've created a few interactive Web pages and consider themselves experts, and "programmers" with college-trained wizards that can be turned loose on any project and relied upon to deliver.
Good coding practices are essential for any reasonably complex programming task, regardless of the language being used. In my experience, it's usually easier to get people to conform to multi-developer, project-specific rules using (say) Python rather than (say) C++, and I suspect the reason is that Python OO coding is more intuitive and less open to quirks of individual creativity than C++. On the other hand, I've seen some truly laughable Perl OO code, that defies any sort of analysis without the original coder being present; Perl seems to attract people who want to find new ways to solve old problems, and sometimes that's not what the project requires... The trick is to find coders who solve problems in a reasonably concise, auditable and consistent manner, and who are actually capable of adhering to a set of rules. The old term "software engineer" is key; people who approach coding with an engineering mindset tend to delivery higher quality results more consistently than those who approach coding as a creative outlet.
In my experience, the best programmers are those who are able to select the right tool for the job. In general, they won't use C++ for GUI design when VB is an option; they won't use Perl for high-speed numeric analysis. Well they might, but only if the decision is taken out of their hands.
Since we are both a couple of flamebait trolls and nobody is watching, we can now discuss it reasonably.
/.'er that has an enthusiam for linux, to higher standards - that is why I went off. I was (am) very disappointed.
Actually I was eager to see what the guy had done in PHP, particularly interested as his chosen inplementation was of Trade Wars - a game I played for fun while I was in college. I was looking forward to reliving my youth, as it were.
I hit the front page, read the discussion about his changing the economy variables, read some of the faq and when I went back to the main page Gator tried to install on me.
I hold a guy with a background in Trade Wars, particularly a
Glonoinha the MebiByte Slayer
I work for IBM, I took a month to get an app ready for alpha test. it was tested on a non-conforming production enviroment. It took another week to code the adjustments for such environments, but the new code was never tested, instead IBM assigned the task to C++ programmers
After three months, even with being able to impose strict conforming rules, it did not work.
I eventually spen another week and wrote the data-gathering routine, and then the machine modification code in order to get it to work at a 90% level (My original was 99%) with the requirement that a special code book be pulished to all users and network admins to be able to locate paticular machines.
oh, enjoyed your journal by the way. i must say I do believe in copyright law, I do not believe in record companies as a middle hand though.
When ti comes to software, I'm bit more unsure. I do believe in the OS model. I do not however belive it might be the right path for every single software company out there. Mind you, I do not see it as an xor kind of thing, I do think they can co exist quite nicely next to each other.
if (!signature) { throw std::runtime_error("No sig!"); }
The more junior the staffer the more supervision they need. You didn't have time to learn Python & Ruby? (nether do I btw) - you should have at least had the time to watch over and guide him/her.
Scripts are good for fixing quick problems. They are also good for developing a suite of often used commands. the problem is when they get into the hands of those that could not write them from scratch.
I have seen too many scripts adapted from an origional that are of such bad quality, I would dearly love to rewrite them all. Bad the person who wrote them is an entrenched senior guy who is revered by upper management.
The fact that they see him as a demi-god and he is a scripter means that scripts are OK, but it also means that his scripts are OK.
This guy breaks every rule in the book. Magic numbers, hard coded machine names, everything.
I am writing this after spending 3 hours supporting real-time gas pipeline operatirs because his shit failed. Again.
Scripts in the hands of non-morons are OK.
--- I hate my sig
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.
Um, yeah. I spilt bong water *all over* this page here in K&R, and well ya know I had to parse and FTP some text files for a highschool assignment, and well my dad bought me a Mac and I couldn't get Borland Turbo C 3.5 to install, and I started hiding under the couch.
I was sitting there for an hour and then it hit me! I could write a shell script, and um then I had another bong, and I'm not sure where the files went...
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
Everyone is protecting their own quarters.
A *real* programmer/developer doesn't think about what tools he/she *should* be using but investigates and acknowledges the problems and choose the right tool for the job, whatever it might be.
Adaptation and evolution. That's how we conquer not so well formed problems, not by the language we speak or use.
A carpenter would never use a drill to cut a plank, he can see the problem and picks the right tool for the job. And that's something many so called developers/designers can't (or won't) do.
Building an application is far from building a real building since you can't patch it. Why don't we learn from that side of the business?
Parent appears to confuse languages with development environments. Languages in general are free. I could write in C, C++, Python, Perl, PHP, etc without paying a cent (for compiler, interpreter, or whatever). What most companies are paying for is a development environment which (supposedly) makes writing and maintaining code easier (usually by integrating many nice features and optimizations). There are both free and proprietary development environments for every language I can think of (from Ada to VHDL) including scripting languages.
I would agree that there seem to be fewer development environments for scripting languages, and they are generally of lower quality than the ones for more respected languages.
"The plural of anecdote is not data." It sounds like you've dealt with a handful of faux-hotshot developers who worked primarily with scripts, who left you in a mess. You haven't seen enormous unmanageable VB programs? And factory-fresh talent (as opposed to home-grown) has never turned out line upon line of spaghetti C? Here's the counter-argument: I've worked with people who've produced tens of thousands of lines of PHP and perl that interact with multiple outside vendor systems, multiple various hardware add-ons, presenting a relatively bug-free interface to their users and admins. Some of them were trained in CS, some of them weren't. The difference? These people were good, unlike the people you've had contact with. Good "programmers" exist too - look at the FreeBSD codebase. I'm surprised you didn't post a moronic "Mod me down for my original thoughts" tagline.
One of the problems that you run into in any sort of language decision is that all sorts of people have religion -- you have the OO/C++ types who think everything should be written in C++, others that think Perl is the perfect language for everything, some who don't think that anything should be scripted in csh, java-bigots and so on.
I've discovered that I need to have a variety of tools in my toolbox. To use the old analogy, if the only tool you know how to use is a hammer, everything looks like a nail.
There are certainly projects that should naturally be written in C++, some in Tcl and some in assembler. If you have experience in all of them, then you have the standing to pick the best approach for a given project with the confidence that you know what you're doing and aren't just being 'religious' about it.
I should note that this idea is true for more than just programming languages -- I've used it with networking technologies, programming environments, editors and documentation systems. You don't need to be an expert in everything -- you just need to know enough.
I believe Moore's Law made the current explosion in scripting languages possible, by lowering the bar for scripting language implementors.
Take the original scripting language, Lisp. I'm serious - Lisp programs are safe (no naked pointers, no buffer overflows), variables are untyped, development is interactive, the first implementations were purely interpreted. Making a Lisp system perform acceptably was beyond all but a few wizards, who had to invent many of the tricks routinely used to speed up interpreters today.
Today's desktops are roughly a million times faster than the dinosaurs of the early 60's that Lisp was born on, and a thousand times faster than the Lisp machines of the early 80's that Common Lisp matured on. Today, naieve implementations of interpreted languages have acceptable performance on modern hardware, especially when handling web transactions where network latency gives you more time to compute.
To a Lisp hacker, XML is S-expressions in drag.
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...
//Assuming that by 'check' you mean check to see
//if the link works, and the text file is one URL
//per line, the following code should work:
import java.io.*;
import java.net.*;
public class LinkCheck{
public static void main(String args[]){
BufferedReader br;
string url;
try{
br = new BufferedReader(new FileInputStream(args[1]);
}
catch(Exception e){
System.out.println("File error, check to make sure file ");
System.out.println("exists, and that you named it on the"
System.out.println(" command line");
}
do{
try{
url = br.readLine();
URL u = new URL(URL);
System.out.println("OK: " + url);
}
catch(Exception e){}
}while(url != null);
}}
//This is just off the top of my head, of
//course. But it only took me 5 minutes. If you
//could give me a more precise definition, I
//could probably still come up with something
//quickly.
autopr0n is like, down and stuff.
So much for that theory.
Will Pythoners suddenly jump from being "scripters" to "programmers", or are those priviliges reserved for the people that were brutalized by their Pascal/C/C++ education and think that freeing your own memory is some kind of sick initiation ritual?
Or how about Erlang? Or any other language that includes abstractions beyond classes (look mah! we're object-oriented! we don't have multiple inheritance or a real type system!).
As has been pointed out in other posts, the whole field of IT is more fickle than the fashion industry when it comes to choosing technologies, and particularly anything related to development. Sure, use Java because your boss said it's popular and everyone knows it and Sun says so etc. And when you come bitching on Slashdot about how your project can always find Java developers in the future, remember that you're part of the problem. Of course you're not going to find any programmers in language X when you're not offering jobs in language X.
Apologies for the rant.
In the great CONS chain of life, you can either be the CAR or be in the CDR.
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
Dude! It's not your choice of scripting language that relegates you to the tiny cubical in the corner. It's your hygiene!
A Government Is a Body of People, Usually Notably Ungoverned
Scripts are usually written in a few hours/days. Java/C++ development efforts often take months. Yes, they may do exactly the same thing, and have comprable complexity, but a person who makes the job seem difficult (or more precicely: seems to be doing a difficult job) gets the admiration of managment, etc.
If you can do something in 2 hours (using Perl), then you're just goofind off and not really putting your effort into development (like C/C++ programmers do).
Hah!
Actually, this would happen less and less if people were smart enough to pick the best language for the job. There are programs best written in Perl, there are those best to be written in assembly (microcontroller code?), and those best written in C/C++, PHP, etc. It all depends on the job, not the language.
"If anything can go wrong, it will." - Murphy
decss is pages long in c, but only 2 or 3 lines long in perl.
Here's an example (real-world): Company running Net.Commerce wanted to write a fancy 'configurator'. Java was all the rage then (still is), so it was proclaimed that the configurator be written in Java, in spite of the fact that: We had many experienced Net.Data, and Net.Commerce (C++ based). NC has some nice utilities which make it easy to setup a commerce site, but also has basic utilities for retrieving data. But no, they wrote it in Java. Instead of using Net.Data (since they didn't have experienced Java prog), and even instead of using JSPs, the Java code *built the pages* in Java! Yeah, it looked like page one of the Java servlet tutorial from 8 years ago. Now how easy is that to read and debug? Furthermore, database connectivity was so badly handled, so that the system could handle about 1 user at most without locking up. (Their solution was to synchronize the servlet! yowee!) Granted, with experience Java programmers, with good tools (open source database pooling utilities or WebSphere etc), and knowledge of how JSPs, XMLC, XSL, work they could've done a better job, perhaps better than NC. But for just getting the work done and out the door, and the users happy, Net.Commerce would've fit the fill fine. Most of the time was spent in design - the design was great, the followthrough (the actual app) sucked That was a lesson for all.
If you need to support Netscape 4 in an elegant manner (ie it has to look good), and you're never going to have more than one person working it that's a half-decent scripter: use tables with templates.
I work for an accounting association and all the accounting offices in our province still running nescape 4 need to be able to access the website to download documents, etc. And, yes, there are apparently large accounting offices that still use netscape 4.
My office has a budget for one webperson. They get far more out of a full-time programmer than a full-time graphic artist, so they hired somebody that can program and hire out any graphics requirements. The graphic artist gives the graphics to me, and I create a template out of it using tables and php or python (we're very slowly moving from PHP to zope+python). (Besides, I noticed that good designers get a little carried with image file size. They need need somebody to tap them on the shoulder and explain to them that nobody' going to sit around to wait for that animated chair to download!)
This way I only have ONE version of the website to keep up to date.
While I'm at it, I've got to add that I absolutely and completely despise javascript. It is completely and utterly broken if you need to support netscape 4, netscape 6, IE 5, IE 6, and I guess, now netscape 7. I have absolutely no time for it. I only use it for simple mouse overs -- hey cool the arrow changes colour when your run your mouse over it!
We run a number of online courses that require flash, so most local offices will have flash installed. If I need to program something that can't be done server side, I use flash. I can create one version that runs in all the browsers I need to make it run in. Flash can be annoying, but it definitely has its uses! Rita.
Actually, what disturbs me more than the potential bias against 'scripters' is the acceptance of a situation where the supposed 'programmer' faction are comfortable not knowing at least one 'scripting' language. Even if you're not using a 'scripting' language such as Perl for production code, it still comes in mighty handy for anciliary tasks while programming in your 'production' language. The typical 'production' language boils down, at some point, to plain text, and there will be situations where using the 'scripting' language to generate or manipulate code in your primary language will eliminate a lot of tedious and repetitious coding.
For example, in a situation where Clarion was the 'production' language, I found myself needing to read a file downloaded from an IBM mainframe. The file had variable-size records (not directly supported by Clarion), with no record-size bytes preceding the records, and the only machine-readable layout for the records was a COBOL copy-file. String fields needed to be converted from EBCDIC to ASCII, except that in some cases the REDEFINES verb was used to re-map parts of the record - in those cases, you can't just automatically do the conversion. COMP fields (16-byte integers) also needed to be byte-swapped. The record layout was large enough that I could have spent a couple or three weeks converting the COBOL layout to a Clarion layout by hand, and writing the code to do the EBCDIC/ASCII and byte-swap conversions. Instead I wrote a series of 3 Perl scripts that parsed the COBOL copy-file, produced the equivalent Clarion layout, wrote the conversion code for those fields which should always be converted, and documented those which might need to be conditionally converted. The result was a Clarion template, so that the code could be easily incorporated into the Clarion development environment.
Not only was this more efficient than hand-coding, it made dealing with the eventual changing of the format by the vendor much easier, as all that was necessary was to run the updated COBOL copy file through the Perl scripts to produce a new template. If I had done the layout by hand, dealing with an updated layout would have required wading through the COBOL copy files looking for changes, and then made the corresponding changes in the Clarion code, a much more tedious and error-prone activity.
It's not just a question of using the right tools for the right jobs, it's also a question of having your people know enough different tools to be able to recognize when something other than the primary tool is needed.
I note that Bruce Eckel (a book author and trainer for Java and C++) is suggesting that Java programmers also know Python, for much the same reasons.
Python hard to write? Give me a fucking break.
I fuck up memory all the time. Woohoo, I'm a programmer! :)
This topic was pretty much already covered a few weeks ago at0 2/10/2032221&tid=156
http://developers.slashdot.org/article.pl?sid=03/
Table-ized A.I.
I encountered this as well with one client. My code had been reused, and repurposed and abused into a sprawling mess.. Be direct.
Like cars, code gets old and crufty and must be renovated (or thrown out and rewritten). The client won't go for it the first time around, but they now know it must be done eventually and can plan for it.
You can have it good, fast, or cheap. Pick any two.
the c++ guys pee on the C guys who pee on the perl/python/java guys who pee on the shell script guys who pee on the javascript/php web guys, etc.
bottom line, everyone wants to code the 'big problems' and everyone else wants someone else to code the annoying ones. if you want to sit in the front of the bus learn c/c++. its simply not that hard. my experience is that you can learn C/c++ faster than learning perl/python really well.
With C++, compliance with the language spec is still imperfect at the compiler level. Library compliance is even worse. Look at the horrors of GNU "autoconf".
Java still has the "write once, compile everywhere" problem. The libraries continue to churn. I wrote in Java for a while, but got so fed up with Sun's bug factory that I gave it up. (I also own three different defunct Java IDEs, which is a bit discouraging.)
With Perl, I'm able to debug the program on a Windows machine and upload it to a Linux server, and it usually works the first time.
I'm writing as someone who's developing real-time code in C++ on QNX. I'm not a big Perl fan, but it's available on commercial web hosting systems and it works well there. If you have to get some work done on a shared server, Perl is a reasonable way to do it.
The language situation today is surprisingly bad. Java had great promise, but was botched. C++ has too much legacy. Perl's object system is a painful hack. Delphi is too closely tied to Borland. Visual Basic is too closely tied to Microsoft. The other languages don't have enough market share. It's frustrating. It's also the cause of much bad code. Our languages really aren't very good.
In your long post you mention "The typical 'production' language boils down, at some point, to plain text, and there will be situations where using the 'scripting' language to generate or manipulate code in your primary language will eliminate a lot of tedious and repetitious coding." while it might sound like a good idea, I ask you one question. Why are you coding repetitious code. You should understand ways to reuse the code to produce the same effect with fewer lines of code and no repetition. Not only repeating the same pattern use more code which will slow down your program, it also makes it harder to debug. More Code is bad, and using a scripting language to create more code sounds like shooting yourself in the foot.
mnewberg.com
Java is buzzword compliant, C++ is somewhat buzzword compliant, VB and .NET are very buzzword compliant. Pay attention to what magazines the office pukes read, and learn to program the languages that are hot according to the business media. Never mind that old saw about using the right tool for the job... this is a new millenium, and symbolism rules over substance.
Exactly.
Style sheets can do to HTML what macros do to PostScript. Real PostScript documents tend to consist of an enormous block of canned macros followed by the actual content. For most short documents, the macros are bigger than the content. Most of the same arguments can be made to defend style sheets as are made to defend PostScript macros. And most of the same troubles appear. Adobe Acrobat is basically a workaround for the problems of PostScript. It grinds the original, "abstract" code down to a low-level representation for delivery. Style sheets aren't that messed up yet, but give them time.
But, like anything, that's an engineering tradeoff. By exposing so much of the implementation and having no fixed, defined standard, things can shift under the programmer from release to release. High performance implementations are nearly impossible to create. And issues like scoping may end up being more convenient but less reliable (Python scoping is something no serious language designer would choose to put into a language, for example).
So, by all means, use scripting languages. But don't expect that code to survive in the long term: 10-20 years from now, the interpreter that executed that code will be gone, and nobody will be able to determine exactly anymore what it actually meant.
A "real language" is a language with a clear, well-thought-out definition that doesn't change every few years and that does not excessively expose implementation details. And while "real languages" are almost universally less convenient to program in than scripting languages, there are reason why people put up with the hassles.
Most of these types of "programmers" are the leftovers from the mid 90's when companies were hiring anybody as programmers. In my experience, they don't have the aptitude to actually design a software system using a software development paradigm. So, the company stuck them in a specialized group that did only scripting with one type of scripting language (e.g.: Javascript).
If you want to get ahead in your company, make sure you know a compiled language as well as a scripting language. They complement each other when trying to get a project done on time.
"Happily lived Mankind in the peaceful Valley of Ignorance." -- Hendrik Willem Van Loon
I can't believe that even the defenders of Java are missing this point.
Java *is* compiled. You don't run the bytecode anymore (except in a very few very small implementations).
Most compiled languages (like C) are compiled once by the programmer, then the resulting binary is executed many times. In the case of Java today, the source is compiled to bytecode by the programmer, but then the bytecode is compiled to binary -- not each time it's run, but just the first time it's run on a given machine. After that first, slow run, it is essentially the same binary as if it had been compiled to binary by the programmer, but with some advantages of being optimized for the specific runtime.
It's also true that modules that aren't called don't get compiled until the first time they are called, but then they're cached and they don't get recompiled.
Java is so fast these days because it has abandoned the "execute the bytecode" ways of its early days. These days, it just does a late compilation to native.
And for benchmarks like the QuickSort mentioned in this thread, you can't measure it reasonably by doing one run, you have to run the same algorithm several times, then measure one iteration to judge the speed.
In other words, when running Java servlets serving customer after customer, the first run is really slow because that's when it compiles, but then you get another 100,000 runs of the same object code with no recompilation, and to judge the speed you should look at one of those 100,000 and not just the startup run.
"Those who have never entered upon scientific pursuits know not a tithe of the poetry by which they are surrounded."
He's giving away our secrets! Hurry, we don't want it to spread any further!
I believe "scripting" originated as a way to automate the functions of an app. Instead of manually calling the functions, you could write a little script and have the program save it and run it for you on demand.
So for this reason, it tended to be higher-level, specialized, and slow compared to a "real program" but faster than manually entering the commands.
Some scripting languages, such as the pseudo shell scripting language that Perl started out as, called lots of outside utilities, then gradually internalized them, then added libraries of its own, then spread across platforms and, as far as I'm concerned, just morphed into general-purpose programming languages.
For the most part, though, I would stick with defining scripting as high-level automation of features that are implemented in a lower-level language and programming as using a lower level language to create new things, and *yes* I can see that it's a spectrum.
"Those who have never entered upon scientific pursuits know not a tithe of the poetry by which they are surrounded."
If those 30 developers can't decipher all of 10 lines of python (or any language) it's time to get some new developers.
I'm sure I could whip out 10 lines of Perl that would make any C/C++/Java-only programmer's head spin. Hell... I bet I could implement a flight simulator in 10 lines of Perl.
NO CARRIER
My experience is that, as I get older, is that my code has gone from near perfect to so bug-ridden that I'm amazed it ever works.
Have I gone senile? Or just gotten sloppy?
Or is it that I've learned to use assertions and strict compiler checks and the like for any program that I won't immediately delete once I have run it once? (I've seen too many "quickie" programs live for a decade or longer.)
The third possibility is that my code today is a lot more intelligent than the first few years I wrote code. E.g., a few years ago I would never transparently compress my data, but now I use zlib several times a year. But I may only be comfortable writing this type of code after developing those other skills.
For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
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.
Up until a couple of years ago Perl had a great reputation as a scripting language. In the mid-to-late 90's it even enjoyed a status as a "hot" language, and Perl programmers were quite sought after. And then, perhaps coinciding with Python's surge to popularity (and definately spurred on by Java programmers who also stand a lot to gain by being disparaging towards Perl) the lies you try to pass off as gospel truth started becoming trendy. Perl became a kicking boy, completely unjustifyably.
Now, to address the bullshit claims in your post:
Lie #1 - Perl is "cryptic"
This single statement shows that you just don't know Perl. Any language can look "cryptic" if you aren't familiar with it's syntax. But if you are competent in the language it is clear as day (unles it's programmed by an awful coder, who no language will help anyway)
Furthermore Perl, Java, C++, Python, JavaScript, ASP, Visual Basic, and Delphi, to name just some of the most popular languages, are all similar enough in syntax that they're not very hard to decypher if you know any one of the others, and especially if you have a reference book in front of you. So even if you don't know the language you can easily get the "gist" of what is happening. And if you do know the language, you have no excuse for not understanding it (unless the program you're reading is written by an incompetant programmer).
A related lie I hear is "Perl looks like line noise". What people are likely referring to are regular expressions, which are used all throughout UNIX, not just in Perl but in vi, sed, awk, etc. If you are using UNIX at all you would do well to learn and live regular expressions, because they are super useful and very powerful. Until you learn them shut up about them looking like line noise, because that makes you look as ignorant and bigoted as someone who curses foreign languages for not sounding like English.
Lie #2 - Perl has a steep learning curve
If you already know shell scripting and UNIX utilities you're more than halfway there with Perl. Therefore a UNIX administrator's learning curve is _halved_ if he choses to learn Perl over virtually any other language. Not surprisingly, the first niche that Perl carved out was in easing system administration tasks. System administrators loved it and used it on _production_systems_ (see Lie #3), because it was the perfect tool for the job. Since then Perl has aquired one of the most complete library collections of any existing programming language. Therefore you don't even need to learn a lot of the lower-level stuff with Perl, as chances are whatever you need to do with it has already been written for you, you just plug in a module and off you go. Easy.
Lie #3 - Perl is not suited for use on production systems
Try saying that with a straight face to any of a million system administrators who are the ones maintaing your production systems. They are the ones who keep your system stable and running, and more often than not they chose Perl to keep it that way. Apart from system administration tasks, Perl is also well suited to application programming, especially when text processing (say HTML, ie. any web application) is involved. I could go on and on about Perl's veteran status for production quality applications, but don't take my word for it, look at CPAN http://www.cpan.org/
Lie #4 - Perl doesn't encourage "good software engineering practices"
If you mean Perl is flexible and you can program any way you want, then it's true. However, this is only a problem for very junior programmers or people who shouldn't be programming in the first place. For them you can try to make a virtue of inflexibly sticking by "the one right way" to program. But professional, veteran programmers will want the flexibility to do it their way, and Perl will allow them to do it. And, as veteran programmers, their choice should be respected instead of trying to force them in to whatever new programming fad is in fashion this week as "the one right way" to program.
In conclusion, Perl is a great language. It's fun to learn, fun to program in, and can hold it's own against any other language out there. But, like all languages, it is just one tool out of many, and can't won't be perfect for every job. If you recognize it's strengths and weaknesses you will be much better off than if you blindly believe the ridiculous insults that are being slung at it by jealous lovers of competing languages. Because that's where these insults really have their origin, not from any kind of objective evaluation of the facts.
If it doesn't have multiple inheritence, it can kiss my ass.
I used to do 8086 assembler, and now do Java, so now Java bytecode assembler is interesting!
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, it is true, and I hope it stays that way.
There's nothing more satisfying than shoving my Python down the throat of an obtuse, lumbering behemoth of a competitor that's too narrow-minded to consider using an unconventional language in an imaginative way. In fact, I get off on it.
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.
perhaps the term is an oxymoron. from my (admittedly limited) experience, `executive-level' folks don't have much interest or even experience in getting the job done (and no - visions and sales promises don't run on servers, as much as we'd like to hope; code, as flawed as it often is, does)
take javascript - it's more powerful (as a `core' language) than java (it lets you write code at runtime). now go look for job openings which require js. how many LISP openings out there?
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.
This is SOOOO TRUE!
I watched a "C++ Guy" give another C++ programmer a project to do which would take him 2 weeks to flesh out, and would only take a day to do in perl since I had done similar projects before.
And I wonder why that company is gone now.
Its a shame that program managers dont think "gee, whats going to be faster to code and get the product to our customer faster?" instead of "C++ or nothing".
Its the reason I bailed from the company before it went under.
If you really "don't want to get in to a flamewar" I suggest you keep your mouth shut on controversial subjects, instead of passing off your oppinion as fact.
/. deserves the epithet of "flamebait" it is yours.
If any post on
There are a large set of problem domains that are inappropriate for scripting and interpreted languages. For instance, you don't find ring-0 code written in scripts, nor many compilers. Such tasks are often many orders of magnitude more complex than the tasks for which scripts are best suited, which perhaps contributes to the bias.
.bat language = scripting language. Perl = interpreter.
That said, it seems that there is some fuzzyness between the categories. What's a scripting language, and what's an interpreter? The lines blur, since scripts tend to be interpreted. I tend to think of scripting as simply glueing little bits of externally supplied functionality together, while interpreters are more suited for creating real software with real algorithms and real data structures. E.g:
Just MHO.
Scripts always depend heavily on the environment where they are running in; for instance first you usually have to install an interpreter.
;-)
Scripts run as a glueing tool to connect some components togather - they are also great as a tool to creat job security (that's why sysadmins love them
Leave out the scripter - and the whole thing is likely to stop functioning once a small little thingy changes in the environment.
Of course you have similar problems with executable code; but here you are trained from the start to abstract those location specific details away.
And that's the whole difference.
Scripts should be used for prototyping and if the prototype doesn't do the trick, then the original programmer who wrote the script can convert the program to the language of choice.
If you don't know about python, it's time to check it out.
They're both unemployed!
I work for a large consultancy, the sort that I thought would be infected with this kind of bias, but discovered that pragmatism is very much valued. I was head techie supporting a large application that someone else had written in C, and when we had to fix a bug, I came to the conclusion that recompiling it was probably quite hazardous (we had loads of source code, but couldn't be entirely confident that we had the right code, or that we were using the right compiler options) so I wrote a 20-line Perl script that would run after the main batch processing program, and would fix the mistakes that it made. It was accepted, and implemented. Quick, reliable, and it didn't risk breaking anything.
After much wasted time, I have decided that exactly 97% of you are 12 year olds taking an introductory BASIC course.
Shut Up
-- Ed Avis ed@membled.com
If you compiled a program using gcc 3.0 and deployed it, chances are it's still working now.
If you wrote a script for PHP 4.0 and deployed it, and someone upgrades the PHP runtime to 4.3, chances are it's buggered.
I realise that second thing probably applies to Java VMs too, but I hate Java, so that's cool.
I am an experience shell scripter [9 years, experienced as in they are not pretty but they work], I am also an experienced C programmer and more recently a java programmer [5 years]. I have written up some short notes on sed and shell coding [Shell_Boot_Camp] (and examples) .
...
Is there an equivalent small reservoir of java programs that do much the same thing, ie a bit of regex, find and pipeing? Whenever I have a small problem to solve that can be scripted I can never be bothered to gear up a java program 'from scratch' so I never build up a small set of java programs to do the job.
I feel I thrash so much between techniques, I should stick to java where possible, as this is the closest to one size fits all.
Hey I work in migration so the same goes from moving, or switching back and forth, between different languages, so equivalent hello regexp, find and pipe in shell (csh,bash,ksh),c, perl, msdos batch files, java, python would make a good entry in a migrationdotcom site.
This is currently a very small hint at what a database migration community site might look at, but is so light on implementation it could go any where, but most likely nowhere
Be Free: Free Software Tuition
... it's about the problem and the solution you want or need.
For instance:
Just now I'm working on a software agent that automates information retrieval and update via the web. It's a long row of subsequent tasks that have do be followed by the book in a very procedural manner. Meaning I would call the resulting Software a 'script' more than an actuall 'programm'.
Now if some time later we move on to build a more general information agent 'engine' I'll do it in 'serious' OOP, separating the regex-runner, scancycler and whatnot in different classes. Easy done with the very same language as I'm using Python (yep, here Perl goes byebye...).
Until then I just need a working system and anything more than JIT compiled Python in scriptstyle - as opposed to precompiled/frozen post-Python binary - would be a hideous bloat. Same if I would be using Java for just that.
Bottom Line:
To me anyone who, for whatever reasons, draws a line between 'scripters' and 'programmers' is a silly goof that really doesn't know what he's talking about.
Oh, and btw.: OOP is also about working with a team. The extra OOP bloat is easyly outrun by the teamworks productivity gain. If the programm is overseable and done by one alone it could look very much more like a script and be just as good.
We suffer more in our imagination than in reality. - Seneca
if you feel that the man is keeping you down because you only do scripting, get off your obese ass and learn programming.
jesus people, it's not rocket science.
I don't mean to be religious, but there are two aspects of at least one of the scripting languages that bother me, and caused me to abandon it. It was either Perl or Python (or both), but it was long ago. Tell me if this applies to your language:
1) If you write a variable name in a script, it automatically becomes a valid variable. This is a problem because, being human, one can make a typo in using that variable's name somewhere else throughout the code. Unfortunately, that variable is entirely valid, albeit initialized to zero. With compiled languages, you can catch such common mistakes.
2) Lack of strong function prototyping, ie, you can call a function with a varying number of arguments, without having an explicit coded idea of the number of arguments it expects. For example (using C style syntax)
void My_Function( )
{
}
could be called with 0 to 100 arguments; anybody who didn't write the program would have no idea how many parameters are required. I think this was a Perl problem, but I think the interface between Python modules also has this problem.
Feel free to correct me if I'm wrong. Maybe those languages have changed since the last time I looked.
Hell... I bet I could implement a flight simulator in 10 lines of Perl.
Go on. I dare you.
Scripting is an artificial distinction. Both scripted and compiled languages are turing-complete.
In the companies I have worked for, there is definately a rivalry between the 'scripting language' group and the 'low-level language' group. The former calling the latter dinosaurs, and the latter saying 'yeah whatever, we get paid more than you do'. In reality this competition is a good thing and makes each group think seriously about what they can gain from each other. The former group get to learn the concept of "version control" and the latter can copy the libraries to improve their productivity. Personally I would pair one of each together in a team!
In my opinion, a good programmer can eg name three different sort algorithms, not name {insert low level language here} as his favourite language. A good programmer will also be able to go in and bug fix a language he has never seen before, given a basic guide to the syntax and decent comments in the code.
Phillip.
Property for sale in Nice, France
Sounds terrible, but "out the door" is completely different than IT. For in house development, the greater cost is maintenance. In IT, rarely do you get to throw the product over the wall. Even as a contractor to multiple companies, I get called back to work on things that I haven't seen for 6 years.
6 year old C code is easier to read than 6 year old perl.
There is no cure for bad programmers (not the person, the whole package of technical skills, communication, and tools) and I would argue that a bad programmer is worse than no programmer.
Joe
Joe Batt Solid Design
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 mean, bullshit.
The CS degree gives you the tools of the trade. The "drive" or "values" (whatever that SUBJECTIVE things are) are a personal trit that nothing has to do with a fscking professional education.
Although you need to be a self learner the basics given by formal education are invaluable. A good scripter normally can't manage to work under the constratints of a big programming porjects. Real programmers can because that is part of the learned trad (serious programmers know about project management, time constrains, working in teams, formal software specification, etc).
IANAL but write like a drunk one.
Just because a body of code is huge and written in C/C++/Java/.NET does not mean that the code is any good. Bad, and more particularly indifferent, programmers write awful code in whatever language they use. (Bad programmers have trouble writing code that recognizably belongs to any particular programming language!) Doesn't matter if the language is a scripting language, a systems language or machine code toggled in on the front panel.
OTOH, the pointyness of the boss's hair does seem to be inversely proportional to the quality of the code...
"Little does he know, but there is no 'I' in 'Idiot'!"
Send us your Linux Sysadmin articles.
Geeky modern art T-shirts
...it's what you do with it.
It strikes me that a "script" is a list of things to do in order (such as a theatrical script), with a high level of abstraction.
A program on the other hand is more low-level. It is concerned with data structures and flow control and is generally harder work to write and interpret.
It is quite possible to write script in C (hello-world is a good example - it does everything in order, and what it does do it calls from elsewhere). Likewise, in most languages it is possible to write a complex program. Of course, C is much better adapted to "programming", and, say shell is better adapted to "scripting", but this does not mean that they could not do the same job as each other.
Therefore I conclude:
- The distinction between "programming" and "scripting" is not discrete, but continuous.
- For a job at a particular point on the scale, almost any language could be used, but some languages will be better than others.
TJ
Owl tried to think of something wise to say, but couldn't.
My boss is always asking me to writ Perl scripts. Unfortunately, I'm the janitor.
Perl isn't a script language... it *can* be a script language, but it isn't defined as one. You can go native if you wish.
From a generic point of view, programming is simply writing instructions for a computer to carry out. These instructions usually have to be compiled into programs that can then be run.
Scripting is writing instructions that are compiled on-the-fly, or on a use-by-use case. They might be a few milliseconds slower, but accomplish the same task.
Tasks that are "do this and terminate" are better off left done by scripts. Tasks that are needed again and again by other objects are better left to already-compiled programs.
Sorry - I use a couple of different ad companies right now... and that can sometimes happen...
It's not me directly...
BlackNova Traders
I've seen the code most of y'all programmer types turn out!
Seriously, though, a few years ago I took my "senior design" course in college. I'd never used java before, but the other two competent people on my team had, and what the heck, it's just a programming language, right? So we decided to do it in Java, using Swing for our GUI.
Java, to me, feels more like scripting than programming-- it felt like everything anyone would ever want to do was in a library, and all I had to do was write some glue, just as if I was writing some ksh to glue together sed or awk. I really began to wonder whether there was truly any difference between "programming" and "scripting" anymore.
Of course, I then went home and put in some work on the game I was writing for the Intellivision, and that's completely different-- but there aren't many bits-and-registers programmers anymore. Modern programming, for the vast majority of us, is really not so different from scripting.
-JDF
The article should be moderated as Flamebait.
It's promoting victimhood and marginalise competence. It is miss-using the word 'discrimination' to presume a negative connotation and automatically associates a negative moral imperative to it. Discrimination is the process where a determination between states is made. There is nothing inherently imoral or wrong with discrimination providing it is based on objective criteria.
Yep programmers do generally look down on scripters and managers too and yep this is discrimination, however to assume this is wrong as the article suggests is to fall for crude double think.
What differentiates programmers from scripters is not the language used but the scope of the languages available for use. If you can develop software independent of language then you are by definition a programmer and also by definition more skilled that a scripter who can only develop software in scripts. Programmers are by definition more widely skilled that scripters.
AIH I consider myself a software engineer, because I am competent in wide range of skill I can system engineer, analyse, design in multiple paridigms, I can program in half a dozen languages from multiple paridigms. Oh and yes I can script. I can also construct a cost benefit analysis to see which is the best approach to utilise, a quick a dirty script that will be used once or a well designed and engineered system that is robust and flexible.
Quite honestly, I hold a couple of copyrights, so I theoretically have an interest in those rights being protected. Even if, as is the case, those interests are mosly academic, since the actual properties don't have any proven value.
It's been nice meeting you. I hope I'll see you around. A pointer to a pointer to a pointer, indeed.
IP is just rude.
Is there any torture so subl
Seems like corporate decision makers are so wrapped up in a finite number of choices that often scripting languages are completely overlooked. Something like a "Java" is a safer choice because people have heard of it, vs.--say--PHP.
Because I started as a Web hack guy, all I know is scripting languages like PERL and PHP. And JavaScript. Ah, JavaScript, my old friend. I was sitting and listening to managers talk about the feasibility of customizing a links menu on a Web site. Emails flew back and forth, and consultants theorized that a java applet coupled with the user database blah blah blah. (Not at all feasible at this particular stage.)
I couldn't take it any more. "I'll do that in JavaScript," I claimed. And I did. Took me like an hour, coding from scratch.
"I didn't know you could DO that in JavaScript," my boss said. "I looked all OVER the internet and couldn't find anything like that. How did you do that?"
"Well, I know how to *program* in JavaScript." Cutting and pasting, of course, is how we LEARN, but writing from scratch is how we deliver the right solution based on the given problem.
Not enough decision makers even consider scripting programs. PERL: Some kind of old-fashioned Unix code used on old-fashioned web sites. PHP: Some kind of wacky open-source fetish. JavaScript: Crap that you cut and paste from Websites, or that mysteriously gets generated by FrontPage. If it doesn't take 8 weeks to program, it couldn't possibly do the job.
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)
Here's what I consider stupid about all this. If you write something that is stateful and capable of Turing decision, you just wrote a program. You programmed; SGML is not programming, it's markup. However, shell, C, Ruby, Perl, FORTRAN, MIPS assembly... what have you. It's all programming. You write a coherent path from A to B that allows for some varied input to calculate. Decisions are made based on the state that is carried; so where's this bias coming from?
I am a C programmer by nature; I love inline asm like no other, even if it kills portability. I'm fortunate enough to be comfortable in x86 and SPARC assembly, so I can reasonably roll out different versions of my projects if needed. However, the first language I ever picked up was Perl, and I'll be damned if anyone can part me from the power that the regex system in that language carries. It makes a lot of low-priority, mass-storage parsing a hell of a lot easier than coding it up into a fully-compiled language.
Now, that said, I do think that this comes down to using the right tool for the right job. I'd be a fool to think that I could write some of the heavily-traversed data-access software we use (since we're currently running some bargain-basement DBMS, there's quite a bit of in-house work to interface) in an interpreted language. We'd never be able to get all the day-end reports printed before midnight (and the office closes at 5; we burn trees like no other). Nevertheless, sometimes I'll knock out my algorithm in Perl to lay out the concept before attacking it in C; that saves me a lot of algorithm checking when I'm debugging. Hell, it probably saves me 3 days' debug time by punching up the algorithm in Perl in one day.
The beauty of computing is that there is no one "right" way of solving a problem. Deadlines, urgency, process priority, systems load... These are the things that determine which angle to approach "How do I code X?", and anyone who thinks otherwise is pretty foolish and closed-minded.
Never attribute to Hanlon that which can be adequately attributed to Heinlein.
True story once again;
somewhere down in the past, the department next to us was the internal programming team. basicly they did everything in VB.
Now at a sudden time, i'm writing this gigantic bourne shell script while one of the VB coders next to us comes over to ask me some stupied question. anyway, he looks at my screen and sees my script and says - wow, you know C ?
just goes to show the world is full of clueless coders...
On a long enough timeline, the survival rate for everyone drops to zero.
But I believe that stron typing does make for more stable, maintainable code. Here's why:
If I write a function in a strongly-typed language (I'm thinking in Java here), I can nail down exactly what I'm getting. All my assumptions about parameter types is made explicit to other programmers, and checked by the compiler.
On the other hand, if I'm using a weakly-typed, or untyped language, my assumptions cannot be checked by the compiler. (There are languages that get around this, but I'm taking the simplified case for now.) All the assumptions I'm making about the types of arguments I'm going to get are implicit in the code. If I'm calling that function, I need to know about its implementation in order to determine what kind of thingy it will work on. Likewise, if I want to change the implementation of the function, I need to know not only about the kind thingy it was meant to work on, but all the other types of thingies that are actually getting passed to it.
There are languages that get around this, with implicit typing, etc. But the bottom line seems to be that some kind of typechecking is simply too powerful a tool to give up in favor of letting programmers be a little lazier. In other words: Yes, Lazy is Good, but cover your ass at all times.
Computers are really good at remembering things and checking the consistency of large systems. These are exactly the things that humans are bad at. Strong typing just seems like a smart division of labor.
That code you showed was probably the WORST example VB code I have seen. I agree that it was crap code - but not because it was done in VB, but because it was crap - heck, it wasn't even a valid implementation of a bubble sort (it doesn't terminate when no swaps are done, and it "waterfalls" or something with the "i" loop variable that slows it down by iterating through progressively larger and larger sets). Furthermore, the variable are declared (default) as type Variant, rather than a faster Long or Integer type (depending on how many items are in the array). I can almost forgive the array for being of a Variant type, but it given that he was sorting directory contents, probably should have been String. Gsize being a long, but having to be typecast to a Variant for the "i" For-Next. Plus, two loops? Should be doable with only one. Damn, all I can say is that is crap VB code. Had he just made those improvements, it would have ran marginally faster.
Yeah, a Quicksort would have been better - any competant VB coder already has a Quicksort function available in their toolset, or knows where to find a C version to translate from. If raw speed is all you want, Quicksort is the way to go. But you also need to know when to balance speed of execution with speed of coding - unless you already have a VB Quicksort function available, it might take a bit to cobble one up and verify it works properly. Depending on the task, a form of sort not a lot of people know about - better and as easy to implement as a bubble sort, and faster - but slower than a Quicksort - in fact, it only takes a couple more instructions to add into a proper bubble sort to get it working - it is called the "comb" sort.
For most directory content listing sorts, it would work fine (yeah, there are cases where there are a bajillion entries to sort through - this sort isn't for it, but it handles way more entries than a bubble sort in less time - it actually isn't too bad, and is as easy to implement as a bubble sort). Also, depending on the number of entries (for example, if you knew you were always sorting 10-50 items), a Quicksort would be overkill to implement, especially if the project needed to be done yesterday, whereas a bubble sort would be fine for the task, at least until you got a breather to implement something better.
Yeah, the code was crap - not the language (ok, I concede that VB isn't the be-all-end-all of programming languages - but you got to admit that it holds its own - and there are a TON of applications out there written using it, albeit for Windows only, sadly). Personally, I think that if there was an open-source implementation of a VB-like language (ie, a RAD language, with the BASIC-like syntax, but drop the GOTO verb, dammit!), for *nix, you would see the general application market on *nix explode (and by applications, I mean "real-world" apps businesses use, not necessarily desktop or games stuff).
Like it or not, VB is *the* thing that has really made Windows for Microsoft, acting as both a simple to use application development platform, and a glue language/scripting platform that was simple to understand. Unfortunately, that is also its weakness, in that it allows just about anyone to be a "programmer" and create crap code like your co-worker...
Reason is the Path to God - Anon
Yes, and we know the reason why VB was introduced was to give Jolt a market to sell their caffeine-free products to.
Sorry, couldn't resist.
Jan Theodore Galkowski, (Oo) http://www.smalltalkidiom.net/ MySQL,PHP,ETL,SQL,MinGW C, and plucking the Web
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));
Slashcode actually uses the template toolkit. Presentation is separated from logic in the same fashion ColdFusion pages are separated from data.
I shit you not go download the Embedded Visual Tools which has VC++ 3.0 and VB 3.0. I thought I'd do a simple project for the local school (notice my name) and it would be a quick few bucks. What's happened is the scope is all f'd up (I'm covered on this because I submit detail design docs to cover my rear) because the specs keep floating. The other problem is eVB is a PIECE OF SHIT. Say for example you're connecting to a local cdb (access file format for wince/pocketpc). You can Select data, you can delete data, hell you can even insert data. So you'd think you can fucking UPDATE data, oh wait, that's not implemented. I guess if you decide you want to use the Left() function/method/whatever you'd better be ready to create your own because it is a Known Bug that will never be fixed (not to mention the 100's of other f'd up things I've encountered).
I really wish I would have just done the project in Embedded VC++. It would have taken an extra few hours initially but tracking down the nonimplemented "features" that should be available in eVB has been a nightmare.
BTW I develop for Solaris (Java), Linux (Java, C/C++), Windows (Everything a client could desire), Mac OS 9, Mac OS X, PocketPC, WinCE and even maintain some POS old DOS code. I don't really hate VB as a lot of people do here on slashdot but it is really only good for quick & dirty internel apps. I would never (again) develop a commerical app in VB.
If I could have one wish for a development tool this would be it:
Java + MFC (not MFC but like MFC instead of JFC) + VM OR Native Compiled Code + Completely ANSI Standardized and OSS.
If my company(s) take off I may devote a few developers to building a cross platform toolkit that meets my needs (choke*pipe-dream*choke).
Relatively objective points:
* Script interpreters or just-in-time compilers are so diverse and
non-standard that situations often arise where you can't count on having a
given extension or function. With C/C++ you have things like libc or MFC.
They are totally ubiquitous and even though there are different versions
you can depend on things like ANSI/POSIX/C99 standards. Those type of
standards are woefully lacking in most script languages.
* Most companies creating a commercial product would bawk if the end result
of their time and money resulted in script(s) that anyone could pop the
hood on. Obviously this only applies to script languages that can't be
compiled (like Java with gcj) or rolled into some byte code (like
PHP/Zend).
* Most companies have standards and don't want to spread development efforts
across a large number of languages. So, they pick a few languages and
stick with them.
* Some tasks are absolutely unsuited for script. Writing optimized device
drivers comes to mind. You might be able to do it in script, but if
someone laughs at you for suggesting it, I wouldn't exactly call their
hazing baseless.
Just my anecdotal experience:
* I've seen bad ASM/C/C++ and I've seen bad scripting. Bad script takes the
cake when it comes to the "most deserving a clown college scholarship".
* Many (most?) people writing code in script languages are inexperienced
programmers and it shows in their work and end result.
* People who are pure scripters rarely use version control.
* Scripting is easy to learn and takes much less mental discipline than C
for example. I'm not saying that makes C a better language, but I am
saying that it creates a situation where the first rung on the ladder is a
bit higher and thus the programmers who learned C/C++ are more likely to
be brighter folks. This also fuels the perception by non-programmers that
people who write scripts are not as smart/good as those who write "real"
code. Here in the real world, their prejudice/heuristic often turns out to
be justified but not always by their own reasoning.
* Expanding on the last point, I personally write some things in script and
some things in C or ASM. I consider myself to be a better judge of the
"right tool" than someone who can only write script. More experience leads
to making better choices.
* When I'm searching at Freshmeat and I see items that are coded with
scripting languages I usually pass them by. Why? Because experience has
taught me that they are usually low quality and half the time getting them
to even run on anything less than the author's configuration is more
trouble than it's worth.
* Java zealots make some decent arguments about why Java is good as a
language. They also say often "if you still think Java implementations
suck then you haven't seen the better ones as of late". But I have seen
them. They are better, but they still suck. Slow GUI performance, slow
load times, and resource hogging are still a problem. Just less of a
problem.
* "But wait you can compile Java with gcj!" Yeah, and have you tried it? Many
Java extensions don't work with gcj, and what's more the code isn't
optimized very well (slower performance across the board with the tests I
performed like FFT and Huffman code). Binaries produced by gcj are about
3x to 4x larger than the same thing done in C++ or C. However, the fact
that you can compile Java at all is a big step in the right direction IMO.
* Perl code is 'terse' by design. However, in my opinion it makes for some
very ugly and unreadable code. It also creates problems for people trying
to maintain code they didn't author. You could write ugly code in any
language, Perl just makes it easier.
* Try writing a raytracer, 3D modeler, device driver, MMORPG, office suite,
or network stack in a scripting language. I'm not saying it can't be done,
but do you think the results of such an undertaking will compare with the
same thing done in C/C++ you are in for a surprise.
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++.
Try Scheme. It has all the dynamic flexibility of the best scripting languages, and the abstraction capabilities of the most high level academic languages, but can be compiled to very fast code. On benchmarks, some of the compiled Schemes are up there with languages like C.
My next that I kept for a couple of years was C++ programming for a large client/server program that would have been easier and better as a web application. I was one of the best if not the best C++ programmers they had but soon I quit because I didn't like working for them.
With 'full blown programming' credentials on my resume, I got a job programming web/cgi pages in perl - a scripting language. The company was a small linux/perl shop. I learned more about programming there in a month than I learned the entire time I was a C++ programmer. Perl is full of nifty things that make 'real programmers' happy like regular expressions ( HA! finally that class in finite automata/grammars/turing church et al is USEFUL for something. Glad too because the math geek in me loved that class ) Perl is imperative or functional as you desire ( kewl! learning scheme was useful ). It is tied well to unix. Though I had used only AIX for my entire term of employment after college I was actually a unix newbie. It's been said that if unix is War and Piece, then perl is the cliffnotes - so true. That is the place where I really cut my teeth as a programmer - using perl a 'scripting language'.
Only idiots see this with prejudice. Because it is possible to write quick and dirty perl 'scripts' to do small tasks doesn't mean it isn't possible to write large software with it as well. Those convenient tricks that perl provides are a strength not a weakness. You can follow all the rules of large scale OO project design or you can write a one time use only data migration script. It's a swiss army knife with all the tools you could want built in or in modules but unlike a swiss army knife which becomes bulky and cumbersome when more features are added perl has a very 'ergonomic' grip that is easy and comfortable to use.
Scheme used to be my favorite language then Java, then C++ but now I like Perl best of all. It's almost everything one could want in a programming language.
Eat at Joe's.
Since the beginning of time, those with screwdrivers have screwed everything, and those with hammers have hammered everything. The new part? Those with hammers and and screwdrivers are told by their bosses that hammers are easier to maintain, so please use a hammer to knock the screws in. Nobody wants to train someone to turn their wrist when everybody already knows how to swing their arms.
Very popular slashdot journal for adul