"James Eshelman" <[email protected]> writes: > Following the thread below made me wonder a bit if I'm living in a world > different from many of the posters on this list. I've worked at a dozen > places or so over past 15 years ( I contract a lot) and at almost every one > the choice of language for the main work to be done (as well as all the > other principal tools of the trade) was made by others before I arrived. In > order to work in Perl I look first for jobs that are to be done in Perl. I > have almost never had the luxury of choosing the *principal language* or > other tools to be used to complete the main task at hand. In my experience > changes in primary languages and toolsets come about either (1) Because a > group of developers sees a better choice and makes a concerted effort (read > sell job) *as a group* to bring about the change. (2) Management somewhere > up the chain dictates a change. Individual developers able to choose on > their own what language they'd like to use for the next major project almost > never happens where I live. What do others see?
Where I work, the original founders sought out some senior developers they had heard of by reputation to develop their idea. Those developers chose the language and platform, I guess based on what they had the most experience using: C++/MFC/COM initially, some .NET later. They were pretty pro-MS, one guy even asked me to sign a petition against the justice department suing them for antitrust. Maybe as much as anyone, it was the editors of MSDN magazine and MS's marketing department that chose our languages. Btw, if anyone ever tells you Perl is weird, point out C++/CLI to them. Perl was in the mix too though. Even among these MS shop people, it's the first thought anytime someone wants something quick and temporary to fiddle with the format of an incoming flat file or for processing XML where linking to the main program isn't necessary. But for some reason we've never embedded it in our main programs or did anything really serious with it. I think that was a mistake in a couple of ways. For instance, I think we could have offered Perl as a second embedded scripting language for our product along with VBScript and gotten reasonable acceptance with it (but not Python, Lua, Tcl, Scheme or other good choices, just because of what our users are likely to be familiar with). But what do we do now with the MS people thinking VBScript must go away and everyone must use .NET? There are no real options that are sensible for the sort of user who would script our stuff. IronPython might sound reasonable to some of you, but to the people I'm thinking about Python is really weird and obscure. They don't even want to know about it. Perl I think is less like that. It's all over the place and managers are comfortable with it. Maybe they wouldn't want it as much as VBScript, but they'd prefer it to making very novice scripters (not really scripters or programmers at all, mostly they do copy and paste hack jobs) learn the .NET class library. That's a different pay grade, the way these places work. -- Mike Small [email protected] _______________________________________________ Boston-pm mailing list [email protected] http://mail.pm.org/mailman/listinfo/boston-pm
