Slashdot Mirror
Do Scripters Suffer Discrimination?
TheTheologian writes "In his InfoWorld column, Chad Dickerson says 'there is a level of quiet discomfort between the "scripting" versus "programming" factions in some corporate development environments in which I have participated. In some instances, executive-level technology management has held scripting languages in disdain as not being "real" languages for day-to-day problem solving, which has discouraged highly talented scripters on staff from practicing their craft. In such an environment, scripters are relegated to the lower ranks ... ' He goes on to say that some companies will assign Java and C++ programmers tasks that take them weeks but could be done by Perl or Python programmers in a few hours. Is it true that some companies are so overcome with code bias they'd assign weeks of unnecessary work rather than give it to the scripting untouchables?"
In reference to perl vs. C that scripting is good for a quick and dirty "proof of concept"
is that it stops being 'scripting' and starts being 'programming' based on the scope of the project. Processing a web form is scripting. Writing a GUI app (be it in Win32 or wxPython) is 'programming'.
"I would say that 99 per cent of what my father has written about his own life is false." - L. Ron Hubbard Jr.
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.
There seems to be this mindset in large corporations that all "programs" have to be written in C, Java or another "compileable" language. In my job at a very large company (Caterpillar) we especially see ancient VAX-based apps or newer web applications that months are spent on, when a simple Perl script would do the same job in a matter of weeks or days.
Moderation: Put your hand inside the puppet head!
Hey, if all those art majors and wanna-be fashion designers hadn't decided to become "web developers", maybe someone who can write an actual program in Perl might get some respect.
Seriously, scripting languages have been "tainted" by the Web. "If it's a script, it can't possibly be worth anything" is a pretty common mind-set these days.
While I've seen some pretty awful C and C++ code out there, it's nothing compared to the horror of amateur Perl or (shudder) Shell scripts.
It's interesting to consider that scripting languages have been able to ride Moore's Law to the extent that you can reasonably implement things in a scripting language hat would have really needed to be compiled a short time ago.
-Mark
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.
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'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.
I work in industrial information management, which is often accomplished using various types of information technology. Just from exposure, I've picked up and used some scripting tools to solve problems.
The fact that I use scripting tools some of the time was held against me in a review. Remember -- I'm not even *in* IT, not required to know programming *or* scripting -- but the value of "script kiddies" has been so diminished that the management here heard I could use scripting, assumed I was another devalued dot-com remnant, and assumed my value would be much lower. I was able to explain the difference to them eventually, but at the time, I thought their zeal to devalue scripters was noteworthy....
He goes on to say that some companies will assign Java and C++ programmers tasks that take them weeks but could be done by Perl or Python programmers in a few hours.
Someone please give me an example of such a task.
If this is from a real world example (which I doubt) then I think those Java/C++ programmers shouldn't be employed.
I think that, once again, someone is under the impression that a person is only capable of one skill.
Is the author in management somewhere?
No kidding!
We had an intern who wrote a bunch of stuff in Python and Ruby. He was all gung-ho on those languages and made a big deal about how they were "it". When he left, no one had the time to learn how to support these languages, so we ended up re-writing them in Perl so that everyone could support them.
FYI: his scripts sucked, too. He'd make lots of dumb mistakes like assigning a variable called "retval" and then checking "ret"!!! Duh. gcc would have caught this immediately, so would "use strict".
https://www.accountkiller.com/removal-requested
One little piece of common sense to remember, though, is that it doesn't matter that e.g. Python would only take 10 lines and is easier to read, if there is only one person at the company who knows Python, and the other 30 developers only know C/C++/Java. You can argue that Python is easy to learn, and easy to use, and I will agree with you to the ends of the earth, but that doesn't mean that a particular individual will find it easy to learn or use.
;)
The additional factors of training expenses and/or recruiting and hiring someone who knows the language should be taken into account when evaluating the tools used on a given project. This is a basic thing in managing a project. It is only my personal opinion that sending all 30 developers out to learn Python is the obviously correct solution, that will save the PHBs (and developers) time, money and frustration in the long run.
...at this point, wouldn't it be a good idea to pick ONE of the scripting languages, and make it a co-standard? Sure, allowing anyone to code in language du jour isn't a great idea, but taking forever to do code simple programs because C takes forever to develop with...well, that ain't so great either.
-Looking for a job as a materials chemist or multivariat
I code both, and I agree with the columnist, although the column was a bit lacking in useful information or original opinion (although he did give a decent analogy), so here's my take on the subject.
When I have to decide what language(s) to use in a project, there are many factors entering the decision, beyond a simple analysis of mile hike vs. Mt Everest. As he touched on, some languages have specific strengths and weaknesses. I wouldn't use java for parsing large text files unless I had other really good reasons to do so.
The only place this breaks down is maintenence. I think that, and the low entry point actually one of the big reasons scripting laguages are looked down upon. You end up with a lot of scripts in place that were poorly written by inexperienced programmers, which have gotten even worse as other programmers applied patches and bug fixes. ASP is particularly offensive in this way, as, while it is possible to write clean & readable code with it, most people will find it much easier to write nightmarish spaghetti code.
What the initial programmer expected to be a mile hike, turned out to be something much longer, as scope creep and unforseen bugs turned it into an expedition. Rather than turn back and resupply, the stubborn programmer kept going, marvelling at how clever he was to keep himself alive with only a swiss army knife. Unfortunately, this lack of sufficient tools carries over to every other trip up the mountain to fix a bug or add a feature, and clever hacks turn into brutal kluges.
There's not always a right answer, but everything has its strengths & weaknesses, and refactoring or restarting from scratch is an often overlooked option at any stage in development.
Money I owe, money-iy-ay
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
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.
Python will also catch reading of a variable before it has been assigned to. Python does not have a 'use strict' directive. Are you sure you know which languages you're talking about?
It's a hell of a lot easier to get a "programmer" to learn a scripting language, and make good use out it, than it is to take a "scripter" and have them learn a programming language and make good use of it.
I'll use the AutoCAD example:
AutoCAD has a built-in LISP interpreter. AutoCAD also has a C++ interface called ObjectARX.
Many "CAD Managers" have picked up LISP (become "scripters") over the years and have used that to automate repetative tasks in AutoCAD. Although useful and helpful, this LISP code is often a train wreck. Suddenly they will reach a place where they can't figure out how to move forward, or need something beyond this simple functionality.
You also have people that have "picked up" ObjectARX to write "C++" applications, that in reality are just LISP routines ported to C.
Then you have trained "programmers" that understand OOP and design. These individuals can step in and make use of the "true" power of the engine that AutoCAD has. These same programmers can write LISP or VB/VBA if they have a "quick and dirty" or need a "proof of concept" app. However, you'll never have the other guys comming out with a real robust add-on like the "programmers" can.
It's not that it's "descrimination," the issue is that people trained in CS are able to choose the right tool for the job, not "fumble around until they figure it out." This has unfortunately become the stigma for "scripters", because scripting is a lot easier to pick up than real software development methods, and as such you have people that may not really understand what they're doing performing the task.
C
- Sighuh?
Everyone assumed I would simply pick up his work and continue with what was in place. Upon inspection, I realized a huge chunk of his build system was C-based, with some BASH thrown in to tie the Makefiles together.
I took on a major task (of course without telling anyone =] ) and rewrote the build system in TCL (and improved the BASH imports to the Makefiles). I can't recall the imrpovement we had, but it was impressive. And it took a couple of weeks.
It proved to the co-CMs the improvements that could be gained with pure scripting without any need for "code."
-- SegFault
"One day, some time ago, something important happened."
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...
I work as a tester for an embedded systems software group. When I started here, all of the tests were hand written and formatted. With information coming out of various databases and models.
Basically, none of the programmers wanted anything to do with formal testing so the process was a mess. I decided something had to be done. With the use of a MatrixX script and some Perl Scripts, a process that took 4 hours was reduced to 15 minutes.
Needless to say, this got a lot of attention. Since then, the company has decided to start sending people to training to learn scripting languages.
Unfortunately no one can be shown what Linux is, one must experience for oneself.
I followed the programming (as opposed to hardware) branch within the Computer Science degree program at my University. At the university there was no stigma placed on one language over another, and so armed with my previous experience with basic, pascal and fortran, I dove into classes on perl, sed, awk, and Unix shell programming, as well as C++, Java and Lisp.
My first job was as a Unix systems administrator/technical support weenie on an proprietary embedded system. The system did not have (and it was not legal to add, without breaking our maintenance agreement) a compiler. So, any automation we needed to perform was in the form of shell scripts.
I ended up building a full blow interactive application that hundreds of people use on a daily basis to this day. The last bug for this system was found in 1999. Scripting allowed us to extend the functionality on that system, and all of the design tasks and lifecycle considerations were the same.
I have been in several projects since then, big and small. In every case I always was able to make the decision to use a scripting language if I thought it appropriate (for example, we needed to perform remote administration on hundreds of machines; what better way to automate this functionality than with Perl and Expect.pm - so I did). As a developer I always keep my eyes open for the most efficient means of getting the job done.
Perhaps being a system administrator for a time helped me avoid the stigma associated with 'scripting'. To me it is all just programming - plain and simple. Those that limit themselves and don't grok as many languages and methods as possible are selling themselves short. Today I am extending my abilities by teaching myself python, and extending my perl repetoire with perl/Tk.
Holy wars are only an overt attempt to subjugate other's ideas to your own. Its wrong - so, STOP IT!
Lodragan Draoidh
The more you explain it, the more I don't understand it. - Mark Twain
In 1993, programming was done in C and scripting was one in .bat files or shell scripts. It would be fine, even good to descriminate between scripters and programmers in that environment. Then HTML came along, which was more of the same thing. Any old joe can write HTML, but real programmers use C++.
In 2003, however, the difference between scripting languages and programming languages is not so clear cut. C can be used to script the CGI that holds up a simple website, and perl can be used for writing programs.
Is Java a scripting language? It has constraints similar to that of any other programming language, but technically runs on top of a virtual machine and is thus a scripting language. Scripting languages will continue to become more powerful and more difficult to use, and this will further blur the line. With perl even gaining the ability to be a compiled language, it's often hard to tell a programming language from a scripting language.
In this way, how can you really look down on a scripter because of the choice of programming language when C and perl are almost interchangeable for many tasks?
In the long run, we're all dead.
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.
The problem is programmers that are insecure because they aren't confident in their ability to move between languages as needed. Programmers usually have their favorite tools for any given job but the ones that get really nasty are the programmers that are only comfortable with the few tools they use.
For me I'm pretty confident in my ability so I can move between any language that exists or is just invented as the job goes along (happens sometimes) so I don't especially get snotty. Python is one of my favorites but it certainly isn't perfect. I have done a lot in PHP but have grown unhappy with it for large projects. It is good for small to medium sized projects. Java is okay for programs that are going to run on servers with lots of memory and that won't be restarting the program often but is to heavy for most of the things I do. C/C++/Asm are good for low level stuff that needs to be fast but IMO should not be used for the bulk of things they get used for.
At what price learning? At what cost wisdom? The price is a man's peace of mind, and the cost is his life.
Java is made for applications. PHP is made for dynamic web pages. I think, by default, this gives PHP an extra layer of planning that you have to do, and restricts you to a different set of options. And for your game, I think PHP was a far better choice.
Remember Barren Realms Elite? If I wasn't so lazy I'd be about half done with my PHP rip-off of it.
Whale
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 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.
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.
On the other hand, I've seen C and C++ programmers come up with the most amazingly fucked up atrocities to get around the strongly-typed nature of those languages, to solve a problem that could have been clearly and elegantly solved with a dynamically-typed language. So you are correct to a certain extent, but compile-tile checking can sometimes cause more problems than it solves.
By the way, modern scripting languages now have unit testing frameworks, which addresses your excellent point of partitioning the work up and testing each bit.
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.
This "either or" stance is false. Scripting *is* programming and to be a decent programmer you need to know both a compiled language and a scripting language. Programmers who know only one language can not be called professional programmers in a true sense of the word (BTW in old days one needs to know assembler and a high level language to be called a professional programmer; Programmers who can program, say in only Fortran, or PL/1 were often called suckers ;-)
Moreover in complex systems it's much better to use both.
The main advantage of a scripting language it that it permits writing five or more times less lines of code. For a large system this is a tremendously important consideration. Many projects died just because the codebase size exceed a reasonable limit and thus IQ of the development team and the resources of the organization to maintain it.
When you have that much less code, it's not only easier and cheaper to maintain the codebase, the design itself can be more better. This is the same consideration that eventually killed usage of assembler language for writing compilers. Moreover the time to create the first version and cost of the development can be considerable less. That's why scripting implementation is often done as a prototyping phaze.
But for most complex projects the development team can benefit from using both scriptnng and a regualar compiled language from the very beginning to the very end of the development cycle and coding different parts of the system in the most appropriate language
In this case you need a scripting language that links well with your base compiled implementation language (for example TCL+C ) but that gives a lot of possibilities to structure the system more flexibly.
One important possibility is to have an internal scripting language for the system that you are developing. That is an important advantage for a large class of systems.
All-in-all scripting language is more important on the initial, exploratory part of the system life cycle. As the system became more mature and design stabilize, it might make sense to rewhite some parts of the system in a high level language. If speed is of primary importance all the system can be rewritten, but this is a pretty extreme and rare case.
One can consider Java as a language sitting between two chairs: it's too verbose and low level to compete with scripting languages and it's too slow and inflexible to compete with classic compiled languages like C and C++.
But still using Java is a compromise that helps to achieve some benefits of scripting language and some benefits of compiled languages while using a single language. The main problem is that you often need to write 5-10 times more lines of codes in Java and that's a huge cost difference.
See http://www.softpanorama.org/Scripting/index.shtml for more inforamtion
- Nikolai Bezroukov
OK, so a big question is what is the difference between scripts and programs? To me, a script is something you just write. A program is something you design, then write. I don't really care what language its in. A 10 line Java program that does some simple operation on args is a script. A huge multi-module Perl file/script is a program. There are other terms to differentiate what most people are talking about, its simply compiled vs. interpreted.
Re: The Main Topic
This basically means the difference is that programmers can script but scripters can't program. *ducks* Seriously, if you are writing complex enterprise-critical applications in javascript, you aren't a scripter, you are a programmer (who probably made a bad language choice). Conversely it you are just running search and replace on open source C code to suit some minor business requirement and compiling it, you aren't a programmer.
This is not the greatest sig in the world, this is just a tribute.
"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
Yes!
There was a task:
There was a file with ~600 URL links with real media. A task was to check those URLs.
My TCL solution took me about an hour and was accepted.
Another persons' Java solution took 2 weeks of his time and was not debugged at all.
that other person vas VERY experienced in Java and
wrote a lot of projects in it.
Would be to say that 'scripting' is a subset of 'programming'.
autopr0n is like, down and stuff.
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 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.
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."
Hmm...
In perl:
open (TEST, test);
while (<TEST>) { print }
close();
Now java:
BufferedReader r = new BufferedReader(new FileReader(test));
int c;
while ((c = r.read()) != -1)
System.out.write(c);
r.close();
And C, just for fun:
int c;
FILE *of = fopen(test, r);
while ((c = getc(of)) != EOF)
putchar(c);
fclose(of);
I disagree with you about home-grown software being an asset.
At the end of the day, an asset is something that creates money. If you're in the business of providing scientific, engineering, or financial products or solutions, then software can be an asset. If you're in the business of making widgets, software is an expense.
It's not the software that is the asset, it's the business process. A winning business process can be developed and implemented using shrink-wrap software. Sure your competitor can buy the same software as you, but can they implement it the same way you do?
Professional oboe players cut their own reeds, because they can't get off the shelf reeds that will sound as good. They don't, however, make their own instruments. Their asset is their ability to produce beautiful music, not perfect reeds.
Successful craftsmen make their own tools, because they can't get off the shelf tools that do what they need. They don't, however, dig up their own iron ore. Their asset is their ability to build fine cabinets and tables, not home-made tools.
Profitable manufacturers configure their shrink-wrap ERP systems to meet their needs, often using only a small subset of available modules. They don't write their own ERP systems, they make widgets. Their asset is their configuration of that system, or, in other words, their business process, not a piece of software.
Large corporate development teams are on their way out. Ten years from now, the majority of programming done outside the software industry will be scripting, and not coding. Scripting is all about solving the problem while minimizing expenses, and that, my friend, is the asset.
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.
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.
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.
A programmer is someone who has (in)formal education in information sciences including common data structures, design patterns, algorithm, and algorithmic analysis.
With the above skills, one should be able to master any language--compiled or interpretted. Often, the term "scripter" is used to describe someone without an understanding of the above who limits themselves to scripting languages.
Obviously, the later is inferior to the former. Most people tend to favor a language but even if that's a scripting language, that doesn't make one a "scripter."
Now as to whether a scripting language could solve problems more effectively, that's simply not relevant. The largest cost in code development is maintaining and expanding existing code bases. Therefore, it is more economical to use languages that are more widely known.
More people know Java or C++ than python or perl (at least, in enough capacity to do something useful). Therefore, in most circumstances, they are preferrable.
int func(int a);
func((b += 3, b));
This is why I hate Slashdot. I've never contracted for the US government, so I take your rather interesting comments on that as fact. I have no reason to doubt them, and they seem intelligent and observant. But then you start in on Perl and start pulling assertions out of your ass. And anyone who's reading this and doesn't know Perl well will likely just take your assertions as facts, due to how your earlier statements on government contracting seem authoritative, and you communicate your (mistaken) Perl oppinions as fact, as if "no one reasonable" can disagree with them. And your comment is rated a 5, so some pointy headed boss who's reading this flamewar because he's wondering what the difference between "scripting" and "coding" is is going to see "Perl is not an appropriate choice of language for production systems" and see your 5 rating and think it's a fact.
But it is a LIE.
I have to chime in here. I've been programming in C for 15 years, Perl for 13 years and C++ for 10 years. Consistently, I've found that Perl takes much less time and effort to program, because it encourages coding at a higher level of abstraction.
Note that I'm not talking about the rich CPAN library of modules you can leverage. (Java isn't the only language with a rich API library available.) I'm talking about new code, not slapping together API calls.
I remember an occasion (about 11 years ago) where I was wrestling with a 20-page COBOL program designed to export data from native COBOL files into flat ASCII text files to be imported into another system. This COBOL program was very slow and kept failing randomly. I could have spent weeks trying to fix this program, but I didn't. Instead, I spent an hour or two analyzing the data format. Before long, I understood the string format and the BCD-encoded number format used by that COBOL compiler, and determined the field layout in the binary data records. Armed with this knowledge, I wrote a Perl script to export the COBOL data into flat files.
The Perl script was literally around 8-10 lines of code -- the "unpack" line took the most effort, because all that data analysis went primarily into that one line of code. If I recall correctly, there was also a line or two that finished decoding numbers. There was a print statement to output the decoded records as flat ASCII data, and a read loop around the whole thing. It took VERY little code, and most of the effort was analyzing the data format. Writing and debugging the actual code took somewhere between 10-30 minutes beyond the time spent on data analysis.
This Perl script was bug-free when I finished -- it exported all data records correctly, and was even able to export the record(s) which caused the COBOL program to crash. Moreover, it converted the entire data file in 1-3 minutes, while the COBOL program took several hours to reach the point where it crashed about halfway through. (This was on 386 machines at the time.)
Now, some people would look at the Perl script, see that it's only a few lines of code in a "scripting" language and conclude that it's not "real programming". That's bullshit. Real programming is about problem solving, not the amount of effort expended. As a programmer, I'll choose the best tool for the job, instead of trying to make one tool (C, C++, Java, etc.) fit every job.
The same people who would disdain that Perl script would look at that 20-page COBOL program (i.e. >1000 lines of code) and say that was "real programming". It sure took someone a lot more time than I spent on the Perl script, and it looks like a more impressive piece of code to a manager, but both programs solved the same problem. To claim that one solution is more "real" than another is ludicrous.
Moreover, the Perl program solved the problem better -- it was literally about 1/100 of the size (in terms of lines of code), ran about 100-300 times faster on the same data, and it was more robust (the COBOL program crashed on certain records, the Perl script didn't). By any useful metric, the Perl code was easily 100 times better. (Ironic, given that the COBOL program was handling its native data formats, while Perl had to decode a foreign data format!) The COBOL program could be considered better for the programmer only in terms of politics. It's a lot of work (keeping busy is good for job security) and it's complex enough to impress the non-technical bosses that usually pay the bills, while the Perl code makes this programming stuff look easy by comparison.
The main reason my boss was impressed with this Perl script was that I had the COBOL program in hand as a baseline for comparison, so he could objectively see that my code was a fraction of the size, orders of magnitude faster, and that it didn't crash when the COBOL program did. Without that COBOL program for comparison (which someone else wrote), my Perl script probably would have looked rather utilitarian. (Which it was, actually!)
People often believe that I think Perl is the best solution for every problem. That's not actually true, but often time is of the essence, and when optimizing programmer time is a top priority (which is usually is these days), Perl often wins hands-down as the most effective tool. Why spend a few days or weeks writing something in Java or C++ when the same problem can be solved with Perl in a few minutes or hours? With Perl, I can be off to solving the next problem much sooner, which is important these days, when TODO lists always seem to grow faster than items can be checked off. C++ may be faster at runtime, but it takes longer to write the code, and often the added runtime performance isn't critical.
Perl is a real programming language, and an excellent general-purpose language for many tasks, especially backend processing. Good Perl code isn't cryptic or hard to maintain. If anything, it's easier to maintain because you don't lose sight of the forest for the trees. However, to maintain it you have to know Perl. If the existing developers don't have the Perl skills, isn't that what training is for?
Deven
"Simple things should be simple, and complex things should be possible." - Alan Kay