Do Scripters Suffer Discrimination? 1216
TheTheologian writes "In his InfoWorld column, Chad Dickerson says 'there is a level of quiet discomfort between the "scripting" versus "programming" factions in some corporate development environments in which I have participated. In some instances, executive-level technology management has held scripting languages in disdain as not being "real" languages for day-to-day problem solving, which has discouraged highly talented scripters on staff from practicing their craft. In such an environment, scripters are relegated to the lower ranks ... ' He goes on to say that some companies will assign Java and C++ programmers tasks that take them weeks but could be done by Perl or Python programmers in a few hours. Is it true that some companies are so overcome with code bias they'd assign weeks of unnecessary work rather than give it to the scripting untouchables?"
Yes (Score:5, Insightful)
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.
On the contrary - (Score:5, Insightful)
IT's called a standard (Score:5, Insightful)
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
Mountains and molehills.. (Score:5, Insightful)
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.
vs programing? (Score:3, Insightful)
tools (Score:2, Insightful)
Scripting vs Programming (Score:3, Insightful)
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?"
Use BOTH! (Score:5, Insightful)
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.
Hardware is so fast and cheap... (Score:3, Insightful)
Re:Script kiddies should be fired (Score:1, Insightful)
A rose by any other name (Score:5, Insightful)
Certainly (Score:5, Insightful)
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.
Scripting Languages are Superior (Score:1, Insightful)
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.
PSST (Score:2, Insightful)
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.
It's about stability (Score:5, Insightful)
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.
Re:Wrong Person, Not Language (Score:5, Insightful)
Oh please! (Score:2, Insightful)
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.
True, (Score:5, Insightful)
Re:Wrong Person, Not Language (Score:4, Insightful)
Re:Wrong Person, Not Language (Score:5, Insightful)
On the other hand I've worked in companies that could grok any language. We even made them up when we needed to.
Joe
I guess I am biased against scripters as well... (Score:5, Insightful)
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...
scripting not the problem (Score:2, Insightful)
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.
You better believe it (Score:2, Insightful)
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.
Legitimate concern (Score:5, Insightful)
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.
Re:my belief (Score:5, Insightful)
It's all about the gory details (Score:3, Insightful)
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.
"Scripter" (Score:2, Insightful)
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."
Re:Mountains and molehills.. (Score:5, Insightful)
I've worked places where the developers use whatever language they want. Guess what? Every time one of the developers leaves, their stuff gets rewritten since no one else likes their choice of language. That's not good business.
The title of idiot manager should not be placed on anyone that wants to reduce the choices of the developers. Instead, it should be placed on managers that don't recognize that at least more than one language will be needed and force everyone into C++. Unfortunatly, it seems that if management makes a decision that limits the "freedom" of the developers, they are labeled idiots irregardless if their decision makes sense business-wise.
There really is a difference (Score:5, Insightful)
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".
Re:On the contrary - (Score:5, Insightful)
I beg to differ. Consider a program script that sits on a web server and does something reasonably complicated for each person that hits the server.
Now consider that said program runs
Now consider that the website gets 100,000 hits a week. Thats almost 14 hours a week wasted. So we're up to almost 60 hours a month. How much time did you save using perl instead of C?
Re:Oh please! (Score:5, Insightful)
Any such distinction between them is better explained along the software programmer versus system admin dimension (programmers do more programming, admins more scripting).
That's the misunderstanding that leads to problems. Scripting is programming and scripting languages can be used for software programming. I mean are you going to say that the task of building slashdot is "system administration" not "programming"?
scripting "cowboys" (Score:5, Insightful)
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...
Re:On the contrary - (Score:2, Insightful)
Sheesh.
Re:Script kiddies should be fired (Score:3, Insightful)
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.
Oh Hell Yes!!!! (Score:4, Insightful)
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:
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!
The Question is Discriminatory (Score:5, Insightful)
Many (not all) programmers will analyze the problem, design a solution, perhaps have their design checked, implement it, and run some tests. This is based on education, experience, and the requirements for programming, but they will do this EVEN WHEN SCRIPTING.
Many (not all) scripters who aren't programmers will simply start writing the code. Lots of iterations. No formal design. Very quick to first test, but not nearly as likely to be the right solution the first time.
The typical result is that the same problem, solved by a script, will often work better and solve the problem completely sooner coming from a programmer than from a scripting non-programmer.
Typically I would expect management to be asking only scripters with exceptional track records at the same time as they ask the programmers. Because management isn't interested in which tool was used to solve the problem, or even in minimizing cost of solving the problem. Management is interested in solving it once and having the solution work. If that means using a developer who implements overkill at double the initial cost, but with much lower ongoing support and revisiting costs, that's fine.
Re:On the contrary - (Score:5, Insightful)
The best (Score:3, Insightful)
But regardless of what solution you choose, document. Even one-liners.
Re:PSST (Score:5, Insightful)
C is not a scripting language, because the end result, after compiling and linking, is an executable that can be run by the OS w/o a separate runtime (I'm including linked-in runtimes, such as the old dbase runtime kit, as 'separate', b/c the end result still goes thru the run-time interpreter).
Oh, and assembler is not 100,000 times harder to code. I actually found perl made me cross-eyed for quite a while before I grokked the mind-set behind it, and now I use it whenever I need a quick-and-dirty script to fetch some data, process it, and give me the results.
Re:Yes (Score:5, Insightful)
in a lot of cases this bias is justified: shell scripts have more portability problems as, say, the location and vendor for awk differs from system to system, or the behavior of "echo -n" changes. this carries over to, say, C vs perl as well: in most cases a C program will run faster with a lighter footprint than a perl script, so when either of those are a big concern then how you solve the problem is as important as the fact that you solved it.
i'm afraid i share the bias for this reason. i think you should pick the right tool for the job, not just do everything in perl because you're a "perl guy" (or a "C++ guy," for that matter). sometimes that means spending weeks writing a program in C that you could do in a few days with perl.
Re:vs programing? (Score:1, Insightful)
Sometimes the issue may be more related to the company wanting to keep to their standards. If C++ is their standard programming language then it makes sense for them to enforce that. That way when someone is hired they know what skills that person needs and the hiree knows which skills they will need. It makes it easy to bring new people onto a project as well.
However, I think the issue is that most companies don't have a standard scripting language but they need one. If a company needs to standardize then they need a standard compiled/general purpose language (or two), and a standard scripting/high level language (or two).
Re:On the contrary - (Score:5, Insightful)
Re:Certainly not (Score:2, Insightful)
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 [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.
Sure, but (Score:5, Insightful)
But ya wanna know what? I *love* scripting. When I'm building a large scale application, I'll often embed a scripting engine, just so that (a) I can modify smaller bits of functionality, without a recompile, and (b) others can do the same.
Heck, often I'll write unit tests in a scripting language, so that I can drop them into a production system in order to test, or do some ad-hoc/on the fly debugging.
Scripting is a type of programming, that to compiled-languaged developers, somehow fails to feel like programming at all. It's often viewed as some sort of "configuration language".
When it boils down to it, I don't know *why* scripting/scripters are discriminated against, it just seems that they are.
Alright, you scripters! Back of the Bus!
Re:Right tool for the job (Score:5, Insightful)
To the untrained eye, perl looks like line noise, and may be rather difficult to maintain.
To the untrained eye, English doesn't make any sense. When hiring someone to maintain Perl scripts, one should look for the trained eye, yes?
Re:Flip side (Score:3, Insightful)
That's funny, except what's funnier is that I consider Java a scripting language.
If it ain't compiled into assembly language, it ain't real programming.
That said, I personally do more programming in Perl nowadays than C or C++ because it's appropriate to the primary project that I work on. I don't pretend that it's real programming though.
Re:PSST (Score:3, Insightful)
Law of leaky abstractions (Score:5, Insightful)
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...
I disagree 100% (Score:5, Insightful)
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.
Static type checking is good (Score:2, Insightful)
Someone should invent a scripting language with static type checking. (Are there any?)
Yes, scripters get short shrift (Score:5, Insightful)
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.
Call me a PHB if you like... (Score:2, Insightful)
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
Standards (Score:3, Insightful)
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.
Re:Flip side (Score:5, Insightful)
Re:Blame the dot-com goldrush... (Score:4, Insightful)
No kidding. Example: Apache webserver: 700 pages/sec on Dell Poweredge 1300 PIII 550MHz (in 2001). Perl webserver: 700 pages/sec on my beige box Athlon XP 2000+. Kind of funny to do pattern substitutions on the fly on webpages
At my prev company, due to a request from my boss to filter out various sorts of email, I configured some dot qmail stuff to call a perl program. Sure C could have been faster, but while with Perl I was introducing a performance hit, I could be pretty certain I was not introducing a security problem - no risk of buffer overflows, and if memory usage gets too high, ulimits kill the process. The code was short and simple - return different exit codes depending on what sort of patterns matched.
Nobody noticed any performance slow downs (the final windows based mailserver was usually the problem
For fun I recent wrote pop3, smtp and plug proxies in perl. AFAIK stuff like this would be fine for small orgs. 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.
Re:On the contrary - (Score:5, Insightful)
Happens all the time (Score:5, Insightful)
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
Not in my workplace... (Score:2, Insightful)
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
Don't blame the intern! (Score:5, Insightful)
Re:PHP scripting/coding/whatever (Score:4, Insightful)
There's some problem that some java developer sees with php. Some of it being it's OOP implementation. A lot of enterprise stuff that follows OOAD, which a lot of developers and analysts are getting to like, relies on OOP. Strong data types make things easier for automated tools, for say, reverse engineering (by tools, not human).
Ruby on the other hand, is strongly typed and OOP Python too (I *think*). If he has no problems with those, then he's just an OOP zealot. If he still does, just find everything possibly wrong with java, like large memory footprint, slow startup.
Managers making technical decisions (Score:2, Insightful)
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.
no, it _is_ credible (Score:3, Insightful)
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.
Re:On the contrary - (Score:2, Insightful)
I was trying to illustrate the idea that if your script/program will get hit a lot, or be in production for a long time, it could very well be worth your while to invest a little more time up front.
Caveat to the Small Fish (Score:5, Insightful)
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.
Re:PHP scripting/coding/whatever (Score:5, Insightful)
The problem isn't the language, or anything remotely to do with programming. The problem is that most programmers are as arrogant as all get out. They find something they like, and because they are convinced that everyone is their intellectual inferior, they need to point out the error of their ways.
Re:my belief (Score:3, Insightful)
Scripting is the glue to tie all of the other stuff together, and automate routine tasks.
When all is said and done the design problem with many systems is making the assumption that integrating them with other systems is "easy".
Scripting is a necessary component of system integration and in that sense if you don't make it so you can use scripts to tie your systems together, you end up coding in more and more interfaces and wasting time changing things in complex code when what a simple solution would have sufficed.
Re:Certainly (Score:3, Insightful)
But none of these cool technologies existed when slashdot first started. There was only tables. If you were writting slashdot and supporting slashdot from the same start time, I think you're code would be full of things like "kludgy tables". The "cool" stuff you seem to like was all invented in the post-slashdot era. They run a web-site and are not fortune tellers.
Re:IT's called a standard (Score:2, Insightful)
My interpretation of it, anyway...
Re:I disagree 100% (Score:5, Insightful)
What do you mean 'maintainable'? Sure, an incompetent programmer can screw up the best languages. But the programming languages aren't designed to help incompetent programmers -- they're designed to help competent ones. I remember reading about a study done in the 80's that suggested that experienced coders wrote as many bugs as inexperienced ones -- they just found more of them before the ship date.
With that in mind, there's a hierarchy of places that bugs exhibit themselves, going from good to bad. The best bugs don't get written; the next best are caught at compile time. After that, are bugs which cause the program to crash immediately (fail-stop) and the worst are bugs that cause random, non-evident behavior much later down the road. Anything you can do to push errors up the hierarchy will make programs easier to debug and maintain. Hence strong typing languages, OO, things like that.
Sure, all decent languages have comments, functions, ways to structure the code that make it somewhat easy to read. But last time I checked (which was a while, granted) Perl didn't have strong type checking to make sure you didn't pass the wrong kind of thing to a function. You have a handful of data types that do everything; it doesn't allow you to make assumptions about what other bits of code are/aren't doing, as you can with a properly-organized strongly-typed language. That's the next step in maintainability -- partitioning the thing into littler bits and making sure they work right, and moving errors up the hierarchy to compile-time errors.
Re:I agree, but... (Score:3, Insightful)
Yes! I wholeheartedly agree!
Nope (Score:3, Insightful)
When I have to write something in C it's just never as easy or bug free.
Re:Flip side (Score:4, Insightful)
Yes, and partly language designers' doing (Score:3, Insightful)
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.
sh + sed vs. Java (Score:4, Insightful)
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.
"Executive-level" management (Score:3, Insightful)
Re:weeks vs. hours (Score:4, Insightful)
It took me 20 minutes of browsing CPAN to come up with this (admittedly stupid) example, I'm sure I could throw in lots more freaky CPAN modules to make life harder for the C folks.
CPAN is what forced me to learn Perl. I'm sure a lot of these libraries exist for C, but it's much harder to find 'em, and who knows if they work on your platform? Let's stipulate that our program will be deployed on a DEC Alpha running WinNT...
Re:Yes (Score:5, Insightful)
Re:Yes (Score:3, Insightful)
Well I think that's taking it a little far. And I'm a scripter. Actually a programmer who uses scripting languages to solve problems. I use and compile C code to do my job but don't write C. I don't use Java because... well, it's Java. I can do everything faster and easier in Perl, and I haven't found anything yet that Java can do but which Perl cannot (insert holy war here).
Anyway, I disagree with what you say, mainly because companies do have reasons for not liking interpreted languages. Not that they're good or fair reasons, but they're certainly legal, as opposed to discrimination based on race or gender.
First of all, standardization is something that has a lot of value in the corporate environment to keep the IT departments from becoming free-for-alls where you never know what something is going to be written in or maintained.
And we all know that Corporate America always needs somebody to sue. If the choice is Java or Perl, Sun is much more likely to be able to pay you off than the Perl5 Porters when you're idiot programmers do something stupid and you feel the need to blame somebody. Again, it's not right, but it's how they think.
What tool you use is also not totally pointless. For example, I wouldn't dream of bringing in a Java or C++ guy to maintain and extend a site that I've written in Perl. Does that make me a Java bigot? No. I am, but not for that reason. The fact is that baseball teams don't hire cricket players. So this is another completely valid reason for this dicrimination by companies. They can choose to have their code written in whatever crappy compiled language they want.
RP
The way out: "Prototyping Language" (Score:3, Insightful)
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.
Re:Flip side (Score:5, Insightful)
Wrong, wrong, wrong.
First, your precious native-code compilers compile into an intermediate language as well. No modern CPU runs a program as-is -- they all have tricks like microcode, out-of-order execution, register renaming, and other hand-waving that make the actual program run by the CPU quite different than the one sitting on your disk. I'm sure "that's different" for some reason, of course.
Second, Java bytecodes are a machine language. Admittedly, no 100% complete implementation of the machine in question exists, but I fail to see how that makes a difference. Are you saying that if I extended the picoJava CPU core to natively handle the last few instructions that are currently emulated, suddenly Java would switch from being a "scripting language" to a "real language"? That's asinine.
That's the primary reason that Java is so slow. The bytecodes cannot be efficiently interpreted.
The primary reason Java is "so slow" is that most of the people claiming that haven't used it in years. Java 1.4.1 is pretty damned fast as I see it. The other reason that Java is seen as slow is that its GUI libraries are not as fast as the native libraries. That doesn't have a thing to do with bytecodes, but rather with how they were designed.
There is nothing special about bytecodes that makes them any more difficult to run efficiently than any other programming language. In fact, they open the door to a lot of optimizations that are all-but-impossible with other languages.
There are things in Java that will NEVER allow Java to be useful as a general purpose language. The lack of an unsigned datatype is probably the most egregious flaw.
The only reason that unsigned datatypes matter one iota is in interfacing with someone else's code that does use an unsigned datatype, in which case nasty conversions must be done. If you don't need to interface with such code, you find that they are completely unnecessary. I fail to see how that is such a serious flaw.
I'm not saying "Java is the bestest language EVAR!!!", but please get your criticisms right.
Re:Hardware is so fast and cheap... (Score:2, Insightful)
Even today, this is very frequently untrue. I think it's more accurate to say the data structures have grown sufficiently to tax even the newest processors. This is true in the graphics industry, manufacturing, electronics design, etc. In other words, we are tackling ever larger and more difficult problems in about the same amount of time.
I'd also add that large programs will never compile fast enough. 90,000 lines of C code still takes long enough to warrant a short coffee break. Much more than that, and SMP or grids are needed to remain highly productive during the day. Huge projects have to leave full compiles to an over night batch job.
Scripting languages or "scripters"? (Score:2, Insightful)
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.
You all are missing the biggest thing.. (Score:5, Insightful)
Scripting limits the choices of the developer in terms of licensing. It can cause incompatibilities when the user needs different interpreter versions for different scripts. And god forbid a pointy haired boss accidentally edits the program in ms word and it no longer works. I can just imagine the support phone calls..
Re:I disagree 100% (Score:5, Insightful)
a) language is OO
b) language is statically typed
c) language is 'scripting language'
Examples:
Java: a+ b+ c-
CLOS: a+ b- c-
Perl 4 (non-OO): a- b- c+
Ruby: a+ b- c+
etc.
You can have any combination of these 3, but none of them correlates directly to maintainablilty.
Re:mod_perl (Score:3, Insightful)
Technology choices are seldom rational (Score:5, Insightful)
After all, if technology selection was rational, everyone would be using Lisp or Smalltalk.
Re:It's about stability (Score:2, Insightful)
I don't know about that...I think the common usage of words from other languages in English writing provides a certain je ne sais quoi. Admittedly, use of other languages in English writing can be confusing. Especially when it is done to showboat, attempting to project the ersatz impression one is a member of the intelligentsia, when in fact they are little more than a schmuck, a putz, et cetera...in any case they deserve a good kick in the tokhis. If this gets out of hand things could run amuck. Capice?
Now, the problem of when to use a foreign word in your writing could be the source of considerable angst. How do you know when its the appropriate moment for a bon mot. Are you expected to be some kind of polyglot!? It could drive you loco!
I think your choice of metaphor is excellent - unfortunately it comes close to proving the opposite of your conclusion. Using the best tool at the right time can be very efficient. Even quickly throwing something together can be very effective, just making it up on the spot to fit your need...ad hoc, so to speak, e.g. the word television (although half Greek and half Latin...well you know... [worldatwar.org])
English itself is a lower Germanic language that has been infused/hybridized with Scandanavian, French, Latin and Greek, to name just the most significant influences. In fact most of our grammar is latinate by custom, imported omnibus by pompous scholars who thought English 'ought' to be like Latin, not by need and certainly not because that's the most useful place for our language to be at [yourdictionary.com]. (Reminds me of how every language seems to read like C these days...)
I don't disagree that uniformity often leads to quality, but it isn't a precondition. Standards are important - but ultimatly those standards are in place to affect cost savings and if a "script" can provide a real efficiency than it's a good bet that it would be beneficial to use.
Anyways, I don't claim to be any kind of guru or sensei about this stuff. But from where I stand, just like the struggle between providing security and providing features that is seen when designing an application, the tension between standards and specialized tools when choosing what coding platform to use is all part of a balance.
It's sort of a...yin-yang kind of thing....
The problem isn't scripters (Score:3, Insightful)
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...
There is a reason why. (Score:1, Insightful)
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.
Re:What is the difference? (Score:2, Insightful)
I realised this a while ago, and now I have a basic grounding in Perl, PHP, Unix Shell Scripting, C++ and Java, all of which I can build on to further my knowledge base.
I don't claim to be a l33t coder or anything like that (I mean look at my C++ code- uurrgggh) but at least I know the value of not putting my eggs in one basket.
Guys...cant we work this out? (Score:3, Insightful)
Here're my tips to keep both sides productive and respecting each other:
Re:PSST (Score:3, Insightful)
How about if I modify it along these lines:
Actually, I think a better analogy is like, where do we draw the line between living and non-living - are viruses (the biological kind) truly alive, or are they just chunks of dna with the ability to convince host cells to replicate them? That debate's been going on for decades, and isn't decided yet either :-(
* what made me re-read what you wrote was the TIHNSIANO. I think it's pretty catchy, at least on a par with TMTOWTDI :-)
Wtf is a 'scripter'? (Score:5, Insightful)
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.
The race is not always to the swift... (Score:4, Insightful)
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.
Re:Legitimate concern (Score:2, Insightful)
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.
I don't mean to be cantankerous but that's grossly inaccurate.
Scripting languages (which due to the examples and other posts people are taking to mean runtime interpreted languages, probably including ruby and python and the rest even though they have a byte code compile phase at the beginning of execution. If you using the term scripting languages to describe languages that are designed to be efficient to code in, we are talking about intent and that becomes very blurry indeed and you can say what you want. I don't think that's the nature of the question presented at the top of the page.) are not all designed around letting small problems be implemented quickly nor are they not designed to have maintainable code for large scale projects.
Python, probably considered a "scripting" language by many people in this discussion, leads to some of the most maintainable code (even if it is slower to initially develop than say ruby or perl) that I have ever seen. The syntax draws coders to write in a uniform style and excellent maintainability over time and multiple coders (rather than perl's TMTOWTDI). The """here""" documentation for modules, classes, methods and functions are absolutely key for large scale development. The ability to introduce new code into a currently running isntance means that you have a builtin debugger and more just by picking python.
I have a number of carps with python. I certainly don't think it's the end all language. In many cases I'll pick other languages over python, for example, ruby. ;)
As a Tru64 kernel developer I code in C all day. I've been writing code in interpreted and compiled languages for over 20 years. I see both the benefits and the detriments of coding in only one or the other of programming languages and scripting languages. I think in any project of scale they both have a place. Often in the same project. Yes, using one in place of the other can get you in trouble some times.
HEY! Who has the Authority here? (Score:3, Insightful)
Leave the technical decisions to those most closely coupled to the technical problem. Perhaps a few companies should learn a bit from Demming.
C//
But we do not have perfect information (Score:1, Insightful)
Yes; but there are a good many MIS types that learned to script in a halfassed manner, but never to program. So while there are quite talented scripters, there's also a large body of "web developers" and "database programmers" and "sysadmins" that aren't particularly skillful at development. So talented scripters get a bit of a bad reputation from this.
Seriously, now, if the only thing you knew about two people was that the first is experienced in Visual Basic (or perl), and the second in C++, which are you more likely to (barring any other information) attribute a higher level of skill to?
Can you make a bogus decision this way? Sure. But you run the risk of that any time you have incomplete information about someone's abilities.
on the flip side (Score:2, Insightful)
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.
Re:weeks vs. hours (Score:3, Insightful)
You issue a challenge where you will never accept the answers, because you can always argue that a C++ programmer could theoretically beat that time. And you'd be right, because the well-documented LOC difference for significant programs between, say, Java and Python is on the order of 5 to 10. In theory, if both programmers program perfectly correctly, the Java programmer will only take 5 to 10 times as long, because that's how much more typing they need to do. Thus, you'll never be satisfied with the answers, because you can always counter-argue, and in the absense of experience you can always counter with another anecdote, or accusations of incompetence in the programmers use of C++ or Java.
However, I'm not going to argue on your terms. Instead, I simply say this: In the experience of people who have used both, Python or correctly-used Perl (which, BTW, tends to look pretty Pythonic if you want it to be maintainable) does indeed give advantages on the order of 10 at the minimum, usually more. I find the advantages multiple exponentially as the product gets larger; to lay my cards out on the table, I believe that most conventional applications, even ones sized in the multi-megabytes, should be written in "scripting" languages*.
I'll briefly justify this by waving my hands in the direction of the well-known facts surrounding how many lines of code one programmer can produce and maintain, and point out that the effects are exponential as each module requires fewer lines, but it's handwaving and any Slashdot comment, which can't be book sized, must consist mostly of hand-waving. So instead I offer this challenge: Based on people's experiences (LOTS of people's experiences; just search on groups.google.com through comp.lang.python, for instance), and based on this LOC justification, try Python for a good six months, on something serious. Do your own research.
Worst case scenario, you learn another language which might expose you to a few idioms you didn't know before. Best case scenario, your effective productivity multiplies, which will easily pay back the time you put into it. I can't prove this for you, you can only learn yourself.
*: And I'm putting my money (well, "time", but time is money) where my mouth is. I have a large application I'm building, all in Python, and while it's not done, I've only spent my spare time on it and the parts that are done are ahead of all the competition I've looked at so far, almost all of which are done either in conventional languages, or someone who is still writing Python as if it were a conventional language. This also includes, in terms of capabilities, my knowlege of the commercial competition, certainly written in C/C++. There are some parts where it would be a full time job to replace a single component in C++ for a whole (person-)month because of the time-sink that strong typing can be in certain situations. (See "Design Patterns" for examples; many of those patterns are ways around type prisons.) Again, in theory somebody could type it in directly, correctly, in one or two days with no mistakes, but we all know it doesn't work that way. C++ requires a lot of debugging. If I were trying to write it in C or C++... well, frankly I would have given up, as I'd never finish it this decade on my own, no matter how 'leet I am at C++. I like C++ for what it is... but it's so... clumsy.
Re:I disagree 100% (Score:3, Insightful)
I'm not sure you're thinking, and I'm certain that you're wrong.
Bzzt. Wrong. C++ is strongly typed (try passing a Foo to a function that expects a Bar (where Foo does not inherit from Bar). That's strong typing.
There are hacks to get around the dynamic typing (RTTI, mainly), but they're considered poor C++ practice.
Re:Legitimate concern (Score:2, Insightful)
I'm not saying that makefiles are inherently ugly or bad. What's ugly is that to compile any application involving more than one source file requires you to write "code" in 3 languages with 3 distinct syntax requirements. C syntax, preprocessor syntax and makefile syntax. Because C, the preprocessor and makefiles have been around for decades the problems are well-understood now and people have gotten used to them and written many tools to deal with them, but by default the c, preprocessor, makefile combination is awful for dealing with large projects.
Do Scripters Suffer Discrimination? (Score:2, Insightful)
the difference between scripting and non-scripting (Score:2, Insightful)
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?
Re:Government Contracts (Score:1, Insightful)
I almost didn't want to dignify your bait with a flame, so I'll bite anonymously...
You don't think anyone can disagree with that opinion? Are you serious?! Do you think embedded Perl support in Apache and Netscape web servers is only for prototyping and non-production systems?
It's possible, but I'm curious if you believe it.
I disagree to the disagreement (Score:2, Insightful)
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.
Engineering. (Score:3, Insightful)
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.
Re:I disagree 100% (Score:3, Insightful)
Aha... but you're not passing a Foo, you're passing a pointer to a Foo. Those are two completely different things (and every C++ programmer knows that).
Your analogy fits even worse. (Score:1, Insightful)
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?
Re:Yes (Score:4, Insightful)
Re:There really is a difference (Score:3, Insightful)
Anyway, I don't see how it matters which language my compiler (or interpreter) or libs are written in. Programmer productivity matters more. Sometimes that can only be achieved close to the metal, sometimes the effort is better spent elsewhere. The real standard should be "horses for courses." Minimize the number of languages used in order to keep complexity down, but do it in the easiest, most concise way, keeping in mind the skill set of the people who are going to maintain it. And remember the tradeoff between having them do it the hard way over and over again and having them learn something new. Equally important is that the languages chosen (if more than one) have to have well-documented interfaces (for instance, the Python-to-C extension APIs).
The thing to watch for is that the scripters don't think that the shorter development cycle is a reason to give up testing entirely. This happened with lots of web scripting that I've seen, and may have contributed to the shoddy reputation for scripted code in some quarters. But anyone who thinks that a stricter compiler will save the world is also mistaken, and I've seen C and C++ programmers blow off testing too. What you win with so-called type safety you lose through inflexible semantics and the proliferation of special cases. And remember that the type-checking hoops you have to jump through are imposed by your choice of tool, not by the problem you're trying to solve, so there's little assurance that the bugs you're finding actually make the final software better. My experience is that you get to the bugs more quickly and can fix them more quickly in Python or Perl than in C or Java-- though in some regards Java is halfway a scripting language anyway, so I'd place it midway between C and scipting in terms of ease of use (as well as doing things behind the curtains that you might not always approve of).
Both programmers and scripters are doomed by... (Score:2, Insightful)
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.
Languages are just tools people! (Score:3, Insightful)
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.
Re:You all are missing the biggest thing.. (Score:2, Insightful)
2) Many companies develop programs that they could care less whether the people using the code could see it or not. Most companies do not sell software, yet many of them have people who work there writing software.
3) Scripting does not necessarily limit developer choice in terms of licensing. Whether the user can view the code or not is not material to the actual license on the code, and most scripting languages do not purport that the license of the interpreter extends to the scripts themselves.
I think scripting is discriminated against only insofar as its still kinda the new kid on the block. It has a bit of that "Unix admin" patina to it, mixed with a bit of disdain for VB and macros, then there's JavaScript where web developers pretend to be programmers (joke!)... none of the advanced scripting languages is particularly mature yet and none of them have large companies bellowing about them all day long.
doubt this is true: (Score:3, Insightful)
If it is, they need to get some different C++/Java programmers.
Re:PHP scripting/coding/whatever (Score:3, Insightful)
No, it isn't. It's a language that can be interpreted. Most java-implementations aren't though...
In this situation, the Java program is (obviously) much faster than the interpreted bytecode version.
No, it isn't. Typical scripting languages use heavily optimized string routines, etc... In many cases, an obvious perl (or PHP I guess, although I have no experience with it) program can be faster than an obvious java (or C) program. But it certainly depends on the task you are doing.
The same is true of many other interpreted languages, optimized for specific tasks, e.g. prolog, mozart, K, J, APL, etc... Sure, in theory, native code is always better, but in reality, we seldom spend weeks, months or years to optimize for performance, but opt for simplicity instead.
Obvious too is the fact that the native code version won't run anywhere but the target machine.
Yes, but usually, we are not writing native code (or even assembler). We are writing in a high-level language, and usually, it is not too hard to compile them for different targets. Porting a reasonably well-written C program can often be much easier, then having to keep 60 different versions of JDK around, to be able to run all your Java programs (compiled to .class-files), or even make one non-trivial java program that will compile and run on all those versions of JDK.
Don't take me wrong, I really like PHP and I don't dislike Java at all. Just wanted to point that
Fine. I hope you understood what I told you, so you don't have to keep going around "pointing that" (whatever that means).
Re:doubt this is true: (Score:3, Insightful)
There have been a number of studies of this very issue, and the general result has been that Java/C++ coders take about 2x longer to write a similar program than Perl coders do. What they get for the additional time spent on the code is generally a faster running program with better modularization.
You pays your money and makes your choice.
Re:On the contrary - (Score:2, Insightful)
Exactly. That's why you write the prototype in Python, then profile the code to rewrite the bottlenecks in C.
Remember that time to initial solution can be as important as time to run the solution.
TTFN
Future Reality of Software (Score:4, Insightful)
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
Because the word "script" is too lightweight. (Score:3, Insightful)
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
Wimp! (Score:3, Insightful)
REAL programmers:
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.
Re:sh + sed vs. Java (Score:2, Insightful)
Real values vs marketing clout (Score:3, Insightful)
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.
Re:totally agree (Score:3, Insightful)
does that make me a bad programmer?
No
Because you're able to admit you have a problem with the languages. And with the set you list I'll be surprosed if you have trouble learning cobol if you have to. What would have made you a bad programmer would have been if you had known only one language, and out of fear of having to learn a new one deem all other languages inferior.
A good programmer knows his limitations, and how to overcome them
It's inevitable (Score:3, Insightful)
Re:You all are missing the biggest thing.. (Score:2, Insightful)
Re:Yes (Score:3, Insightful)
Your maint point is right, but I wish you hadn't said:
Now that's just ridiculous. Everybody keeps saying "you need someone to sue" but the fact is that you can't, not past the first motion to dismiss for lack of cause. Sun is not liable for your damages if you misuse Java. Short of unprecedented extreme negligence, Sun is not liable for your damage if you use Java correctly and bad things happen that are Sun's fault.
"We need someone to sue" doesn't even pass the basic bullshit test. Sun is ten times as likely to pay you off as Perl5 Porters are--but ten times zero is still zero.
I am not a lawyer, but I do read things besides /.
Re:PHP scripting/coding/whatever (Score:3, Insightful)
Yes, very true! Take your try at any nontrivial perl-program. Rewrite it in C. Now, pick your alternative: maintainability, speed.
And I would reverse your statement about a poor programmer. A poor programmer is one that doesn't know to choose the right tool. If you feel like spending months writing in C when I can spend a few hours on a Perl script and get the same result, then you are the poor programmer. (For the record: I'm hardly a perl-bigot, as I work almost exclusively with C and C++ code that is extremely speed-critical, to the point where a single second lost, will most likely cost us a few thousand dollars, if not more. Obviously, for such code, reliability and maintainability is also important. We use perl where it's easier and better).
But Perl can ALWAYS be beaten by C
Sure, Perl is written in C itself. By taking out the interpreter, you'll get faster. But for any project with a deadline, it's certainly not true.
It's not hard for a below average programmer to write a Perl script in a day with a performance and reliability that would take weeks if not months to achieve if it was written by an above average programmer in C. Of course, the opposite is also true, but with the exception that the Perl programmer is likely to never succeed.
For it's class of problems, Perl is surprisingly fast.
Re:PHP scripting/coding/whatever (Score:4, Insightful)
Yes, very true! Take your try at any nontrivial perl-program. Rewrite it in C. Now, pick your alternative: maintainability, speed
Hmmm, the choice is rarely as simple as that. Perl is not inherently more maintainable than C. As far as picking a non-trivial program... project size is usually directly proportional to maintainability in Perl. Additionally, Perl encourages poor coding practices. Note that I'm not saying that Perl forces poor coding. It simply makes it easy for immature coders to be sloppy and lazy. I've seen countless newbies come and go who wrote some god awful code that wouldn't be possible in a more structured language. In a business environment, reliability is important, and the gains made when a project manager knows that a certain class of problems are eliminated by choosing a structured language (though C is not generally the best choice for this) is invaluable.
And I would reverse your statement about a poor programmer. A poor programmer is one that doesn't know to choose the right tool
That's hardly a reversal of what I said. We're talking about execution time and you implied that I said C was always the right tool. Untrue, and if you go back through my comment history, (if the last n comments happen to contain one) you'll find me saying the same thing... the right tool for the right job.
If you feel like spending months writing in C when I can spend a few hours on a Perl script and get the same result
It's not hard for a below average programmer to write a Perl script in a day with a performance and reliability that would take weeks if not months to achieve if it was written by an above average programmer in C
That's bordering on FUD, and is most certainly hyperbole. Hours versus months, no way, weeks vs. a day, uh uh. A good coder who knows both languages can finish them in comparable time. I know from experience I can beat an average Perl programmer on the same task when writing the code in Scheme, C, or Java.
Perl is incredibly fast, and incredibly useful for a commonly occurring class of problems. Sometimes it's the right choice sometimes it isn't. It's a great language, and has replaced shell scripting for me personally. When I need to whip out a relatively small application I do it in Perl, for the main project it's generally C or Java.
Is it really about programming languages? (Score:2, Insightful)
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++.