Cyber Surfer wrote:
> With a mighty <334E8E59.6AFD@nospan.netright.com>,
> email@example.com uttered these wise words...
> > Sorry, But I'm a developer, and I picked my development language,
> > enviornemnt and tools, all by my lonesome.
> Good for you! My employer picked VB, Java, and C++. I'm currently
> compromising, by using Java. My first choice is Lisp, but it isn't on
> the list. Nor is Tcl, for the same reasons.
> I don't think that this is unusual, but please let me know if it is.
Lots of programmers find themselves constrained by the employer's choice
of language. A choice which is frequently insane and regrettable.
In case anyone wonders out there how employers think, I'll give myself
as an example.
We are a real-time trading organization with a lot of technology
leverage and a lot of programming chores which need to be done on the
fly. But we also carry out very high performance scientific
computations. I happen to be the guy who gets to pick the languages, and
the programmers report to me. I also happen to be the guy who develops
the high performance scientific computations, so there are research
types (who _think_ they can write code, but, uh, well, ...right). The
research types also report to me.
So if I felt like it, I could have everyone program in GOTRAN II.
But, since I'm trying to make things go, I don't pick the languages, I
_suggest_ them. Like, a couple years ago I thought it would be good to
see if Tcl/TK/expect was a good choice, so I had a programmer learn it
and decide if it was useful. It turned out to be much better than C++
(which was his original idea) so he uses Tcl/TK/expect for our entire
trading system interface. We still have some stuff in C, and some shell
scripts, but Tcl/TK/expect basically took over the user interface world.
In the research side, we use S, APL, C, and Fortran. It's a lot better
for me to have the high-priced researchers doing research instead of
learning a new language, so we pretty much let things go all over the
place in research. But when we put stuff into production, we have to cut
the choice down a little. We generally have to re-implement it anyway
(and this turns out to be a _good_ thing more than a _bad_ thing) so
it's not a problem.
As a result, we maintain about 10K or 20K lines or code to do work
similar to that which at one of my previous firms took close to 1M lines
of straight C.
So do I have a "big" project? Except for the number of lines of code,
_yes_, especially since I've seen this type of stuff take close to 1M
lines of C. But by creative and flexible choice of language, we have to
maintain only about 2% of that amount of code, and better yet, only
about half of our code is mission-critical.
So when you wonder if a language "scales" worry more about how the
project might not have to scale in the right choice of language.
Now at the moment, we're looking at whether or not we can consolidate
some of our development by finding a language which can support more of
our common needs between research and production, and among other
candidates, Python with Numerical Extensions is the reason I participate
in this newsgroup. I started a few months ago, and about three of us are
looking into this possibility. I expect it will be another three or four
months before we really know if Python is a piece of the puzzle for our
future, and this will be apparent more from if the people who are
already doing the work in other languages choose to defect to Python
more than anything else.
This approach has worked out pretty well, and I would recommend it to