A few years ago, I was one of those elitists that said people who didn't code directly in C had weak minds. Then I learned Perl, and discovered that fluently programming in Perl can be just as intellectually satisfying as C or ASM. I was delighted when I finally understood the Schwartzian Transform. My mouth hit the floor when I saw this solution (external link) for creating an ASCII Cantor set.

So, I think the solution to low-level elitism is to show off some of the amazing solutions that can be developed with high-level concepts.

----
I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
-- Schemer

Note: All code is untested, unless otherwise stated

I think you may be pleasantly surprised by the 'real' world. There are management types which actually possess a reasonable amount of clue. As for your programming classes, and classes in general, I would expect some degree of resistance to addressing off topic material. The purpose of a C++ class is to teach C++, so from a learning standpoint using the 'non optimal' tool isn't much of an issue since the goal is to learn C++ and not to program a CGI calandar handler application.

If you were in a Perl class you might be able to get away with a bit of Inline::C though...

Also, when you interview you can get a feel for the general clueness of your potential supervisor and also a feel for the culture where you are applying, so you can make the decision with that information properly factored in. In the current job market though, one may need to compromise on the culture a bit, but I would be reluctant to hire on into a clue-free environment in any case.

You may also consider inertia when you are interviewing potential employers. For example, if all of their current production code is in one particular language, that will be unlikely to change in the near future, whereas, a company with different languages in use for different purposes, or in different areas, will probably be easier to use the most favored tool for any given project.

I disagree. The business environments that I work with (see my homenode for a clue) are rife with scripting languages - Java, LotusScript, (whatever Windows Scripting Host uses), JavaScript and ever so teensy bits of perl. But then I suppose it makes difference what sorts of things you are developing. I build business applications using Lotus Domino for use within a company - some of my peers write Java code for the web server.

There are barely any programmers here (that I'm aware of) that are even marginally fluent in C or C++. I happen to like C++ only because Domino has a particularly nice C++ API. Beyond that... eh. Toss it.

That's been going on for ages and transcends programming. Yes, it's elitist bullshit. Yes, people fear what they don't know. Yes, there are technical improvements we could implement to change this. Yes, people are working on them. Yes, everything will be fine. Yes, you may go about your business.

Then again, we could always use more Perl Advocacy! (and yes, I did look at the link :)

Well, IME you will plenty of this in the workforce, but perhaps not for the reasons you think. Oh, I can't deny that you will almost certainly find your share of managers who force people to program in a certain language just because it's their favorite, but remember that choice of technology (by which I mean to encompass general architecture, data storage, operating system, and bunch of other things as well as programming language) is usually a major decision for a company. And, in most cases, it should be. It's short-sighted for a company to let an individual pick how to implement a solution that they may have to support, maintain, and enhance for years to come. So in many cases the programming language (and a lot of other things) is going to be chosen for you before the project ever starts.

OTOH, you may run into many cases where the point is to get the job done, and the choice of programming language isn't a big deal. For instance, the sales team needs some numbers pulled out of the database and jammed into a spreadsheet: they don't care if you use Acess and VB, or DBI and Spreadsheet::WriteExcel as long as they get their numbers. In these cases, you do get to make your pick, and it may impact how others view your performance (hopefully for the better <s>).

My experience has been maybe 60/40 with the slight edge going to having the language chosen for me. (YMMV, naturally.) Don't get bummed about those, though. Try to look at them as opportunities to learn new things (even if what you learn are very good reasons why you never want to use X again), and wait for the other ones to come along.

HTH.

I even used to feel sort of the same way before I knew perl and was still in school. It came from the difficulty of distributing the programs I wrote. If I wrote a program in C, all I had to do was compile it and email it to my friend or a relative, then they could run it. But if it was in perl they would have to download and install perl which would be a big hassle if they weren't technically competent. Therefore when developing programs that other people would use I would stick with languages that I could compile to binary. Now I know enough perl that I can whip out a complex program pretty quickly so why would I use anything else if I just want to get the job done?

I think it's a real shame that people frown upon scripting languages. They can accomplish so much in such a short period of time. But luckily so far, the most technically knowledgeable people I've met have considered them full-fledged programming languages and thought highly of them.

Most companies end up using the best tool for the job, even if it's not the one you , as the developer, would have selected. TMTOWTDI applies to making this sort of technical selection as much as it does to programming perl. Few hands-on technical people have very much of the big-picture perspective. As such, they might make the choice of best tool based on an overly narrow point of view. Some might even make the choice based on personal preference - talk about elitist.

In companies with knowledgable technical management, this sort of decision making can generally been done on mostly technical grounds. Then, it may fall to you to do a little local advocacy. But don't throw in the towel if it doesn't go you way this time - or next. Try and gain an understanding of the non-technical factors that influence technology choices and ask yourself if you think those are justified. If so, adapt your viewpoint to fit your environment. If not, strive to change the environment. If neither is an option, then you might not be a good fit with that organization.

I have a friend who is a brilliant System's Architect. He always approached his work from the perspective of trying to help the company make the best technology decisions. Yet he was also pragmatic, and a realist. He came in with a 5-year plan. If he were not able to move the company far enough in what he felt passionately was the right direction, then he would need to seek a more enlightened employer. Sadly he did leave to go elsewhere, but those of us left behind are still reaping the benefits of those cases where his view won the day. That's where we pick up the torch.

------
We are the carpenters and bricklayers of the Information Age.

Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.

The only definition I could personally come up with for "scripting language" that C doesn't meet is "a language where a single line of code is interpreted and executed immediately". However, Perl also does not meet this definition (for that matter, neither does Python, Java, VB, or C#). AFAIK, the only true scripting languages left in common use are *nix shell scripts and the equivilents for other OSes (DOS batch scripts, etc.). Perhaps JavaScript, but I haven't dug into much JavaScript, so I don't know for sure. Intrestingly, you could might be able to fit ASM under this definition (since there is (usually) a 1:1 corrspondance between the ASM and the raw machine code).

Defining it as "a simplistic language" might work, but that statement is so vague as to be useless as a working definition. With the right definition of "simple", you could still probably fit ASM in as a "scripting language".

"Dynamically-typed language" might work as a definition, but I doubt you could get most programmers to go along with it. You could still probably sneak ASM in there (since you'd be manipulating the memory at a low-level, you can make it any "type" that you want). For that matter, you could probably program a few libraries to come up with a dynamically-typed version of C (in fact, I know you can, since perl itself does exactly that).

How about "a language which can be compiled directly to machine code without an intermediary interpreter"? This is talking about the details of how the language is implemented, not with how the programmer actually uses the language. Ways exist to compile Perl without an interpeter (they might even work someday :). Ways exist to run C code through an interpreter (often used to shorten the debug cycle). Would machine code suddenly become a "scripting language" just because you ran it on an emulator instead of the actual CPU? VB can be both intrepreted or compiled. So is VB a scripting language or not?

Can anybody come up with a more useful definition?

----
I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
-- Schemer

Note: All code is untested, unless otherwise stated

Nope, you've just about covered the problem.

I prefer the term "dynamic language" anyway. The type system is flexible, you've a lot of power at run time, and you've access to some type of eval.

My point exactly! Perl may have come from the world of purely interpreted scripting languages (such as awk and sed), but it went to a place that even C++ dares not go. Because of that, it has gone beyond what most other languages can do. Perl6 will be a true 4G language, where C++ is a 3G and Java or Perl are 3.5G languages (in different ways).

------
We are the carpenters and bricklayers of the Information Age.

Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.

The rest(most) of the managers out there however, like to intimately dictate what stylish/buzzwordish/obviously better/gave a better kickback, tool to use in every case.

I think this is indicative of most of the management I've seen over the last decade. To prove the point, I think Sun knew who they were really selling to.

I have to give the guys at Sun credit. Those are some smart mofo's. They created Java and made a "compiler" for it. Does it compile to machine code? No. It compiles to something that still needs to be interpreted. Did everybody buy into it. Hell Yea? Is it expensive? God Almight, does it cost money. Make any sence? Nope. Is it even a "fast" language, development or execute wise.... I say No (some might disagree)

I got lucky for the last 3 years and had the 1st type of manager. I get stuff done, he looks good, I look good. Does anybody even know the work is done in perl. Nope. Does anybody really care. Nope.

As for colleges, decisions on what languages to teach seem to be dictated by the same retarded facilities in most companies. Someone, somewhere, who is "important", and lacks the large knowledge base which should be required, makes the decision on what will and won't be taught. </rant>

Please keep in mind, this is only an opinion. It's all rant because I've been less happy at work lately.

Sincerely,
An old time C programmer who like the pain
Smiles

PS. I don't miss waking up from drooling on my keyboard at two in the morning because I was trying to debug a large C program. I work about 6 hours a day 5 days a week and I intend to keep it that way, unless I start working for myself ;)

The bias against scripting languages is really just a bias against change. Change is expensive and painful. Having eveyone code in their favorite language results in chaos. Change can and does happen, no one used Java seriously 5 years ago. Java might be the bridge that brings people to Perl/Python/Ruby by demonstrating that CPUs are super fast and coding in C is going the way of coding in ASM (use it when you have to, and no more). You might like perl better than X, but companies have standards because it keeps their costs down. Perl has a large user base but it is still easier to find candidates that already know industrial C++ or Java.

That said, some of the complaints against C|C++|Java above could be applied to perl (OK, not the its-too-verbose one). Consider that it isn't possible to write an obfu in python. This is a good thing. Perl6 better become reality soonish (it addresses most of the warts of coding large scale apps in perl) or Python is going to eat its lunch. Ruby has an outside chance of doing the same, but misses the mark IMO.

Note, I'm just talking about apps here b/c the question was really about large scale development. Perl's sed and awk heritage make it unbeatable for text file manipulation, sys admin tasks, Makefile helpers, etc.

-jackdied

I guess in many cases it really depends on whether the people in your workplace have enough programming experience and/or skills to actually have an opinion. There were two guys on the floor with programming experience and both of us had the idea of automating a few of the 80,000,000. tasks that were just copying information from one database system to another.

To make a long story endless, the department management (through our self-promotion) saw that we were reducing the call times by reducing the amount of typing and gave us the go-ahead to expand our little projects. The problem was that we were pretty much at the limits of what we could do with the tools I had at hand. These were severely limited due to the IT department's policy of having an iron fist around the software on our PCs (even though many of the people there knew more about our Win2k systems than the IT guys did). I was using JavaScript as an input parser (cut and paste), grabbing useful bits of information and reformatting them so our other software could generate more useful information for the techs. The other guy was using VBScript to write macros to generate reports for management. I asked that they install Perl on my machine so I could do more more quickly. Once our managers made the request to IT, my end was put pretty much on hold because they didn't want to put any new software on our PCs. The reason: They didn't trust third-party software to not crash the one machine I needed it on.

I've switched to the first person singular here because the other guy continued to use VBScript and got everything he requested and was promoted to another department so he could write Excel macros that color-highlighted QA spreadheets. The IT department had just enough knowledge to have a prejudice against anything that wasn't an MS product, whereas the department managers were happy to use whatever gave them the best results. Of course, what should I have expected? The company was owned by a MS exec.

--
Allolex