Slashdot Mirror
Does Company-Wide Language "Standardization" Work?
RMX asks: "In our company, we're currently going through the debate of standardizing on a computer language for our next set of products. The pro-standardization guys say that a single language (like Java) will save everyone time. The anti-standardization guys are advocating a mixed environment (of languages like Python, Ruby, and C#), and argue that the whole discussion is as silly as a manufacturing firm standardizing on screwdrivers for all their screw/nail/glue fastening needs. Have any of your companies standardized on a language? How well did it go?"
Problems and needs are naturally occurring things.
... well, let's just say it won't be long before a problem or need comes along that the standard doesn't fit.
They take on unforeseen forms with non-standard characteristics. If your tool can't solve the problem or satisfy the need, you build a new tool that does. It's the human way.
Likewise, your company can standardize methodologies and practices all it wants. But should they ever standardize the tools they use to solve problems
And then someone might be tempted to work hard at trying to make your standard fix it and work. They might spend hours re-inventing the wheel. And what will that get them?
Why, the ability to say, "Yep, and we did it all with one language."
The customer doesn't care how a solution is created. They care that it works and meets their requirements. Rarely have I seen requirements that read "... and it must all be done in the same language."
I am a computer programmer. I make computing devices do what I want. I will use any tool at my disposal, to hell with my employer's proposed "beneficial" restrictions.
In my dictionary, fatalism is the inability to cope with change. Adapt or fail. I am required to adapt to each new language I learn and I hope I never get rusty at that. Confining employees to one language does just that, it gives them a false sense of security and teaches them to think inside their box.
My work here is dung.
Among my collegues we discussed this about a year ago. After doing some performance tests and after trying to write "problematic" pieces of code in some other languages, we dropped the standardisation idea. You either end up with bad performance or some long bizzare code (when you have problems with translation). There are also times where interpreted/scripting languages are of much higher value. Naturally you shouldnt end up using everything...
There are a few languages groups:
Special: Sql, Fortran, ASM
Brute force: C,C++
Object: C++, Py, Java, Ruby, Lua
Scripting: Perl, PHP, asp
High level: Haskel, LISP
As Python, Ruby, Lua are all the same and closely related to Java I definitely wouldnt use all of them. You might be well of with one, maximally two from each of the groups you use (appart from the special group:)).
That's my point of view being a person solving a very wide range of problems. But if you just write stuff that doesnt have much inovation (i.e. basic desktop apps.), a single language might suite well enough.
Comment removed based on user account deletion
Let everyone code in their own .NET language, and let everyone use everyones assemblies.
Standarize, but leave the door open when its justified ... For example, if a system is going to use Microsoft tools (like active directory), leave the door open to use things like .NET tools... but in general I think is fine to set Java as a standard for legacy systems.
"We all know Linux is great...it does infinite loops in 5 seconds." -- Linus
I remember reading a post here about catapiller using C as a standard language. Problem is they use unix scripting c rather than bash or perl because its the standard??
Tell me how much time is saved there?
Its not like its radically different like platforms are in IT environments? The support argument is dumb and each language is better for a particular task.
You can't write shell scripts in java and except the same results in Perl.
I dislike perl for the most part but I am writing an app which uses wget in Unix and perl is the obvious choice. For Ecommerce it would be Java. Each language is differnet and most are similar and can be converted to one type or another faster and cheaper than using one language. You dont need training really to teach an experience c++ programmer java. Some would be required but the argument is mute on support costs as one good programmer can learn another.
http://saveie6.com/
I'm a one man shop, and I could stand to go to just one language. I could see reducing simliar languages (python and ruby maybe?) ..
But, python, java, C and .net can be very different.
-- these are only opinions and they might not be mine.
there is already a standard language for computer programs:
binary
Robertson are the best screwdriver, of course manufacturers should standardize their use!
'nuff said :)
Now, one thing that does need to be standardized is terminology. I'm working on a contract right now for a wireless telco. The hardest part of this project was getting managers from various departments to agree on how this system we're trying to automate is supposed to work, and describe it to me in a way that would allow me to translate it to software. Compounding the proverbial six-blind-men-describing-an-elephant problem was the fact that everybody was using different vocabulary.
The government tried that once. Called the language "Ada". They had a mandate in 1987 that required it. In 1997 they had a change of heart and dropped the mandate.
- real hackers don't have sigs -
This seems to be the worst kind of savings - PHBs and HR depts don't want to actually do any work and they want to prevent anyone else from being effective and efficient. This is the same as the desktop dept saying "everyone" needs the same desktop apps (graphics dept, software dev dept, hardware dev dept, admin staff, etc) - its stupid.
Who wants to parse logs with Java - not me. But wait, I don't want to do anything with Java seeing how people were able to make a 3 wk/2 monkey project take 18 months/12 monkeys, 1.2 million dollars.
Standardizing on one language is not a problem. "The determined Real Programmer can write Fortran programs in any language".
It doesn't matter whether you standardize or not, it depends on having everyones buy in. If standardization is the route you're going, and even one team does their own thing it can ruin it for everyone.
If you're unsure of ALL of the management and business buying into the idea of standardization, and will adhere strictly to it, it will end up being a complete waste of time.
...as silly as a manufacturing firm standardizing on screwdrivers for all their screw/nail/glue fastening needs.
.NET to be adequate for all their screwing needs.
Microsoft itself is finding
"Is this just useless, or is it expensive as well?"
Friends don't help friends install M$ junk.
It will go well with their standardized living-in-mom's-basements and not getting laid.
'nuff said.
The filesystem is the package manager
It can depends on the size of your company. I worked for a fairly small shop that specialized in Java and SQL work, because of that we became known for it in a positive way. It also was very useful because we all had a decent grounding in Java and our constant work in it had all of us improving our own skill sets quite rapidly.
... small shop. In other situations I can see why multiple languages would be more useful than a standardized company one.
But the firm had only 9 geeks, so as I said
If you can, avoid the discussion/meetings/emails.
Firm-wide standardization drives are
a) usually politically driven, and if you voice the wrong opinion you will be disliked.
b) driven by the incompetents - if they could do something profitable, they would be doing that.
c) out of date by the time they are finalized.
There is no upside here because there is no magic standard that will make things better.
Pick one static/strong-typed language like Java or C#, and one "scriptish" language such as PHP, Python, or Perl. Some tasks will be best suited to one or the other.
Table-ized A.I.
I wouldn't want to standardize myself on one single language. I can't imagine an entire company doing it.
If your company specializes in one type of software, then standardizing would probably work out ok if you choose the best language to suit it.
If your company has a lot of variety in what you do, then stardardizing is a bad idea. Each language has strengths and weaknesses. To ignore the weaknesses of a language and force it into a situation is usually possible, but not very efficient.
Would you use php to program an office suite? Would you use c++ for a simple web-script? Don't fall for Sun's PR and try to use java for every situation, unless you only program for 1 kind of situation.
but then we weren't allowed to use SQL or XML anymore!!
Problems and needs are naturally occurring things.
They take on unforeseen forms with non-standard characteristics.
Are you talking about the "known unknowns" and the "unknown unknowns" ????
The language used will depend entirely on bussiness needs, existing infrastructure if anything, breakdown of in-house talent, maturity -- etc. I think you TRY to use a consistent platform/langauge unless it makes sense to do otherwise. Then, you rely on integration techniques like webservices to bridge the gaps.
.net would be the best choice to process those doc files and create the appropriate jar. So, A directory monitor in .net had to be written, then all the reprocessing done, then the jar file must be written, .. all stuff ready to go with our existing java code. And, to date we are still trying to figure out how to get a proper jar file and manifest written in .net.
.net. Difference was that mountains of java code already existed to do most of the work.
.doc coupled with legacy java, mixed with off-the-cuff design decisions = "Do it in .net"
In my current project, for example, we needed to monitor a directory and translate a doc file to an XML/jar file currently being accepted elsewhere. It would have been trivial to use pre-existing java code to do the job -- the directory monitor and an import interface already existed. 20 lines of code tops to do the job.
However, because it HAD to be a doc file, and MS integrates so well with itself, it was ASSUMED that
So, which was better? In my opinion we could have gotten around the doc file problem in java just as easy as the jar file problem in
So, requirements to use
A standardized language has been vetted by an organization like ISO, ANSI or ECMA. A few examples would be ANSI C, ECMA C#, and ANSI Common List, but there are obviously many more. Using one ensures (for the most part) that your application will survive no matter what happens to the specific implementation of the language.
-- null
...but that's not silly at all. Many manufacturing firms do just that.
Use the right tool for the job.
The higher the technology, the sharper that two-edged sword.
Why wouldn't it be more like standardizing on torx vs. phillips head, or standard vs. metric?
We all know that monoculture can be bad. Besides platform uniformity, strict monoculture opens you up for enterprise-wide vulnerability, and even getting people with a similar, closed mindset. But it also provides for the ability to have a common dialogue with one another. It can be a shared jumping-off point. It keeps you from getting screwed when the one guy at the company who knew mindfuck leaves, and nobody else knows how to read his code.
There are costs and benefits to having, and to deviating from, a standard operating environment. Deviations should be allowed, but the deviations shouldn't be up to the developers, they should be weighed by management (who shouldn't be idiots), and risks and benefits weighed.
Business needs shouldn't be determined by developers. Developers tend to believe in nifty hacks. Code monkeys can love the elegance of using nuance in their code, but there's also a reason that they're not in charge. And it's not just because managers are stupid. Processes may be tedious. They may even be a reason for a developer to hate his job, which isn't good for productivity. Knowing 4 languages, and having the business be dependent upon him may be wonderful from his point of view. But having an employee dictate how things will be done can be destructive to the business. Particularly when he leaves the company for another job, and the new Java guy can't do shit with the Ruby and python.
500GB of disk, 5TB of transfer, $5.95/mo
and standardizing on DOS batch files may not have been my best idea, but it did save a lot of time when the answer was "Sorry, this can't be done, ask someone else".
Wrongo! DOS batch script language is Turing Complete, meaning it *can* solve any problem any other programming language can. (However, TC does not guarentee ease or speed in any way.)
Table-ized A.I.
A single language makes each developer easily replacable. You quit, they just hire another Java programmer. If the collection of software you develop with is sufficiently unique (XSLT with extention functions written in both Groovy and Jython on IKVM running under .Net) you can create a position that would be nearly impossible to fill.
On the other hand, having each developer work on projects with their own collection of technologies tends cause the maintainance tasks of those projects go back to the original developer. This is generally a bad thing. Having a developer know that no one will ever see their code gives a temptation to take shortcuts that they wouldn't take others. Even more than code reviews, splitting maintanance across developers encourages quality code. You don't want a co-worker cursing your name as they try to add one minor feature to something you've done. ("F'n Andrew! Why'd he do that!").
Different languages and other technologies have their strengths and weaknesses. If they are chosen based on their strengths and not just their familiarity (let alone out and out prejudice) then their should be productivity gains achived from the choices. Of course, that means that this would increase the ramp up time a new developer needs to be very productive.
So if you have high turnover, you want to get new developers productively quickly (which would imply standardizing on as few languages and technologies as possible) and you want to get projects seen by as many developers as possible before the original developer leaves. (If Andrew is long gone, then "F'n Andrew!" can be an excuse given by the maintainance programmer, even if it is groundless.) If you have a lower turnover, then developers start getting a better feel over which technology choices fit in which business scenarios.
If this standardization is being driven by upper management, they are hoping to turn the developer positions into a cookie cutter role.
http://panela.blog-city.com/python_at_google_greg_ stein__sdforum.htm discusses the fact that Google has three official languages: c++, Java, and Python. It then goes into some detail about the use of Python at Google. It is a worthwhile read.
Lasers Controlled Games!
Standardization will buy you time until your software is outsourced to India. You can let the hackers beat the hell out of it until it gets too expensive to maintain/enhance. Simple rule - do what makes sense. Java for everything does NOT make sense. When I worked for large engineering companies, Java sucked for large-scale systems. On the other hand, it worked well in other areas (e.g. Web-related apps). On a tangent - Hey, Wells Fargo is doing it. One of the tellers that made it up to the top of the software sector made a bundle off that idea. They want Java everywhere. Well, they're getting it everywhere. Looks great at the beginning and looks like crap soon after they begin hacking away at it. Long story short - if you have the right employees/engineers, they could do it with alphabet soup - therefore, let them apply the appropriate tool/language.
Such standardization efforts, while idealistic, are most likely doomed. The reason is that you can never get rid of legacy systems. You will try to train new hires on the 'standard' language and platform, but it is inevitable that they will be tasked at some point at maintaining "that old system that runs such-and-such." You just cannot escape it, unless your company is so small and new and trivial that you have no legacy code at all.
If you want to dig yourself even deeper, ask your standardization club where business logic should go: in the database or in the J2EE bean container or in the JSP pages, etc. I recommend setting up a ring full of mud, strip them to their underwear and let'em go at it. Bet on the fat guy...at least that's how it worked in Stripes.
I'm sure it's good stuff, because their comments make no sense whatsoever.
/etc/init.d in C++? How about a web browser in awk? Maybe an OS kernel in Perl?
Would you write everything in
Each language that exists and is in common use has its strengths and weaknesses. Given a particular job to be done, the strengths of a subset of those languages could well be so great that you'd be a fool to use anything else. Conversely, another subset will have weaknesses that will mean you'll be cursing for months as you try to work around the limitations.
You don't use a hammer to drive in a screw. You don't use a screwdriver to push in a nail. Or a lawn edging tool to cut your meat.
I guarantee you: if your company standardises on one language, and decrees that this language shall be used for every problem forevermore, you'll find that a problem will crop up that is next to impossible to solve with that language. By all means say "The default language is (insert language of choice here), and it shall be used for all tasks unless a compelling argument can be made to the techies as to why an alternative should be used." Just make sure you understand the strengths and weaknesses of whatever language you pick as the default so you don't spend months doing something that could have been done in days with something else.
Stay flexible. You and your company will be spitting chips if you don't.
The main languages where I work are Java, Perl and SQL. One of the benefits of this is that everyone knows them, and we can all work on any system without having to learn a language as well as a codebase. We're even slowly getting rid of our legacy bash shell scripts when they become unmaintainable (Perl does the job nicely, and everyone knows it)
Other languages pop up here and there, but there has to be a damned good reason to take the maintainability hit of another weird language.
What item should I pick to always win in rock, scissors, paper?
BSD is designed. Linux is grown. C++ libs
There are many sides to the issue of standardizing on a language, and not always technical. It depends on the nature of the companies business, number of IT employees, and the type of software developed. On the Pro side: 1. In a small company developing in-house software standardizing can help save employee cost because you don't have to find someone who is skilled in all the languages or have a person for each language. And, everyone can share the work load. 2. Greater skill and efficiency can be developed focusing on one language. 3. Licensing costs are lower with fewer development tools. On the Con Side: 1. It's too late!! There would be a cost to convert existing software to the new standard that is otherwise an unnecessary cost with little business value. If you don't convert the old stuff, then you haven't standardized and won't reap the benefits. 2.You won't be using the best (or better) tool for the task. That can make some projects difficult and needlessly expensive. (write a C# program to copy files?). A hammer doesn't really fix everything. The screw driver analogy is apt. 3. When the standard tool is not the current trend (think COBOL), you'll either have to rewrite everything, become nonstandardized, or be stuck with code few people want to maintain. 4. Much like 3, you won't be able to take advantage of new technology to meet next months needs. 18 months and everything is going to be different.
Any company that has to standardize on one language is asking for trouble; it'll either limit the problems it can solve, or make lots of half-assed solutions to problems better solved in other ways.
Try standardizing on a standard set of languages. With Prolog, Haskell, Perl (and perhaps PHP), C, C++, assembler, experience with shell, you pretty much have the majority of problems you'll ever run into (from bare-metal systems to logic to webpage serving) sown up.
Creative people don't like being restricted to one method anyways. If you don't want your best people to walk, don't choose to standarize on one language.
--
Internet Explorer (n): Another bug -- that is, a feature that can't be turned off -- in Windows.
It might seem a little primitive having to do a whole heap of pen up, pen down, move, and rotate commands to draw a dialog box, but imagine how impressed future employers will be when they see on your resume that you developed an enterprise scale distributed system with it.
Everything starts to look like a nail.
I am always working on several personal projects. I've found that even in my limited uses some tasks are better suited to certain languages/environments.
If it's all about processing numbers and getting output C++ is the way to go for me. If I NEED to do limited data processing and I need a windows GUI, VB or RB are what I use. If I need to develop an app that works on multiple platforms, it's Java.
For the few thousand lines of code that my apps require it's obvious that not every task is suited to one language. I can only extend that logic to include apps with hundreds of thousands of lines of code.
LK
"Hi. This is my friend, Jack Shit, and you don't know him." - Lord Kano
Myself; i generally use 4 languages:
.NET that I can only guarantee will work flawlessly on 50% of the boxes we use; they generally go my way.
Java: End User Applications; web based apps with WebStart (portability between OSes)
PHP: Simple Web Based stuff (mainly mapserver interfaces)
Python (Zope): More complex websites that need integration to survive (can't beat the stack in Zope)
Perl: simple shortcut scripts to parse text into databases. (You can't replace a language meant to parse text as well as perl does; but the learning curve is a pain to get there).
Occasionally i will have a limit placed on the language; but when the numbers are shown for me showing them the cost of me doing the learning curve to say write a gui application in
I've considered this question before; one one hand I've got very much of a "right tool for the job" attitude... on the other hand within a company there is usually the need to move people between projects ocassionally or do code review.
:-P
Recently, I've run into an issue with wanting to work on a co-workers code... which was in C#. I've had some experience with C#, but it was a few years ago and I use C daily. Switching projects is tough enough, but switching syntax and more importantly *mindset* ended up taking too much time to justify for what I wanted, which was just to unofficially take a peek and help out a bit.
The decision depends greatly on the size of your company and your particular situation, of course. The larger your company is, the more standardizing on a language or languages makes sense. The fewer languages you use, the more flexible you will be to move between projects and to share common libraries.
I would suggest standardizing on a single language for all *major projects*, but don't force people to rewrite their shell scripts in Java
"Save everybody time" is the best the pro-standardization folks could come up with? How about: (1) save training and support expenses for multiple sets of tools & languages; (2) specialists in the language & its quirks can benefit the entire enterprose not just the single group; (3) integration between different pieces of software is significantly easier if they're all in the same language; (4) easier to reuse code; and (5) easier to adjust when developers leave.
It's impossible to know whether it's a good idea in your case without knowing a lot more about what your company does, but in general a bad technical decision made for a good business reason is better than a bad business decision made for a good technical reason. The first one will cause you headaches down the road, but the second will make sure there's no road to go down. The key is deciding which decisions are good and which only appear to be good.
Standardization should be a goal not a requirement. When picking the right tool some weighting should be given toward the tool deemed standard. With the extra weighting if the standard tool is not as good as some other tool then the other tool should be used. This prevents the programmer who want to just inflate his resume of pick the flavor of the day language from making a bad decision.
Lawrence Person (lawrencepersonh@gmailh.com (remove all "h"s to mail)
http://www.lawrenceperson.com/
My experience with company-wide standardization of technical details is that there are all kinds of reasons why it seems like a great idea for a while, but then it turns into obsolescence and stagnation. One problem is that users inevitably want to buy packages that IT will have to customize, and the IT dept refuses because of standards. The users hate the 2nd or 3rd best choice that does fit the standard, and the IT people who work on it get blamed for all its shortcomings.
Another problem is personnel rot. You standardize on ColdFusion or ASP/VBScript or whatever, but then the rest of the world keeps moving. The talented creative people who want to learn C# or Ruby or whatever move on. Management replaces them with people who know their standard stuff and nothing else, who do everything one way whether it fits or not. Headhunters start describing your company as "a COBOL shop" or whatever, and you only attract one-dimensional job candidates. The people who stay behind will feel increasingly stuck there by their lack of experience with the cooler newer stuff.
I could go on and on... anyway, if they insist on doing this it might be a good way to get some solid experience, but plan on moving on in a couple years.
Launch a missile and guide it to a target, track a ship's inventory, air traffic control system! What couldn't it do?
My gawd, it combined the best of Fortran, COBOL, assembly language, ALGOL, PL/I and many, many more. (What do you mean there was no "best of" for those languages? Oh, right...)
In my day we had only one real language: binary. Two bits, and one of them was broken. And we were damn lucky to have them!
----------
Any problem can be made unsolvable if there are enough meetings made to discuss it.
The company I work for has offices in Australia, New Zealand and China so we standardized to engrish.
It nearly works but not quite.
When the only tool you have is a hammer, every problem looks like a nail.
It sounds to me like the people who are pushing for standardization only know that one language they want everyone to standardize on. They're not trying to make things easier for EVERYONE, they're just trying to make things easier for themselves.
Anyone who is limited to a single language is essentially incompetent. If they lack the natural curiosity to seek out and experiment with new development tools and languages, then they're pretty much worthless.
I work as a sysadmin, but even I know how to code in C/C++, Java, Perl, Bourne shell scripts and even visual basic. If someone told me I had to "standardize" on just one of the above, I'd KNOW they were either crazy or stupid.
I think you really need to consider finding employment someone else, hopefully someplace where the idiot quotient wasn't quite so high.
Lee
Muslim community leaders warn of backlash from tomorrow morning's terrorist attack.
Exactly!
=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Friends don't let friends enable ecmascript.
Yep. My boss made it fairly clear that such colorful verbage as: "f** you" "____ idiot" "H'vha!" and "Pa'ta' Tratnan!" Was not ok. But saying stupid [something_not_human_here] is fine ( Despite him being a mench and All American[tm]) he speeks impecable Klingon and " Potty mouth. "-However only three other people knew what a shout that sounded like HweeCha, at the top of your lungs ment. (Don't ask how I found out)
If you decide on multiple languages, you can use the .NET framework because all languages that sit on top of it boil down to the single Microsoft Intermediate Language (MSIL) code meaning: .NET runtime is ported.
- classes, methods and algorithms written in one language can be accessed, re-encapsulated, extended, etc from the other languages.
Write a class in VB.NET and access it from C#, write a C# object and extend it using VisualCobol.NET, etc etc.
- MSIL can be ported to other platforms (in the future) provided the full implementation of the
- It promotes code reuse and easy sharing between languages.
Your programmers might be more efficient if they stay in their language of choice (provided there is difference experience within your company).
- The MSIL code supports most of the latest object-oriented concepts (although not aspect-oriented yet) unlike classic VB
Some here would suggest the Mono platform, the open-source version. I don't know enough about its particulars, but I assume it supports the same concepts.
yes, reducing the languages you use in a company reduces complexity, development cost (reusable code bases), and maintenance cost. This is common knowledge.
But if you are a competitor of mine, please disregard this trade secret and litter your organization with as many languages as you can find...and some you can't...and please post your stock symbol.
I personally liked Perl a lot for most of our companies need, until the day till I found that good perl programmers are really hard to find, however, finding decent Java programmers was not that difficult. Not only that, the company could literally hire two Java programers at the cost of one Perl programmer... not that it was ever a concern. The migration of all the systems took over 9 man months. However, for our performance criticial systems, we still rely on good old C. Since the amount of code there is not too much, our company has agreed to stick to it.
A similar scenario where the Java programmers wanted to outlaw all other languages. In my biased opinion, they were afraid they would be out of jobs if anyone got around to comparing their productivity in Java with the productivity of the Perl group.
Two people coding Perl were able to finish a large project in roughly three months. The same amount of time the Java group said they would need to complete the job specification.
I'm not saying Java is useless. But you really have to wonder when people start suggesting you outlaw perfectly good tools ...what are they afraid of?
Untrue. Brainfuck, for example, is Turing complete, but cannot be used to write a webserver because it doesn't have any way of talking to operating system network calls.
Like anything else, the answer's "be sensible" - play to your strengths. If your company uses the "infinite monkeys" model, then standardize on Java.
In general: an adequate coder can handle Java and bodge C++. A good coder can pick up and use any ordinary language in a week or less, and be fluent and experienced within six months. A guru can handle the oddballs, like lisp and haskell, and make them dance.
Do not expose code monkeys to haskell. You'll pop their fuses, leading to expensive lawsuits, etc.
...You seem to be seeing it as a negative, yet standardisation is the Engineers greatest tool; without standardisation, Eli Whitney wouldn't have been able to manufacture weapons fast enough to win the American Civil War; Henry Ford wouldn't have produced a cost effective automobile; Toyota wouldn't be the insanely successful company they are today, of course, they standardised on a method of doing things, not a specific type of tool... Anyway, enough engineering bias, let me try and make a point :)
:) Like everything else in business, there is only one reason to do ANYTHING, you take an action because it yields an overall, objective benefit. Of course, I, personally, take the long view to "overall" and often recommend and sign off on short to mid term pain for long term gain.
Could a layman not ask the question of multiple programming languages being utilised as follows; why do you need to use thirteen different tools to solve the same problem thirteen different times? This is just as foolish... Note I am not talking about solving DIFFERENT problems...
Standardisation is NOT INTENDED as a straight jacket, however it does intend to ensure that faced with the same situation you use the same solution. It is about portability and interoperability, it is about ensuring that if you get hit by a bus an equally competent colleague can pick up where you left off with minimal learning curve. Naturally you should employ process improvement methods after each activity to fine tune the methods!! that goes without saying. Anyway the true Engineer only uses appropriate tools to solve a problem. Sometimes "appropriate" means the tool which is perhaps not the most ideal immediately, but creates the least ongoing burden (for maintenance, interoperability, etc...).
The descision to standardise should be made for one reason only, to IMPROVE your businesses products or processes. If you do not gain from standardising, do not standardise. Likewise, do not resist standardisation just because it is out of your comfort zone, because it makes YOUR life harder even as it yields overall benefits or because you PREFER tool a over tool b. It most certainly not be resisted because it makes your job less secure.
just my $0.02AUD
err!
jak.
Have any of your companies ;-)
This is slashdot, no one here owns a company... but send me an email if you do happen to chance upon a business I own, and I'll make sure our marketing department gets back to you.
standardized on a language? How well did it go?
Over here at DavidHOzAu Pty Ltd, our entire staff consists of one programmer, and our programming standard is that he decides what the company does. We've never encountered any problems with that, productivity remains high, and a bug never lasts for more than a day.
And no, I am not pulling your leg. Honest.
Standardizing on a screwdriver really would be silly. Everybody knows that the best tool for every chore is a Vice-Grip.
at the pharma company I work at. We were all java, C++, LISP, Smalltalkers before. It's been four years now, and it was a wise decision. It's a very adept glue language that has been easy to integrate with other systems, both at the source code and network level. YMMV, and I think perl or ruby both fill this niche well too. We just wanted to have a standard platform for new development, and have been pleasantly surprised that python has been a productive choice for legacy integration and utility tasks as well. We had a requirement recently to integrate with a Java system. I used jython and it took three days, with no curly braces to be seen. We get a lot done every day now, and it's quite motivating.
No, but seriously for which languages has Microsoft written .NET compilers?
And how closely have those compilers implemented the standard?
http://yetanotherpoliticalrant.blogspot.com
The best thing to do is have everyone agree on the code development method, not the specific language. You can always document your design using the same templates - a function is a function is a function, and you should always have an interface description doc as well as something that describes the code's behavior in more abstract terms than what the source provides.
Less is more.
From my point of view it is more important to get the programmers working together, than forcing them together to choose the one and the only language,
.net - ms
.gnu, or else, sun and ms are simply the main distributors, they make the API- and language standards, the free projects are getting close, but ever will be a step behind the distributors, and unfortunatly they do not have the money for getting certified, and this certification is which most customers eye on)
:
;) )
:) )
which is a totally non flexible decission,
for example, if you are in the possesion of a haskel (functional programming) guy, use his skill, use his rapid devellopment skills, but get him to let other
languages/programmers easily interface with his programs through an API
there it is to use standards, but they should be documented well.
The main problem when stuck to the common managed environments is, you are mostly bound to only one distributor,
java - java - sun
C#,.. -
(please do not comment on mono as the solution for every problem, or kaffee, or
But for standardization
javas doc tools are good for automaticly generating interface Docs,
with first hand develloper comments (if he/she made some)
( ok I left out Smalltalk
So you see if you say, "I only need c-something coders" or say to existing
"programmers stick to XYZ-lang", they probably will learn the XYZ language
but they won´t feel comfortable,
while it is a wonderfull idea to standardize on languages, it should remain a beautifull dream, because it would turn out to be a horrible reality, for the programmers, and programmers who don´t feel liked or apreatiated for their work and their skills they used for, they simply won´t give their 100% ( DO NOT SPEAK OF 100+X % please
Both of the extremes of this question lead to disaster. Some languages solve a given problem more concisely than others, but having too many languages can lead to disaster as the context switch effort from one piece of code to another is larger when they are written in different languages. If I was managing a software house, I would mandate that any given project should be done in a language that was already in use in the company, unless there was a compelling reason to do it in another language. In fact choice of language between those already in use should be on the basis of sound reasons. And "It's what I know" or "It's my favourite language" are not compelling. cheers
Think back how many "flavor of the month" languages we've had over the past 50 years. How long do you think it will be before your "standard" language is considered déclassé, and your company has a huge code base that no one wants to work on?
I suspect there's a trade-off. Standardizing on something makes things easier in the short run, but eventually you have an "earthquake" discontinuity and find yourself converting your whole code base to a "modern" language. Avoiding standardization gives you a mish-mash at any given time, but your code base drifts along with what the rest of the world is doing, so you get continuous slips along the fault rather than letting the out-of-synchness build up to the earthquake level.
Sheesh, evil *and* a jerk. -- Jade
There are a few things I could say about standardization:
First of all it means that any developer can work on any project. If you have a developer leave, die or go on holiday their projects are not left in limbo while some other developer gets up to speed. In large shops it might not matter so much, but with a small shop of four or five developers it's a different story.
Maintaining a level of professional proficiency in any language means spending time on a regular basis developing in it. Languages and utilities change all the time, and to keep up takes time. I can't imagine a single developer being proficient in more than three languages. For example, I used to do Delphi, but havn't really done anything in it in a couple of years, so I'm not really in touch with it anymore.
From a business perspective its good to concentrate on being good with one technology rather than being mediocre in several. Learning new languages takes time, and so having standardized on one language means not needing to train new employees in several languages, and also keeps the employment pool wide.
It means you can be clear about which projects you are aiming for, who your clients are, and allows you to concentrate on what you are good at. Obviously you don't want to chose a language which paints you into a corner - it must be flexible, generic, well supported by employee availability, and accepted by clients (and yes, some clients do care).
However, that doesn't mean you stop evaluating the options. Right now we are moving from Java technology towards Python. Our bread and butter is still Java, but Python is giving us a faster more effective way to develop web applications without sacrificing our favorite language features. We even mix languages in projects.
However, unregulated use of languages is not permitted because it would mean having no clear strategy for the future support and maintenance of the project. Moving to python for me means moving all our developers to that technology, and making sure we don't lose the company advantages we built up by using Java.
"they should be weighed by management (who shouldn't be idiots)"
And there lies the problem.
What else can happen when an unstoppable force collides with an immovable object?
This isn't a foreign language, it's a computer language. Especially for business programming, it should be about week and a competent programmer should be able to write decent code with a manual or a web page open.
Most of the code I write is in python or java. But I'm writing a small windows application, and chose C#: I installed the IDE, and I was writing code in a few days, especially with google helping out.
When needed I write C and C++ as well, again not a big deal except it takes a lot more time to get the same amount of work done, but sometimes there's a library you need to link to.
The caveat in all of this is you need to be competent.
If you can get yourself on the "Standardization Committee", you can probably even have REAL fun! Like -- ask stupid questions: how does the language express factorial 10,000? Can I see some sample code? How about implementation of Knuth's Algorithm for sorting tape runs (whatever). How about dynamic programming? Backtracking? Functional programming? OOP support? Report generation from databases. GUI interfacing? Multi-threading?
You get the drift. I am sure that you could generate at least 1,000 pages of samples, criteria, &etc.
Ratboy
Just another "Cubible(sic) Joe" 2 17 3061
me, too!
That's only because nobody has been clever enough to run it through inetd. As soon as someone w/ some more ingenuity than time attacks it, there will be one.
Many tasks are more or less language neutral. For those it's nice to choose a single multipurpose language (like say python).
When you need something specialized you deal with it on a case by case basis.
It clearly benefits code reuse and reduces bugs to have a small rather then large number of languages.
Boris
Unless your company is an ungodly narrow sort of business, you should rule out the use of other languages entirely.
If you're hiring programmers who are totoally hopeless in other languages, you're not getting very smart programmers.
However, it makes oodles of sense to restrict languages for a certain product. That makes everyone on the team interchangable, and it makes it easy to have a place to plop new hires (who know that language).
However, before you build in a product restriction, you should put an out for performance/library reasons. I think it's silly for a shop to standarize on Java/Python, when you quite often need to make a C/C++ JNI/Swig wrapper to get certain tasks done.
At my firm we do a LOT of Python with C++ performance cores. We do some Expect scripts to interact with interactive programs. If we had standardized down to the point we would have used One And Only One language, then we would have one of many suboptimal situations: Standarizing on Expect would have been silly, TCL is not a full featured language. If we had standarized on Python Only, some of the code that needed to run over HUGE datasets would have taken approximately 15 times longer to complete than the C++ core did. The C++ core took HOURS as it was.
If we had standardized on C++, our dev/debug time would have been much much higher. We also would have had to spend more hiring developers (you can get good python code out of an intern. Good C++ doesn't come out of interns often enough to mention).
Standardizing on C++ isn't really standardizing. For a project to really standardize on C++, you have to pick a subset of that colossus and forbid the rest.
--Michael
Want to see every step I took to start my company? http://www.rowdylabs.com/blogs/pitchtothegods
Prove the standardization guys wrong. Show them how inefficent one language can be. Standardize on Intercal.
I work for a multinational software company. We've grown through acquisition, so we're a whole lot of diverse pieces of software and different build systems/source control. We're going through an initiative to consolidate all of our build systems.
Looking at the way it's happening, it's going to be painful. Imagine trying to mine out the data from a bunch of cobbled together build and source-code control systems into one big honkin' one. Every code repository and build mechanism you could think of, using a dizzying amount of different tools, across several micro-organizations, on a bunch of different environments, spanning at least one ocean. I'm scared looking at it because I can't yet tell if the information which is captured in some of these system can be represented efficiently (and useably) into one system.
Forced standardization sounds great on paper, and probably gives the metric-heads something to make graphs from. But in the end, if moving to such a system causes you to lose information (or worse, causes complete re-implementation of code) then certainly in the short run it's done more damage than good. And possibly in the long-run depending on how much archival information was embedded in the systems you scrapped, you could lose a lot of the knowledge in those systems.
The theory that one tool is the solution for everything is highly flawed, IMO. I'm looking forward to seeing how our migration goes over the next few months.
I've deployed stuff in the field, and migrating any legacy system can be a pain in the ass. It's always fraught with data-loss, or no way of capturing those 'exceptions' that nobody ever thinks of up front. And then you're left with highly valuable bits of data there's no place to store, or no way to use later.
There be dragons.
Absolutely yes, standardising one one language is a Good Thing(tm)
Lisp systems did it. Of course lisp is so powerful and flexible nobody would have considered that a restriction.
A language like Java has a number of flaws but it is Good Enough(tm) to standardise on also.
So I say standardise away within reason. Obviously there may be exceptions, but if your primary language you choose is a good one, you should need a damned good reason to leave the standard.
Notice a pattern?
If there are enough people in your organization that this issue actually has to be debated, you might as well start looking for an exit -- the company is doomed to, at best, forever wallow in mediocrity. I'm not exagerating. This type of 'discussion' shows a serious disregard for reason, logic, and a lack of respect for wisdom. It's a serious indication that those spearheading the push have no clue what they should be doing in their roles -- they can't figure out how to do real work that would actually be valuable to the company, so they choose to waste their time on this.
There is something else at play here: whoever is pushing for this doesn't trust their developers to make sane decisions regarding development tools. Maybe that mistrust is warranted, maybe it isn't. Either way, you are screwed.
Now, if you were talking about a 5-man startup, it's almost a sure bet that you are all going to be writing in the same language, and you might even all be using the same IDE. Same if you are working in a small team in a larger organization. But a company-wide push to put all your eggs arbitrarily in one basket? Insane. For one, it means that the company will only attract (or keep) programmers who are not interested in developing new skills. And a programmer who is not interested in keeping their toolset current is generally a very poor programmer.
Smart people don't build monocultures on purpose.
Machine code! Yes, those good old 1's and 0's will solve anything. After all, assembler,C/C++, Perl, Ruby, Python are all built on top of machine code arn't they? All you have to do now is figure out what machine you are building for! (NOT!!) All languages were built for a reason, to abstract the problem domain from the hardware and to express the problem in a language natural for the problem domain. Each language has its place, but what you REALLY need to do is figure out what problem you are trying to solve and then pick the *languages* (yes plural) to fit the problem(s)! Don't pick fortran to solve an need for an AI expert system, likewise don't pick scheme to fix a distributed but otherwise purely numeric computational problem. I stopped counting at 14 languages because I soon found that some pointy haired bosses will expect you to solve all the worlds problems in the language they just heard about, even if its 20 years out of date. Yes, you want to limit the number of languages but you can not bring that number down to '1' just because someone likes that number.
Really? I know both C++ and DOS bs are turing-complete, but why does that make DOS bs C++-complete?
Le français vous intéresse?
Pick Two
One from - Java, C#
One from - Ruby, Python, Perl
It makes perfect sense to standardize on both. Scripting languages will always be more appropriate for text processing and other tasks like validation and system administration.
But, from what I've seen, it is important to standardize an organization on one of each. Letting people go off and just write System X in new technology Y might be enjoyable, but it does end up in a great deal of duplication and expense. For example, one environment I've seen has a great deal of Actionscript, a great deal or Ruby, more Perl than I'd ever want to see, and some J2EE applications. This usually occurs when an organization lacks a sufficient level of oversight over architectural decisions.
Just pray that neither side wins. Writing only Java is as silly as writing in a different language every single day.
------ Tim O'Brien
Your company should standardize around Hindi - the new programming language in India - It is an extremely natural language - you write down your requirements in English (even on paper), send it via e-mail / snail mail to a supercomputer called "India", the "India" machine turns it into Hindi and feeds the information to a cluster of other India machines, known as "Indians" and then these "Indians" break it down into functions, write the code, put it back together, compile and send you the binary - you wont have to worry about what language they code it in!
--------- I have no signature
That is more of an access/portal issue, not a computation issue. If BF can write to files, I would note, then one can use polling for messaging to a web-server with a small driver on the other side. Not pleasent, but T.C. is not about "pleasent".
Table-ized A.I.
Why would it need to? Simply write your brainfuck webserver to talk to standard I/O, and let inetd talk to the operating system network calls. You only need to get your program to speak HTTP (and optionally produce some coherent output in HTML) This is not impossible, just insanely difficult and masochistic.
Waiting for ad.doubleclick.net...
Its wrong to focus on a standard language. Its better to focus on interoperability. Web Services (SOAP over HTTP) seems to be the winner today, with COM ruling the windows world.
Programming languages are lot harder to learn than screwdrivers are, so that analogy is not particularly apt. If you're a well-healed business that can afford to hire for the bulk of your tech team CS graduates or the equivalent who are versed in theory and therefore equipped with the intellectual tools to quickly pick up any language, then you should have no problem supporting a diversity of languages and platforms, and could even leverage their various strengths to get something better than a single platform or language might provide. If you can't hire such a tech team, you're probably better off standardizing on something common like .NET or Java.
Flying is easy, just throw yourself at the ground and miss. -Douglas Adams
From the question, it is hard to ascertain the size of the "company" Below a certain size, standardization is more trouble than the benefits provide. In the middle, standardization probably depends on how willing the developers are. At the top end, where I live, some amount of standardization is a must. With 200 developers in our division alone, being hit with numeroud SOX (SarbOx to some) requirements, a need to implement massive DR plans for our systems, and a wide geographic development distribution that sometimes does not communicate well enough, treating programming languages like tools in a toolbox is unworkable. That said, you can't just quit cold turkey. At our size, you need to define a "strategic" language. In our case, many of our vendors utilize Java and J2EE, so that becomes our strategic language. However, we continue to support some older Win32 client code that demands VB6, and some vendors we use chose .NET, so we have to support that as well. That said, stuff like Python, PHP, Perl, Pascal, etc. must have serious justification before they are used for major development work (Perl is a favorite for the UNIX admins, but they are not considered development staff here)
Yes, there are times when the project gets sub-optimized by being constrained language-wise. Developers will grumble (and I am a senior development resource, BTW), but overall, the cost is less to enforce some standardization. Why?
Cross training/support. The fewer languages, the more bodies we have on staff that know it.
Integration. Not everything can be a web service. Our business users hate us telling them that we need to rewrite that chunk of code because it is in Language A and the rest of the project is in Language B
Development Machine stability: Compilers, IDEs, runtimes, etc., all have to pass through a rigorous testing matrix before they can be loaded on Development machines. Cringe if you want, but SOX and other regulations make those things necessary. Thus, more languages means more money tied to testing and certifying the components on a development box
Coding standards: The fewer languages, the fewer times we have to sanction a team to author standard for that language.
As a developer, I find the "languages as hand-tools" analogy severely lacking. Possibly, treating them like powertools is better. Once I select my Dewalt cordless tools, I am locked into a battery option, saw blades, etc. Some stuff can be bought generically, but I'm not going to go out and buy a Wilwaukee set of cordless tools just because their saw option does a better job on miter cuts. I will figure out a way to make good miters with my Dewalt. If I find myself making miters all day, I might consider buying just the Milwaukee saw, but I know I'll be forking over more bucks for extra chargers, batteries, blades, etc. I will not do that lightly.
I applaud developers who can pick up languages easily and are fluent in many. That said, language prowess does not give the developer license to create a programming Tower of Babel. If a developer can't show that kind of restraint, the company is no longer a good fit for him/her.
In the end, I think 1 is too few languages, but I think > 4 is too many for a large firm. Same goes for editors, compilers, etc. Of course, each company has to weigh the risks against the benefits. I can see a cross-platform developer needing many more compiler options, and there are no doubt firms where performance cannot ever be sub-optimized, so my comments are moot. However, for those who live in a data-processing land where I exist, there is little to gain from switching languages like a playboy switches partners.
but only within certain boundaries. Our company standardizes on a language in each of our different projects. There is also a standardized interface between projects, so we don't have the multiple languages problem.
It gives us flexibility, but also leaves us room to react as needed.
This reminds me my languages class in college...
We had to do the same three projects in 4 different language styles (C, Lisp, Prolog, etc...)
From that we really learned how painful a language can be if it is being forced, and how wonderful they can be when used for what they were designed for.
I've never tried standardizing on a language after the fact, so I don't know how that would work. But I am a firm believer that a common language for the development team is a good thing. Much like a common spoken language for the team is a good thing. It encourages code reuse, sharing, and general system understanding. On the occasions that something in our system is written in another language (we had a few C modules from contractors and third parties), it usually ends up being a mystery system and we accept it with it's behavioral limitations or we end up rewriting it in our own language (which happens to be Perl) so we can tweak it as needed.
Of course we actually do use several languages: perl, SQL, DHTML. But each one covers a very specific, non-overlapping domain. I've tried to stay away from having a second language cover the same need in a different way. It's hard enough to keep everything understood and shared as is.
Cheers.
Greetings.
.Net, depending on problem sub-domain
I work as an architect for one of the largest companies in the world. There have been several attempts at finding the standard language holy grail, and in the end, the strategy that works, is to have a standard language assigned to given problem domains. With that in mind...
* The web site itself is done in Java/JSP/JSTL/etc.
* The business logic is built with PL/SQL
* The scripts that build the site are written in shell, make, m4, Perl
* The QA team gets along marvelously with Python
* The end-user, on-demand digital goods delivery offerings are written
in either Flash or
* Etc.
The policy is to find what's the best tool for a given job, and standardize on that tool. The strategy has worked very well.
My suggestion? The good old "find the right tool for doing a specific job".
Cheers!
Eugene
http://eugeneciurana.com | http://ciurana.eu
Moral: 'The best tool for the job' is not the same thing as 'the best set of tools for all of our jobs'. I suspect most businesses will do best picking one or two languages (static+dynamic works well, like Java/Jython) and sticking to them except in well-justified exception cases (like needing to write a device driver). DBA's and sysadmins will probably have their own collection of scripting languages dictated by their DBMS or OS platform.
The opposite of 'best tool for the job' (often subscribed to by programmers) is the 'one size fits all' advice (often subscribed to by management). It has problems too. If your bias is towards 'best tool', think about (1) overcoming any reluctance you have to learning a new or "rival" platform (2) long-term cost and risk of having an extra platform [it's higher than you think]. If your bias is towards 'fits all', learn more about when language choice it matters and be receptive to dialog on new or alternative tools. (2) avoiding pointless diversity which will cause headaches for future maintainers down the road.
-1, Too Many Layers Of Abstraction
I say yes, select a small set of "standard" languages -- but let me select them:
-- Python for prototyping and in-house analysis
-- Ada for large, long-lasting, and/or critical systems
Yes, I'm serious.
I watch Brit Hume on Fox News
I work for an internet pioneer company that has survived the .com crisis and continues to thrive. However 3 things are golden. Bash, Perl, mason. It is not the quantity of tools you have, but the right swiss army knife. Granted there are times you need a surgical tool for the job. Just keep the pool of tools small and versatile and all will be well.
One tool can't do everything. Too many tools lead to organization problems, etc.
Generally, a small toolbox with good selection of tools is your best bet.
Don't worry to much about it though since office politics will just screw it up anyway.
I've had mixed results with standardizing on a language. All too often it's done purely for the sake of standardizing, with no thought to anything else. Programming languages are tools, and ones being used by a team not just one person. You want to minimize the number of variations in your tools so people don't have to worry about needless vagaries from one tool to another. At the same time, you don't want to standardize so far that you eliminate entire kinds of tools and end up doing the equivalent of trying to use a rock as a hammer because your shop's standardized on screwdrivers and screws for holding things together and so doesn't have hammers (the programming equivalent would be trying to do simple scripting jobs, that'd be 5 lines in Perl or bash, in C++ because that's the language your shop standardized on).
The only times I've seen standardizing languages work is when the first step was to not standardize. The first step in a successful standardization effort will be to ignore languages and instead take stock of what kinds of programs you need to write. Include all those little one-off jobs that you have to do several of every week, eg. the little hack to extract the error messages you're interested in from the logfile. Then, for each kind of program, look at the languages suited to writing that kind of program and see what one your developers are most comfortable with and, just as importantly, what your existing code is written in. An inferior langauge that all your developers know well is superior to a superior language that they're not familiar with, and if you've a large body of code in one language then that language is better than a different language. If several kinds of programs can be served sufficiently well by one language, well and good. If not, well and good too. The goal is to simplify getting the job done, not hamstring yourself with rules not related to getting the job done.
In the Unix world, normally I expect at least 4 standard languages. You'll have shell script (typically sh because so many other tools expect it, but csh is possible), make (because every development environment typically depends on make at some point), another scripting language (Perl, Python, Ruby, etc.) and a "real" programming language (commonly C, C++ or Java, add VB and C# in a Windows environment, others are possible).
Instead of having a company standard language, they should consider a company preferred language, that way if you have a choice, you stick with what most of your people know and in those 10% of cases where it just doesn't make sense to use your preferred language, you use what you have to, instead of trying to make that round peg fit where it doesn't.
The USA's own Department of Defence [sic] tried this. Their attempt at standardisation was called Ada. How many people program in Ada these days? That's right, the fringe minority desperately trying to hold onto their Defence jobs... and the lecturers who taught them.
"We at ACME Corp are going to standardise on concrete cinder blocks as our building material."
It's really as simple as that.
This is what lead engineers, or architects (responsibilities and titles vary by team) are for.
There should be a chief, and he should listen to the opinions of the entire team. Then, using his expertise, wisdom and the input of the team, he/she should make the decision.
In fact, a good architect or lead should have a good instinct for this... it will be highly dependent upon the system architecture, team makeup, etc. If the pieces are easily seperable (say, a c# GUI app that communicates to a ruby-on-rails web service), and most developers on the team know both languages, maybe multiple languages work. On the other hand, if only one or two programmers know ruby (or c#), or you're talking about one app that uses both languages, the situation gets murkier.
I've served as a lead dev / manager for teams in both scenarios. In the past, I developed a large system based on Delphi combined with C++ (several applications), and recently a whole system with C# (again, multiple applications and components). I can say that both are doable, but each was approach was tailored to the requirements of the system.
Where do you rank COBOL in those groups?
While you're answering.. can you think of a better language in which the major actions are:
READ DATA SOURCE
PERFORM CALCULATIONS
WRITE DATA SOURCE.
With data source being.. DB2 (table sizes in the 10M rows+ range), VSAM files (equiv to those DB2 tables) and flat files (text files) of similar size. (Comments comparing VSAM vs Flatfile will be ignored).
I work with mainframes. We use COBOL. If you know of something better to use.. I'm listening. I'll even pass on the suggestion to Management (I'm not kidding. They are looking for alternatives).
We have Java for midrange.. but it does not perform (by cost analysis CPU/Environment costs used and incurred) better against the mainframe running COBOL/Delta/etc.
You have a sick, twisted mind. Please subscribe me to your newsletter.
I hope that this is a joke...?
Seriously.. because.. I've heard similar things said in 'focus meetings' here at work. It's terrible when people have no clue what they are saying.
You have a sick, twisted mind. Please subscribe me to your newsletter.
several companies I've been at have standardized on a single language for "the customer product" (it's always been C or C++) while for strictly internal tools it has always been a free for all -- Mostly Perl but also Python, Expect, TCL and even bourne shell.
Using the "standard language" never seemed to be a problem for us.
Of course my experience is limited to enterprise computing and embedded software (no MS Windows shrink wrap).
A few years ago we have standardized on Java on the client workstations but it simply doesn't work. Whenever an application is converted to Java helpdesk tickets soar up in the sky. Not because of technical reasons, there are almost never any bugs involve. No mostly because users doesn't seem to be happy with Java applications since they don't feel what the users are used to. Even with trying to implement as much of the users complains as possible. Sure the complains slowly die down but not to the level as for none-Java applications.
We are now considering to replace Java with AJAX for the simpler DB oriented applications and C++ for the complex applications, hoping to halve the helpdesk tickets count in the long run. It seems C++ together with the wxWidgets framework produces produces enough good applications which users are happy with.
See http://wyoguide.sf.net/papers/Cross-platform.html
Mod parent up: A rare (for ./) dose of common sense, well written.
Anyone who loves or hates any language, platform, or manufacturer, doesn't know what they're talking about.
I think most programmers would love for there to be one unified language, if for simplicity if nothing else.
.NET is the language abstraction, and the importance to keep this separation. Microsoft also worked to keep the .NET environment 'open commercially' for other companies to create language interfaces for the .NET environment. That is why you can develop in everything from Basic, and Pascal, to Fortran and COBAL in .NET. In a sad way, it is too bad Sun didn't grasp this concept and extend their JAVA sandbox technologies to do the same.
However there is no such thing, and probably never will be. The nature of diversity in what programming is used for mixed with the diverse nature of how each individual thinks dictates that many programming languages will continue to exist.
This is a lot like linguistics and the argument of universal languages to replace native languages. In one aspect it sounds good, and sounds simple, but so much would be lost if this was ever pursed. The culture and diversity of language itself is what breeds creativity.
Creativity in programming is also a strong consideration that companies don't take into account when proposing such ideas. We all think (in process) so differently, that the programming languages we use not only reflect our internal process, but contribute to our creativity.
If you watch companies that know a bit out people and user productivity they tend to go out of their way to even nurture many programming languages, and even encourage their programmers to use the ones they are comfortable with, and play with the other languages when they are looking for creative solutions.
A couple of good examples in the corporate world are Borland and Microsoft.
Borland not only produces many types of languages, but also works to keep them somewhat pure and removed from the other languages. When you are working in Delphi you don't have to think in C++ terms.
Microsoft also appears to get the diversity of language concept, and goes out of their way to nurture many languages for their own developers as well as provide them in commercial Microsoft Development tools.
Even the fundamental concept of something as big as
So if you work in an environment that is considering forcing a common programming language, keep all this in mind when adding your input. Sure one code base would make things simpler, but no language currently exists that does everything or everything well, and then add in the argument that it would severely limit creativity and reduce productivity levels for people that have stronger proficiencies in different languages. Also I would suggest that the company should be more worried about interface structures within the organization, than what programming language it was written in.
Well.. here we are split between COBOL and Java. Management recently felt the need to fire people (as you do.. you know.. let go of 15% of the workforce to keep 'within budget'). Strangely.. we released more Java programmers than COBOL programmers. Why? We need the COBOL programmers. We can always get more Java programmers very easily.. but replacing the COBOL programmers is harder. What University still offers COBOL courses? A lot of our processing is currently done in COBOL, but we are slowly moving everything we can to Java.
You have a sick, twisted mind. Please subscribe me to your newsletter.
What needs to be standardized, then, is not the language per-se, but the rules by which a language is selected. The IF statements. If you read through the standards documents on the IETF's website, you are not looking at a single, all-encompassing rule. You are looking at possibly a few thousand rules, with enough logic behind them to determine which rule applies.
In the case of a company picking a programming language, you probably don't need a few thousand rules. A single side of paper should be more than sufficient to cover all the meaningful languages and the cases they apply in.
Rule 1 might be: "If a more precise rule is not defined, programs should be written to the ANSI dialect of C, revision C-99 with all threading assuming the POSIX threading model and other parallelisms within a single computer assuming OpenMP extensions. Where a more precise rule exists, that rule takes precedence over this default action."
For embedded code in web pages, the rule might be: "Except where a specific project requirement dictates otherwise, embedded code within web pages should be written in PHP, revision PHP-5.1"
For transportable bytecode, you might say: "Web-enabled applications, applications needing to run on clients without installation and applications needing to run on otherwise unsupported platforms should be written in Java and compiled to bytecode using a standard Java SDK version 1.5"
For configuration code, you might say: "Automatic configuration files should be written to the standards specified by Gnu Autoconf and Gnu Automake, using the applicable Gnu M4 macros" (Hey, M4 is a language too!)
You'd then have a few more cases for specific types of work the company does a lot of. This may include additional rules requiring C, but that's fine. You want the specifics in there, so that if you want/need to change the default action, it doesn't screw everything up.
If you're defining standards for languages, I'd also define in the same document some standard coding practices (eg: keep namespaces distinct, if you're using javadoc or something similar then comments should follow javadoc's rules, if you're using a code validator that uses comments to embed commands then state what commands should be used and when, if you're using a SCM - a very good idea - then comments to embed details like revision notes, date, etc, should be included in a standard location, etc.)
The upshot is that there's a lot of different things to consider, nobody can just pick one language for all occasions. Well, they can, but the only language that will ALWAYS work for ALL cases is assembly, and I don't think many people really want to write entire applications in assembler any more.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
You might want to look at it from your customer's perspective - i.e. what does your customer loose and what gains.:
customer already uses a platform and has technical guys to administer it: choose his/her language if possible. If what you're developing is going to be ran by other people, these people probably cannot administer IIS, BEA, Apache, Tomcat, MSSQL, Oracle, Mysql and whatever else comes in mind. This usually counts for big projects. I bet that majority of slashdotters wouldn't like the delivered product be for IIS+MSSQL+C#, whereas it's still standard for lots of companies outsite.
code-maintainability: think why your customer hired a company instead of a freelancer - one reason is continuity of development. if you're going to programm something else than one-off application, you need to have people profound in the technology you used (and it does not only include language, but servers, etc...) and keep enough of them. if you don't use their skills by the time there is nothing going on in the project, you loose. if you fire them, customer looses. if you teach them completelly new stuff, it can get expensive (and specialisation usually brings experteese).
re-use: if you're able to re-use components you already have, your customer can benefit from that as well. and you probably can benefit from that by the time you put your offers.
support: if you're doing some serious development, you want to stay in touch with the future development of your language. be it java, python, c# or php. having more languages requires you to spend more time in this. which usually means more money.
what i'm talking about is usually mid-size computer company doing bigger projects for big companies (like banks, telco, etc...). so I believe, that there is usually no way you can avoid standardisation of a platform in bigger companies. even google, with (i believe) really bright programmers choosed a limited set of languages to work with.
so i'd say: choose a limited set of languages you can support. just one can result in lock-out, too many can proove to be burden if you think about serious more big projects with long live and continuous development.
usually decisions like this don't result in either 1 (choose one) or 0 (don't choose any). it's a matter of reasonable amount of them, so that you can have enough people profound in them to be able to help your customer all the time.
We only have one 'standard' IDE - WSAD. There are, at any one given time, three versions (the old, the current, and the new) being used by developers. We have several machine builds that install or rebuild a machine with Rational / WSAD. Why do we only 'support' one IDE?
Money. Time. Support costs. In our organisation now we have one guy who creates/fixes the deployment scripts for windows machines. He is also the one person who the helpdesk / faults go to. So, yes, there can be a business rule behind only having one IDE.
Then again.. there is nothing stopping people here form installing a second IDE. Just don't put in a helpdesk request for someone to fix it for you. There's nothing wrong with this approach.. so long as you know why it the decision to only support one IDE was made. In the same vein we only have one source control product (officially) - ClearCase (for now). Less support required when there is only one product involved.
Never install WebMethods unless you seriously have a reason to use it, know what you are doing, have it installed by someone who knows how to correctly configure it with your current architecture and you have a gold level support contract. Failing all of the above.. try hiding your head under your desk and hope that the problems will just go away. Works here 9 times out of 10.
You have a sick, twisted mind. Please subscribe me to your newsletter.
I'm an independent software developer (translation: marketing, life cycle, engineering, development), and I can honestly say I seldom create an application in one language. To tie yourself to one language, it's pros and cons, is nothing short of shooting yourself in the foot.
Havoc Video
If all of the company's products solve problems that can be addressed reasonably with a single language, then it would be a good move to consolidate. At my current company, we have legacy code in C++, VB, and all of our current projects are in Java. Guess which code is the cruftiest? Guess which codebases no one wants to work with?
The company simply can't afford to keep a staff dedicated to each different language's codebase, and no Java developer I know would deign to work in C++ or VB even if they have extensive experience. I know assembly, but I'd start looking for a job if my boss told me I needed to split my time between Java and assembler.
On the other hand, if the company makes a diverse set of products that simply cannot reasonably be approached with a single language and platform, then it would be a mistake to try. Engineering should be split into separate divisions if the problems are that different and separate staffs should be maintained for each.
but have you considered the following argument: shut up.
As a sysadmin/mini-programmer I say don't standardize.
Far too often I have seen things like grep in a perl script, shell calls in c programs (I mean to shell scripts that do the work) and all sorts of nastiness that just makes things more complicated than it needs to be.
Some days I wish I could just use Ruby for some stuff. Dumb things like adding lines of a file to file names or other such stuff is a breeze.
That and threading (yes I know it isn't true threading yet, 2.0 will fix that).
I wonder how far a standardisation drive would go if it was pushing everyone to use the company provided ballpen/pencil - and not one of those ubiquitous monte blanc pens that ride suit & shirt pockets - perosnally I wouldn't mind the sight so much, but they are all usually just a.n.other ballpen - me - i am a snobby fountain (ink) pen user - oh yes - and 0.7mm pencil - but lets not start a debate on pencil lead...
"I am a computer programmer. I make computing devices do what I want. I will use any tool at my disposal, to hell with my employer's proposed "beneficial" restrictions."
;) ). It worked and brought Chrysler back from the brink. From that point the car industry understood standardization needs to happen. Now we even see standardization of major parts across car manufacturers. And yes standardizing on one screwdriver is part of it!
This is why we have we mess that we have now! If you were an engineer and machinist you would be screaming bloody murder! About 20 years ago the car industry had the problem where they had 20,000 parts that were unique to a car. When a new model was introduced there were 20,000 more parts unique to the car! All of these unique parts were wrecking havoc on car design, and maintenance.
If any of you remember the K-Car from Chrysler it was the first attempt in the car industry to share parts (Oh the horror!
"You can't make a race horse of a pig"
"No," said Samuel, "but you can make very fast pig"
We standardised on java. Great, now we have a room full of developers who can't maintain our legacy apps (C etc), they can't rapidly devlop something in a more simple language (perl, php). Now every machine needs a JVM installed.
Horses for courses my friends. Would you expect a system admin group to standardise on a scripting language, no, they'll use awk/sed/bash/perl/etc when needed and be more effective because they will be using the right tool for the right job.
Bloody small minded java monkeys.. You can hammer a nail in with a wrench if you want, but I'm not hiring you to build my new kitchen.
Would you trust a carpenter that opened his tool chest and it contained only a #2 Phillips screwdriver?
An auto mechanic that used only Channel-Locks?
A hair-stylist that used only a Flo-Be?
I have been writing software for 25 years. A good professional programmer knows when to use the appropriate tool for a specific task. Only an idiot would tell him he couldn't.
Of course, every time I used awk to transform some text, I probably could have built an equally functional solution using C or Java. It would just be 10-100 times more code - with the corresponding increase in bugs and time spent creating it.
You're setting up a straw man. Here's the opposite: If everyone gets to use their favourite language, you'll end up with lots of code that no-one else except the author can reuse or debug.
This isn't even that far fetched. I've seen a case where one guy insisted on using language X for his tasks, a language which nobody else in the department was familiar with. Then he left. If his boss had insisted that everyone use a less elegant but widely familiar language, lots of headache and time (==money) would have been spared.
As usual, the right approach is somewhere between the extremes.
I'm sorry if I haven't offended anyone
Usually, it's hard to substitute a language of one category with a language of another (if some of your code runs on an embedded platform, or in kernel, you can't do those parts in Perl...). Likewise, it usually wouldn't make much sense to program your sysadmin scripts in C.
So you pick one language of each category, and make these your set of standard languages.
Beyond that, if you push to "standardize" languages across a company, be prepared to write code in your least-favourite language. Personally, I'd recommend that your company give you a choice between FORTRAN, COBOL, LISP, dc, and PHP.
http://outcampaign.org/
I settled about a year ago on two things: 1. Use the right tool for the right job. Web applications, which perform most of the processing on a remote server, are very different than GUI apps that run on a user's desktop. It's stupid to think that one language is going to provide everything you need in every case. GUI apps need strong typing to run quickly and keep the end users happy - Web apps need rapid design to keep the VPs happy. End users love GUI apps and hate crashes; VPs love Web apps and don't care if if an app crashed from time to time as long as it mostly works and gets done NOW. Pick whatever language is appropriate for the task. 2. Learn from Java. Java has its warts, but from a structural standpoint it's probably the most solid language I've ever worked with. These days I mostly work with apps that target mod_perl, but my code - and the code of anyone who works with me - is required to adhere strictly to Java's naming convention, must follow a pure OO paradigm, and do its best to act like a JavaBean, with "getters" and "setters" properly implemented and static and normal methods documented as such. By doing this, I've managed to make Java programmers actually like working with Perl... something long thought to be impossible :)
Beauty is just a light switch away.
Wha?
A company where that can happen has a much bigger problem than languages. Such as a complete lack of teamwork and communication between it's developers!
Standardizing on a language will help a bit with the symptoms of that, I suppose, but unless you address the actual issue, I don't foresee great things for that kind of organization.
Not to get religious, but avoiding problems like this is one of the big "hidden" advantages of pair programming.
I like unlambda better, because it is intractable in a conceptually pure way, rather than by virtue of heaps of stinking crap. Although the whitespace language does have it's appeal, I must say.
Regardless, I take exception to the notion that you can't write a webserver in bf (or unlambda or whitespace). You can indeed write one. It's the *operating system* which is failing to perform the IO, not the webserver. Fix the operating system to recognize when your application is requesting to do IO and the problem is solved.
-I like my women like I like my tea: green-
It's shouldn't be an issue of best language for the company, it's an issue of best tool for the job. I saw the reference regarding standardizing on a screwdriver in a manufacturing plant. Strangly enough that does makes sense alot of the times (I used to run a plant and standardizing on a screwdriver meant we could buy 500 high quality screw drivers each at the cost of a cheaper model). But on the other hand, on one production line where we handled through-hole soldering work on a primarily surface mount board, we used high quality Diamond-Excelite diagonal cutters that reduced the number of blisters and calluses on the workers hands. In the primarily through hole manufacturing environment, we standardized on using air tools for clipping, Diamond Excelite make a fabulous air compressor powered set of clippers that can cut 6 leads simultaniously in one click of a button. In this environment, it made more sense for that tool. Also, I'd like to make clear that in cases where we needed a hammer, we used a hammer, not the other end of a heavy screwdriver.
.NET solution over Java (and in fact, I don't like either solution, but choosing the lesser of two evils) because Java is theoretically standardized on a single language for a single platform (the JVM) where .NET is instead a solution that standardizes on no language but could realistically be targetted to different platforms if someone were interested. It would be excellent to one day see a C# and Visual Basic compiler targetting the JVM for instance.
That all being said, working as an engineer in a leading commercial software company, we standardize on a language per project/environment. The software we develop is 95% C++ and 2% Java and 3% scripts (makefile generators etc..). In the IT/IS departments, we use Perl for the automated build systems and we use PHP for web systems. In places where we know there's no hope for a standardized scripting language across platforms, we often write simple C programs mixed with bourne shell and windows scripting host.
For managers, this environment is often a disaster. It requires that we have a minimum of 3 developers for each language used. Of course there's often an overlap in skills, and typically, an educated developer can work in any language, but it still means that we have to make sure the talent is always available.
The rule to remember is that if you have 1000 screws and 1000 nails, and the job requires 2000 fastening components, it often is better to standardize on one or the other and purchase the extra 1000 fasteners while the first 1000 are being used. But it does not make sense to use 2000 nails if 2000 screws does the job cleaner and more efficiently.
This is a problem I have seen in many companies over the 14 years of my professional development career. If you are however an IT department developing a single set of systems of a single set of users, then standization may not be the wrong choice. If your company has the budget to hire a Ph.D. that can work purely in a research environment to develop alterative solutions to problems, it may make sense to hire one. It often makes sense that a proper researcher is on staff to make sure that the company is never stuck in a single solution environment. I personally like the
Good luck, but I suggest you just go with it, if management has come to such a solution, it's is more likely that managing multi-language systems is too much for the organization.
It's all fine and dandy to have standardization on coding language and conventions - these make it easier to read work done by somebody else, and lower the cost of maintenance. (which is, arguably, GREATER than the cost of development)
But, no matter what, I don't care what your philosophy, it's very, very important to standardize your DATA FORMATS. The state of Massachusetts is coming to this realization - that they need to be in some control of the format that their data gets stored in - and over the next 20 years, expect to see this become ever more of an issue.
You can write a perl script that interoperates with a java jar or a PHP weblication if you have a common, agreed-upon format for storing the data. If your data store is a particular database, such as PostgreSQL, this isn't much of an issue. But, if you feel OK giving developers their choice of languages, make sure that whatever format you save your apps in, you can READ IT using other technologies!
I have no problem with your religion until you decide it's reason to deprive others of the truth.
My boss is confident enough in his staff and himself to be able to pickup and maintain whatever the developers decide to do their job in. Currently I have written C#,Java(JSP/Servlets,J2ME/MIDP, server applications, Blackberry J2ME stuff, Applications), C/C++, Tons of Shell scripts, XML, LaTex, HTML, XML running on Solaris,Windows,FreeBSD,various flavors of Linux. All of which ultimatley connect to either an Informix or Postgresql database of which the host apps are running on an old legacy SCO UNIX system. Whatever does the job best is our motto. Id hate for my boss to walk in and say convert everything to . It would be hell.
Assume that highly-skilled programmers work efficiently without a need for rules like these, but morons do not.
If you find that you *need* a "language standardization" policy, then you're already at a disadvantage, because talented people often tend to avoid working in places where there is a large number of people whom they perceive to be morons. As a result, skilled people are less likely work at your company than they would be otherwise.
Now, if you create policy that explicitly *hinders* skilled programmers, well...
I'm sure many of us would *love* to scoop up the talented people that might otherwise choose to work at your company!
http://outcampaign.org/
You only need to choose if it should be xml, html, javascript or java... That any project can be solved with just one language is an illusion! But it might be a good idea to select a single language in the main language categories, to make it possible to maintain the code.
Max M - IT's Mad Science
Had to go through that once. Delphi -> Java.
Only causes a lot of retraining and angered employees, and the typical Delphi shops (departmanets) after a while quickly abandonned Java again, at the first point where the Java solution was ore troublesome than Delphi (read components availability, performance, lowlevel interfacing)
Maybe except for projects with a more company wide scope.
I love debugging a C++ callstack that goes in and out of an interpreter a few times. It's bad enough having ten programmers with different approaches to programming without mixing langauges.
Well, you can think of anything that goes into the interpreter as something that takes you out of the prison of C or C++. I mean, for the brief, glorious times that you actually are in the interpreter, you are free of pointer bugs, arrays without bounds, and other problems.
smash.
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
So are those hardcore standards people going to want Java operating systems, and Java office suites? I mean, if they want everything in Java, then I guess C written OSes, or C++ written apps are out too, eh? Oh, and no shell startup/maintenance scripts. Excel/word macros, banned! Legacy Cobol stuff? rewrite!
IT is too diverse to be this anal about standards. Have a recommended/encouraged standard, but allow exceptions.
From my experience many programming languages have different pros and cons, choosing the best language for each task is generally the best idea. However standardisation can save money but in time it may cost more as you may have to write more code to do simple tasks rather than use built in modules etc in other languages.
Every company and situation is different, there is no "one size fits all".
- Will standardizing on 1 language save your company time and money? Yes, probably, as long as the majority of your employees already are trained in the language.
- Will standardizing on 1 language safegaurd you from future pressures and shortcomings of that one language. No, of course not.
The bottom line I guess is what is best for your company and situation. If that 1 language can do what you need, and all you'll ever need and the majority of your employees know it anyway, then why not.
I would hazard a guess that most people want to get a problem solved in the most painless manner possible when programming.
Surely the best way to achive this is by avoiding the reinvention of the wheel.
In some manner I tend to view languages now as nothing more than the glue that binds library calls together!
My approach is:
For example, there is a wealth of scientific code out there in F77. Just because F77 is old doesn't mean that the libraries are now wrong. They still do what they did back then. They are still useful. People have spent a great deal of time working out the error propagation in these codes, the efficiency and their validity. Do you really think you will save yourself time and do a better job by rewriting it in Java? No! So. Use them.
Then there are (great) libraries such as ATLAS or FFTW [*] written in C. Why assume you can do better? You can't, use that too.
In the rare case where you need to have something written from scratch, write it in whatever you are comfortable with. In my case C++/Boost (yes another library).
Finally you need to tie all this together, and hack around with it, and analyse the results so what's wrong with a bit of Python and MATLAB?
Perhaps this is an extreme example, and doesn't fall into the buisiness relm but the point is "the path of least resistance". Sometimes that path is dictated by existing code.
Do you really expect someone to rewrite from scratch an XML parser in "DoomJuice", or whatever is fashionable in house, just to please the people that want to standerdise on "DoomJuice"? No, use an existing library!
Ok, I've made my point. I will stop now.
[*] Yes I know FFTW technically uses Objective CAML to generate C code, but that's really only a distinction that a nerd would make.
Be nice to people on the way up. You will meet them again on your way down!
Lets see:
About 2 years ago, - lets say 2004
followed by 8 years of Smalltalk - 96?
I chose erlang after 8 years of Java programming
By my reckoning you were writing Java in at least 88? Wow, you were way ahead of the curve on that one. But then maybe I should be less pedantic / suspicious, and assume you meant Smalltalk then Java.
We standardised on C# for production code and monad (already!) for scripting. They're easy to deploy, easy to get staff for and easy to use (compared to some laguages).
We do not have any problems that way with small chunks of unmaintainable junk sitting on strange boxes all over the company.
We do not have any learning curves.
We do not have any unexpected trouble if someone leaves.
We can automate *everything* (for example it takes us about 25 seconds to deploy our entire software platform (which is massive - think 90Mb of source) if it passes QA.
We do however spend all day bitching on what design pattern is best, which is a far more appropriate use of time.
I worked for a bank in Australia that standardised on J2EE. The strategy and architecture guys said it would be great for reusing components across projects. 5 years later I was still developing and supporting ASP applications.
"A single language makes each developer easily replacable."
-- Dream on! At Wells Fargo, they have a bunch of hackers that have no concept of design.
Ah, computer programming: One of those rare jobs where incompetence means job security.
If you can write really unreadable code, then your bosses won't have the nerve to fire you!
But if you write sensible, understandable and well-documented code, well, then your replacement can easily pick up where you leave off.
Phiwum's law: anyone that names an obvious law after himself and then puts it in his own sig is just pathetic.
Have fun teaching your managers pseudocode.
-:sigma.SB
WARN
THERE IS ANOTHER SYSTEM
Every generation has had it's favourite language, and the big ones has been Cobol, Basic and C in history. Currently the languages Java and C# is rising, and offers flexibility that can be used and abused but in the end are far much more flexible than the early languages. Ada can be defined as a father of Java and C#, and certainly has it's place.
What you actually should focus more on is not a specific language, but how to model solutions and do efficient coding models. It doesn't matter what language you use if you aren't able to do a good system design. And system design is not something only for senior system analysts to do - even junior programmers should be involved. Start with a large meeting whith a HUGE whiteboard and a lot of pens in different colors - try ideas - even ideas that may seem stupid and explain WHY it's stupid. Break down into task groups and let each group do it's own analysis. This should be repeated through various phases in the project to be able to stay on track. A system isn't better as it's overall design - even if it incorporates solutions that are outright brilliant.
Building a system is like building a house - you use different material for different parts. The foundation the house resides on is the operating system. Utilities like electricity, gas, water and sewer are all connected at foundation level, which can be seen as C code (and optionally assembly code) and are normally part of the language you use unless you have special features. The basement is done with the basic language classes of Ada, Java or C#. As is the framework of the rest of the house. The walls are then done by extended classes of your language of choice and then all trimming, wallpapers etc. are your completely custom-built classes. There is need for different class groups in different rooms - like a kitchen and a bedroom does have different properties - so only a few properties are common, and you may even be able to accept that they don't even share these properties in an abstract base class since that may require too much interoperating time between different task forces. It all comes down to how big your project is. The re-inventing of the wheel can't be avoided every time, and if the wheel costs five minutes to invent - is it worth the time to check if it is already invented?
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
i was gonna post something about one-size-fits-all and reinventing the wheel and doing what meets the business requirements, but you have it all here.
Some company we worked with was one of these Indian, cmm level five, everything-prefixed-with-'enterprise' outsourcers. They had standards alright; everything was oracle and java. Everything. Except, of course, when the software had to fax. Or convert html to postscript. Or print. Or be accessible from the outside. Or generate images. Or do things in a timely manner. Etcetera, etcetera, etcetera. Really, everything was java and oracle in the end, except for everything the software had to actually *do*.
I guess the whole debate is the symptom of some sort of culture-clash; not Indian vs. Western or anything, but rather programmers versus managers in large bureaucratic companies with standards vs. small flexible companies where people actually talk to each other.
Is that AutoConf 2.13 or AutoConf 2.5?
they're conveniently incompatible, and you didn't specify.
The Slashdot story said, "The anti-standardization guys are advocating a mixed environment..."
I agree with your ideas (in the parent comment), but I thought this sentence was extreme: "I am a computer programmer. I make computing devices do what I want. I will use any tool at my disposal, to hell with my employer's proposed "beneficial" restrictions."
The problem is that many people involved with computers fundamentally don't actually work for their company. Instead, they do only what they perceive is best for them. Generally, when such people are programmers they want a resume that shows familiarity with many computer languages.
That kind of short-term vision works because of the brokenness of the human resources department of most technically-oriented companies. In most such companies, the top management has too little technical understanding. The top management tries to reduce salary expense by hiring people who will work cheaply, and that means people with minimal technical understanding.
Poorly educated human resources people are impressed by someone who says he has familiarity with several computer languages. (Actually, human resources people aren't impressed at all; they only think the manager for which they are interviewing applicants will be impressed. Generally the people with no technical knowledge at a technically-oriented company have a secret belief that they are superior to those who work with grubby technical details.)
Of course, it would be possible for someone to lie on a resume and claim knowledge of languages with which he or she had little experience. But that is regarded by most people as far too risky. The liklihood is that someone doing the interviewing would detect ignorance.
So, many programmers want enough practice that they can claim familiarity with several languages. Such people can be expected to lead their companies into as many technologies as possible.
A good simple example of this is any online banking web page. You will find a lot of foolish use of Javascript by designers who clearly were just experimenting. Banks are where the money is! But, amazingly, banks are not able to hire people who actually work for them; their IT staff works for their next job. It's that bad.
The average person wants to move up the job ladder in preparation for retiring and waiting to die. Someone who actually has programming in his or her heart, however, gets tired of all the tools after a while. Each tool has serious limitations. Each tool has its own quirkiness. Is it beyond human comprehension to make one good compiler and one good editor?
"The right tool for the job" tends to mean "none of the tools are very good". My opinion is that Java is necessary and good, but it should have been activated as a compiler switch for GCC.
Unfortunately, programmers are, in my experience, not good at loving themselves. Many of them are too insensitive to social issues to recognize when they are being abused, so they don't recognize when they are abusing. In a perfect world, programmers would expect more perfect tools, and they would always have the needs of their companies in their hearts at the same time they considered their own needs.
But, we don't yet have that more perfect world, and programmers often express desires to be involved in software development in such a way that they would quickly create intellectual overload for themselves and their managers. If they have their way, their company fails and they get a job elsewhere, never realizing the misery of their existence.
--
Before, Saddam got Iraq oil profits and paid part to kill Iraqis. Now a few Americans share Iraq oil profits, and American citizens pay to kill Iraqis. Improvement?
If you're doing any web development (and let's be honest, if you're doing any develolpment, your organization is doing some web development somewhere), you *must * use 3 or 4 different languages. No way around it. If your organization isn't using some combination of HTML, XML, CSS, Javascript, XSLT, XPath, ActionScript (1, 2, or 3!), SVG, and other web languages, well, WTF?? Toss in a server side language, either Java, ASP.Net (any), PHP, Perl, Ruby, etc, and often you pick (or have only 1 choice of) a tag language to match (like JSP/JSF/etc with Java). Unless you're using some data abstraction layer, ORM type thingy, you'll probably have some SQL kicking around too.
.Net runtime. Then, you probably have to write an installer, and this might be using InstallShield's scripting language or similar. Does your QA department do automated testing? The automated testing tools usually have their own scripting languages too (maybe these are moving to .Net languages now, I haven't looked in a while). And if you're a big dev team, you'll be doing automated builds, so'll have somebody who's actually hacking around with makefiles (potentially MS format NMAKE files).
Next, if you create an end-user application of some kind, in many many cases, you must use C/C++ due to end user requirements. Some of this is being eaten up by C#, but not everybody is willing to target the
If you're company is big enough to be worrying about this kind of problem, you'll have an IT infrastructure of some importance. Your IT team damn well better be using Bash scripting, Perl, Python, or some other Sys Admin language. Even Windows admins these days write scripts; there's even this new scripting framework scheduled (as an add on?) for Vista. How about your Apache config files? Your various mail/proxy/firewall configs (talking to UNIX folks here...)?
If you have a real IT division, I'll bet you have an accounting section. Remember why people have such trouble moving to OpenOffice.org? That's right, custom Excell/Acess solutions. What's that, VBScript you say? Moving into Fortune 1000 territory, how about R3? Well, that SAP system never actually did anything, but those consultants sure made a helluva lot of money. Manufacturing and assembly lines use all kinds of weird stuff. Got any telephony solutions running around? Are you targetting mobile devices? Use scientific/mathematical software? Rendering software? Various pre-press systems? Work in the medical/health care industry? A lawyer's office? All these verticals have lots of custom things running around that you sometimes can't avoid.
So in a nutshell, any reasonable corporation doing software development *should* be using 5-10 languages. If you were to pick only 1 language, the only choice you could possibly have is HTML. You could theoretically write a static HTML page with no CSS, no Javascript, no server side scripting, no SQL, and no Flash. You could run it off of one server, with no admins and no scripting. With no product to hawk, you don't need an accounting deptartment, and voila. Good luck with the whole money thing, though... What a stupid question. Use what you have to based on the requirements, and when you have a choice, do your best (maybe even bend over backwards) to avoid unnecessary proliferation.
I work for a reasonably large IT company. We have hundreds of developers and between them they must know a huge number of languages. However, we only use about four languages for development of production systems. Two are compiled, two are interpreted. Three have object-oriented facilities, one doesn't. Two are commonly used to build web sites, two are not. Two are scripting languages, two are not.
So, with just four languages there is, in real terms, a wide choice of characteristics. However, there is no rule in the company that states that we shall only use those four languages. However, if you are trying to get some code written, choosing an obscure language only makes it less likely that ytou can find people to work on the code. This is a natural disincentive to the proliferation of languages.
What I'm saying is, the problem just works out. It solves itself. If your colleagues are spending significant amounts of time arguing about which language to implement in, are you sure they understand the tasks at hand properly? Are you sure your problems are technical problems and not people problems?
Better avoid a situation like Debian where duplicate libraries in Perl and Python (soon enough in Ruby and Pike too - $deity forbid - followed by yet more duplicates in Mono) become standard packages, simply because too many important or essential tools were coded in those languages without consideration for keeping the basic installation's package count to the strict minimum. This is one of the main reasons why transitions are so impossibly difficult to manage in Debian, nowadays.
Then again, at the other extreme, an OpenBSD situation where an excessively spartan C shell and a substandard Korn shell are the only two possibilities should also be avoided.
Pick one compiled language for binaries and one scripting language for everything else (boot scripts and "glue" components). That's it. Then, standardize on those two choices and spank unconscious anyone who tries to deviate from the company's selected standards.
Software is not supposed to be about how to work around a useability issue. - Ken Barber
It sounds dumb. It is dumb. What about when you purchase that small company and their code is in fuck#+--, but all your newb ass programmers only know REALLYBASICSIMPLESHIT. Yea, you're fucked.
I'd rather use the right tool for the job and employ versatile people who could care less what lang. the implementation is in, as long as it is the 'right' one. I guarantee you'll have some meeting and ppl will be like zomg we could do it so easy w/ this small script but the boss says we HAVE to write EVERYTHING in java. ghey.
by standardizing "standardise" and "standardize"
Do you have an oblem?
In most companies I've worked for, there wouldn't be standardization on a single language, but rather a list of approved languages, eg - J2EE or .NET for web, perl for unix scripting, C++ for application development, etc. Is this not a more sensible approach?
Man Needs God Like Birds Need Helicopters
A good programmer can write FORTRAN in any language.
1) The people problem. As with any change or edict, there are people that will be naturally resistant towards it. Others will naturally go along with it. You can cause a whole new outbreak of problems when this happens that are so far unrelated to the original problem, that you will wonder wtf happened.
2) There is no way to solve every problem that comes along with (insert your favorite language here) efficiently. I don't care how sexy or catchy the name sounds. Writing windows apps in assembly *sucks*, and coding in 32k of ram with Visual Studio *sucks*. Everything else is relative.
People get paid to use their judgement. Let people use their best judgement when it comes to picking their tools. If their ego or judgement is a problem, deal with that accordingly.
Join the Slashcott! Feb 10 thru Feb 17!
Standardizing on a single language is, in theory, possible. In theory there's no difference between theory and practice, but in practice there is. Yes, with any Turing-complete language you *theoretically* can do anything you need to do, you will in practice discover that this is not the case, that there are things for which you just plain have to have a different language.
What those things are depend on what language you standardize on, of course. At work all reports are created for Microsoft Reporting Services, so that means TSQL. A few weeks ago, I ran into a solid brick wall: TSQL does not have regular expression matching. At all. I needed, for a particular report, two or three dozen regular expression matches. Implementing any given one of them in some other fashion (e.g., with a trainload of LIKE operators glued together with OR) was going to turn a hundred-line report into tens of thousands of lines, to get everything right. Initially I settled for kludging together LIKE matches for just the most common subsets, but ultimately we had to install a third-party regular expression library, which is (guess what?) not implemented in T-SQL. If we'd been locked into only solutions implemented in a certain language, I'd have been stuck.
It doesn't matter what language you standardize on: you will find it utterly inappropriate for some tasks. Even a language like Perl, which is expressly designed to make "the hard things possible", has some things it's just *not* well-suited for doing (in Perl's case, GUI stuff).
On the other hand, "standardizing" on a particular language in the sense of requiring all of your programmers to know that language and work with it on a regular basis is probably a good thing. Just make sure it's understood that there will occasionally have to be things implemented elsewise.
Cut that out, or I will ship you to Norilsk in a box.
It was tough. But once we standardized on english, communication was MUCH easier.
If there is a strong notion amoungst the employees to all get down on the same language and do whatever needs to be done in that, even if it isn't that good at doing it, you may go ahead.
Scritping in Java must be anoying compared to Python. BeanShell might be a different issue but still. And one would have to argue wether BeanShell still fits a "go Java" rule. In order to do effective scripting in Java you have to be firm in it.
Parsing, Printing and Document Conversion could suck aswell. It's all about libraries, knowing them and the people knowing how to write and document OOP properly.
If everyone in the outfit is determined and willing and diciplined enough to join in and you get down to documentation standards and get together a nice set of libs for all company tasks at hand it may very well turn out well.
Otherwise just use the best tool for the job, regardles of what PL it is.
We suffer more in our imagination than in reality. - Seneca
As somebody who works with hand tools on a daily basis, believe me when I say that standardizing on one type of screwdriver would be a good idea. Provided that choice would be Robertson screwdrivers, of course. In fact, I'd almost go as far as to say that Phillips and flat head screwdrivers should be illegal.
Is that a real poncho? I mean, is that a Mexican poncho or is that a Sears poncho?
... and choose the hammer. I've been putting screws in with a hammer for years and they all stay in, a hammer is also good for nails and I have found hitting two things enough often makes them stick together (especially if there are nails in them). So yes, standardize but on the hammer. Oh wait we were talking about programmign languages. Erm well yes I agree.
I used to have a better sig but it broke.
In the early 80s the military rebeled against the chaos in their software procurements. They claimed that in the history of procured software projects that more than 250 langauages had been used, only one of which was used in more than one project (I think that one was Jovial which was used in two projects.) They commissioned Ada to be the single language to end all languages. They tried to be as heads up and up front as possible in designing Ada, and solicited input from anyone and everyone. As you know, Ada made a major dent in military circles but it never got far in becoming the one and only language. There were (and are) compelling reasons to also use other languages.
So what's the point? We have to allow some chaos and experimentation even within projects. Otherwise, our thinking gets too rigid and we lose the ability to stimulate new ideas and to let the best ideas percolate to the top via real life experience.
If every project optimizes only itself, and doesn't consider growth of the industry and the profession, the result is stagnation. We would be becalmed in a sea of localized suboptimizations. R&D does not belong exclusively in ivory towers. Software R&D works best when allowed to grow from real life's hard lessons.
The best advice I heard was that large projects should budget the new technology and risks that they allow. In no circumstances should a project include more than 25% new (or risky) technology. On the other hand, I would argue that a large project should budget 10% (certainly no less than 5%) for undirected experimentation. Management should not get involved in the nature of the experiments, but it must manage the quantity of experimentation.
From my standpoint, I find the process of standardation rather futile for the following reasons:
/* $0.02 */
* By the time the "standard" gets written and approved for development use, the technology has already changed.
* Managers seem to have a problem inforcing what they standardize upon. Once they finally understand it - the process must then start over again.
Outside of these reasons, it just squashes creativity.
I went very well. The standards committee decided on windows/ C++/Java/Tcl. And now everyone is developing in c++/java/tcl/python/pearl/bash/Qt on windows/Linux/solaris. welcome to the real world!
This is one of the main reasons to use a .NET language. They can all be intermixed within the same code and go through the same debugger.
easy for you to say... what if it's not up to you to fire/hire people, but it's up to you to make every inhouse developer (bad, mediocre or good) able to work on any new (and in the future existing) project
i'd say the 'pick two' option the grandparent suggests doesn't sound too bad afterall
if you standardize and get it approved by whatever steering organization there is (committees, upper management), then you have something you can use to fence with against unwilling/unqualified existing staff (i.e. have them fired or transferred to another division if they won't/can't follow the standards)
it all depends on the size of the company, the position you're in, the quality of the existing personnel, unions, friends in high places, politics, etc...
When I read the title of the article I thought it was about the English/Hindi languages.
But the weak form of this (everybody should be using the same set of complementary tech, except in cases where there is a clear technical justification for it) makes a lot of sense. In particular, letting different people use different tech that are basically equivalent (like Java/C#, JSP/ASP/PHP, Perl/Python/etc.), just because different people like different stuff or want to try out new toys, can make your life much harder.
So if your company wants to make commitment to a set of tech (like Java, or .NET, or whatever) and try to use that in all the cases where it makes sense (even if there are other tools that could do the job just as well), I'd say that's a good thing.
-Esme
I totally agree.
Using multiple languages for a given purpose just creates more of a legacy liability. If you do your performance critical software in C, C++ and Assembler then you need to maintain a staff that knows C, C++ and Assembler.
But that is not a reason to try to write web applications in C. Or even test scripts. Those areas need their own standard tools, and using the tools standardized for another area will not make it easier to recruit and maintain staff. It will mean that you'll have to recruit web developers who use different tools than what all the rest of the web developers are using.
Ditto for test tools, which is actually where you see the greatest tendency to just let each project decide how they are going to write their test scripts.
If the problem is not uniform, then the toolset shouldn't be either. But that doesn't mean you should just casually select the toolset for each project without recognizing the cost of maintaining competence with each new toolset added.
There's the right tool for the job and the wrong tool for the job. Then there's the generic tool, which is almost the right tool for almost every job: Think about all the things one can do with a Leatherman. I've sawed up 4 inch branches, cleaned fish, loosened bolts, stripped wires, punched holes in leather. The Leatherman did a fair job at each. But I found myself sawing a lot of branches, for example, I'd invest in an honest-to-Ghod saw. Likewise a scaling knife, ratchet set, wire stripper, and a rotary-tip leather punch. I love my Leatherman, but like every other multipurpose tool out there it sacrifices efficiency for versatility.
Ponder the various goals you're trying to reach and find a (hopefully short) set of tools to reach those goals. For example: Serve your web pages in PHP. Exchange data in XML. Retrieve data in SQL. Hack and script in Python. Write everything else in C++. But: Don't hesitate to use Java servlets for computationally expensive web pages, exchange medical data in HL7, retrieve textual data with AWK, hack and script in Perl, and still write everything else in C++.
If you want to standardize your entire company on a single great big perfect do-everything language, just ask the U.S. Department of Defense it's doing with Ada.
This is not my sandwich.
If you want to start hearing "We can't do that" go ahead and standardize on a tool. Better to standardize Processes, Methods and Practices than a toolset. Unfortunately this is usually so difficult and so contentious that few institutions rarely do it! The easier way is to say, "We'll just all use the same tool". Since all tools are a compromise, a single tool will promote mediocrity at the expense of innovation. When that happens you are dead money in the poker game of business.
Of course! You must remember Erlang....
Both have pros and cons. Standardizing on a single language limits the knowledge required to do the job. Using many different languages (The right tool for the job) saves development time money, and headaches.
My beleive is a using different languages, but limiting the langauges used. The last thing you want is 40 languages floating around your office. Then again, you don't want a basic applications taking 3 weeks to a month to write in Java or C that could have been written in 1 or 2 weeks (or even days) written in Python or Ruby.
more Perl than I'd ever want to see
And it's all on one line, consiting of #$/%;&(!-> and {
I work for a company where instead of standardizing on standards, they standardize on the wrong tool. For example, here we build our Java application with DOS batch files instead of Ant. That's what we standardized on. Needless to say, the build is not incremental (unless you know which sub batch file to run instead of running the main one, and then only with so much of granularity: you rebuild whole modules). Maintaining this is a headache and some files have to be included one by one in batch files, instead of using patterns. When I suggested changing this I was told that it works and it doesn't need being changed. One of the reasons for this is that we don't have regression tests (regression tests: a great thing to standardize on) here so the QA guys only check what we work on, so that we cannot afford to do system wide improvements or refactorings at key modules. Another thing we standardized on: CamelCase. That's natural, because we are a Java centerd company. The problem is that our XMLs look like this instead of In short, standardizing for the sake of standards will not take you anywhere. Standardize on the right tools for your purpose and not apply standards on everything.
Use C# for codebehind that dynamically builds SQL with ASP.net on the front end. Doesn't sound like it's possible to be homogenous - unless you standardize on Perl ;-)
... is that it tends to degenerate to the "lowest common denominator", or the most widely-used language for everything, regardless of applicability and common sense.
Nonsense such as COBOL in the desktop environment, or perl in an IBM mainframe environment. Neither makes much sense, as the supporting codebases that might make COBOL in an IBM mainframe environment do not exist in a desktop environment (without extensive (and expensive) porting) and similarly, the large pre-existing codebases for perl do not exist (or again require substantial porting) in the mainframe environment, not to mention perl's targeted UI of a unix shell or console is not what one is presented with in mainframe environments. REXX makes for a much better choice of a scripting language on the mainframe.
Yes, you CAN use COBOL for everything. Or Java. Or C/C++. Or perl. Or assembler.
That old saying, "To the man with only a hammer in the toolbox, every problem looks like a nail", applies here.
Having a toolbox with a reasonable assortment of versatile tools is a sign of a craftsman. Having a toolbox with every tool known is a sign of a rich dilettante playing at being a craftsman. Having a toolbox containing a single tool is a sign of an idiot playing at being a craftsman.
I would not want to write Oracle stored procedures in PHP, I would not want to write web sites using PLSQL.
.net rather than Java.
.net
If I were writing a windows only GUI that made heavy use of the Windows API,I'd want to do it in
If I wanted to standardise my server side enterprise applications, I would want to use Java instead of
Standardising on one language across an entire company is a crazy idea, standardising on one language per application type is probably a good idea as long as someone is responsible for scanning the market to ensure your standard isn't becoming obsolete.
Guess they looked for the language with the most checkmarks. In case you don't know, "PowerBuilder" started off as a mainframe language, got grafted to a PC, then had Web client/server glop grafted onto that. Sure, it merits a lot of checkmarks, and now it does most everything, slowly and poorly and with plenty of mainframe-like throwbacks to work around.
I'm reaching here but the idea sounds at least a bit interesting. .NET supports multiple languages. The languages are converted to IL and the resulting code between the languages look almost identical. Could you have that situation where multiple languages are used and IL is debugged?
Its called competitive efficiencies for the enterprise, and the answer is... "it depends". It depends more on the nature of the firm.
I used to be architect of capital markets (trading applications) at Bank One/JP Morgan before starting my own company and I will tell you that there is no one-size answer.
At the bank we tried to standardize on Java and C# (had to placate the myriad of windows requirements, vendor and legacy apps, etc.). It had the effect of making the tech work, at times, less efficient. But it made their hiring and HR practices, vendor and purchasing management, and consultant relations more efficient. For them, there was no real big competitve advantage in saving hardware or operating system costs as compared to all the other issues. There was no huge competitive edge in squeezing 2 months of dev time off a one year project by using a better language.
At my company (starving start-up) it's all about efficiency, competing on technology (and every other facet), and doing things right as best as possible. I don't have 5,000 developers, 10,000 sysadmins, and 20,000 miscellaneous other types to worry about, only my product and my customers.
Answers different.
Good luck on all those meetings...
Rethinking email
I have been one of the advocates for language standardization at our own company, and for the past three years we have slowly gotten everyone on board in C# standard. This was easy to get management's seal of approval, but it has been a very tough sell to some of the programmers in our development department, especially older programmers with with C/C++ backgrounds. Despite this, after three years of being standardized, we don't work any faster or any more efficiently; however, it is much easier for our department to handle staff turnover, because every program in the building (many of which were authored and maintained by a single developer) is written in a syntax understandable by all. Developers in our standardized environment are no more "replaceable" than they were before -- I've always maintained that if all that keeps you at your job is what you know, and not what you can do, you'll be replaced anyway eventually.
Be very, very careful what you put into that head, because you will never, ever get it out. -Thomas Cardinal Wolsey
I've been scripting my web pages in assembly but they never work properly. Is this a Firefox bug?
At least it means permanent work for the rest of us. I spent most of 2003 cleaning up a project where every tool had been used in the worst of all possible ways. CVS for local copies of source code at every workstation. Java for procedural programming and plain c for processing... plain text files. Of course.
I felt like one of those guys cleaning sewers, but I also got paid well, so I guess I am in debt to my predecessor who wrote the code.
In other words: keep up the good work and consider using a handful of esoteric languages! (Including Flip.)
Some say a universal language is impossible, and that you need different languages for different tasks. I say that's a little like medieval philosophers saying you need different epicycles for different planets, or that there's no one bodily humour that accounts for all moods. We're way too new at this programming thing to make any pronouncements about what's impossible in the realm of software engineering tools. To paraphrase Arthur C Clarke: if an expert says something is possible, he's probably right; if he says something is impossible, he's probably wrong. The languages we'll have 100 years from now will be as unlike today's languages as our modern astronomy is to ancient Ptolemy's geocentrism.
However, this universal language, whatever it is, doesn't exist yet, as far as I know, so standardizing on a single language for everything is premature.
Patrick Doyle
I mod down every jackass who puts his moderation policy in his sig. Oh, wait a sec....
Some people, when confronted with a problem say to themselves: "I know, I'll use $language." Now they have two problems.
Moving from one screwdriver to another is not much of a learning curve. Understanding what someone screwed in is not difficult.
Whilst programmers should be given some freedom, I would really avoid multiple languages. Sometimes it's not an issue, like if someone writes a library in C#, a vb.net developer can happily use it. That still means, though, that if the c# developer leaves, you've got to address that knowledge gap.
It's important to work as a team. The teams I've worked in where programmers work in their own way (one guy does his reports in Crystal, two others use an open source reporting engine, another outputs to Excel) you end up with problems. When the guy who prefers Excel is off sick, the people not versed in Excel have a harder job to resolve it. The teams I've worked in where people agree the method of working (preferably in meetings, and buy in to it together and form a common process are those that work more effectively.
Standard languages are fine if you have a complete set of languages to cover problem domains.
People rarely take the time to do this right.
Since all languages aren't created equal, it creates big problems pretty quickly. For example, if you have Unix cron jobs writtin in BASH do you have to rewrite them into another language?
What about systems with Scheme extentions?
What about problems that are simply better solved in a procedural language instead of a functinal language?
A good language standardization policy can be a benefit to a company, but a good policy will limit you to perhaps a dozen different languages for the problem domains you'll face. If you try and compress it beyond this you'll create as many or more inefficiencies as you eliminate.
I've seen this happen before. Your company is being eaten by a political machine and evidentally productivity will go to nil, and bad things will happen as you won't be able to get any work done for all the politics you are caught up in. My recommendation is to escape while you still can. I hated seeing my company full of smart hackers turned into code monkeys, it's really not fair that these types of narrow minded individuals can ruin such great companies for people that really care about programming.
Writing good software is very difficult. I see a pattern in companies where there are (i) people with technical ability and (ii) posers who take the 30,000-foot view on everything telling them what to do at every turn.
The posers can be detected by the following:
(a) Posers tend to swear allegiance to whatever mantras are put forward to them in books, by well-meaning gurus, in whatever software-development rule book the poser has most recently read. The poser tuned out at some point in the book's more complex content, but they did read far enough in order to take away some new silver bullets, that they think makes them capable of leading a project that they don't understand and could not develop on their own, even giving 30 years of their own time.
(b) Posers believe that whatever makes inherent sense to them, should require no explanation, and should be immediately cast in stone, becoming a new Corporate Commandment. Posers lead by use of brute power, rather than by use of reason and influence.
(c) Posers don't bother to think about the fact that one language/technology/tool/method will not suit every application in every department of every company, for all time, and instead worry about preventing stress on their very limited mental abilities caused by the learning of some new language, technology or method.
(d) What posers do tend to be able to do is calm the nerves of rattled executives they report to, who don't want to understand anything about the actual problems in a given development project, but can give high level, fluffy claims about how we've "got the process under control now", and "we'll be back on schedule right away sir". The poser serves a valuable role in an organization. By being reviled from above and below, the poser is a lightening rod for negativity. This helps keep the developers actually developing and making progress towards some goal, even if the date they will reach the destination remains a mystery to the PHBs and posers.
Warren
I think you use the language best suited to the problem. Isn't that the way it has always been done? If you standardise on java, and there's something you can't do in java, by the time you standardise on something else, you've lost a lot of production time.
I hate sigs.
But .NET is so portable, why would we even consider using another programming language...
far...out
90% Standardized
10% Glue, because even an All Java, All C place won't work without glue!(Or Duct Tape, your choice).
Glue should be something like one of the following: Perl, Ruby, or Python
Years ago, I worked at a company that decided to standardize on one cross-platform (Windows/HP-UX/Solaris) scripting language. The contenders were Perl, Tcl, and (believe it or not) REXX. I was given the task of "advocating" for Tcl, I guess because I was the only one who could write "hello world" in it. In the end, Tcl "won" only because the guys advocating for Perl couldn't figure out how to make it talk to an Oracle server, but I got Tcl to connect. (REXX had fallen out of the running because only my manager knew anything about it.)
So Tcl became the company's standard scripting language. I left shortly thereafter. Shortly after that they outsourced their IT stuff. Wonder why...
I work for a large telecommunications company, and this is effectively our approach to language standardization. There are no hard standards that apply to the entire enterprise, but each solution domain (which sometimes loosely maps to organization boundaries) has its own standards, sometimes official.
For example, in the "web" domain, our standard language is Java. Our standard web publishing platform is J2EE. We have an awful lot of Java developers, and they can all move around between projects and we have no trouble getting replacements. This particular standard is official and exclusive of all other web publishing platforms.
In our "system administration" domain, our de facto standard is sh (for the lighter stuff) and Perl (for the heavier stuff). This isn't an official standard, but the tools to run shell and Perl scripts are standardized and widely available, so there's less of a headache to run these than some other type of script.
At the enterprise level, we do have technology standards dictating what versions of things like a JRE, and a perl installation, so that code that we do write will run predictably everywhere, but they don't go so far as to dictate when each language should be used.
Finally, we have an exception process, where if you can justify the need to use something non-standard, you can. You just have to justify it, and people have to weigh in with the cost risks, etc. I think our approach works well.
Let everyone code in their own .NET language, and let everyone use everyones assemblies.
.Net runs great on all those UNIX servers the company has spent 100's of thousands of dollars on. Yes, I know about Mono, but it's always going to lag behind Microsoft's implementation, for example C# 2.0 is not supported in Mono AFAIK.
Umm, yeah, because
Personally, I'm against standardization. What if your choice ends up being the wrong choice down the line (or even at the moment)? Then your stuck with the tool you standardized and all your developers are only have been excercising one skill set. Standardization is ok if its for specific tasks, for example if you say choose Java on the server-side, C#/.Net on the client side, Python for scripts, PHP for the company website, etc. But even then there should be some room to change as technology changes.
The place I work, we are pretty heterogenous and don't enforce any standardization, but we do just fine because our developers are used to using a variety of tools (and we're a really small team), and we make intelligent decisions about which tools we use. We have a tendency to use certain things for certain tasks, but these have changed and are allowed to change over the years. At the moment, our main languages are Java 1.4, C# 1.1, and PL/SQL, so its not like we are using the latest greatest shiny new language that we'd have a hard time hiring developers for. But we occasionally write in C, C++, Delphi, Python, PHP, shell scripts, and a few other languages. Some of that is maintaining legacy stuff, and some of that is using the appropriate for getting a task done.
Where I worked, we moved from the following programming "standards":
Today we're maintaining a multiple language environment because many of the "legacy" products are still used by customers and they pay us to maintain them.
Vi havas e-poston.
It's about weighing the pros and cons of the situation:
Language standardization gets you something really great -- a large resource pool of talent and experience that you can draw on. During all cycles of software development you have people who understand the strengths and pitfalls of a certain solution and can offer assistance or guidance as needed. Peer reviews and such can be more in-depth and more meaningful. Software libraries can grow and be abundant, leading to faster software development. When developers leave, it's easy to find someone to pick up the reigns (assuming you don't have some horrible spaghetti of code left by the previous developer).
But language standardization also gets you stuck in certain situations. No one tool is perfect for every situation. Some tools (like Java) are better for enterprise-wide software solutions involving Single Sign-on (SSO) and multi-platform/multi-vendor (like DB) support, but can be too slow for many situations. It can also lead to stagnation and lack of innovation.
Utilizing a "free love" of languages can be just as terrifying as well. Many new languages lack adequate libraries, forcing developers to come up with their own solutions from the ground-up. Support resources are more scarce for these new languages, meaning possibly paying for support. When a developer leaves, valuable time can be lost trying to find a replacement. And when a replacement is found, they have to try to decipher what the last person left behind and get up to speed on the project.
So which do I support? Both. Standardize, but not just on a single solution. Get a group with some core skills, but allow them to "mix it up". Let the Java folks work on the PHP/Ruby/etc. projects and vice-versa sometimes (if they want). Personally I'm always willing to learn more, but am also happy and comfortable with what I know.
I sort of see your point about having too many languages doing the same thing, but did you know that most modern web applications already use 4+ languages?
.NET and PHP apps? What is the cost for your employees to retrain to another language? Who will maintain the php app? I've created small perl and ruby scripts that would have needed many more hours to develop under Java or C#. Sure there were some developers on our team that didn't know how to maintain those scripts, but we had enough smart developers to cover it. There is a definite cost savings when smart developers choose the right tool for the job.
Choose one of PHP/Perl/Python/Java/C# to handle business logic and flow on control. Use some flavor of SQL to access the database. Throw in HTML to provide the basic user interface. Add javascript for client side features that can't be supported with plain HTML. If your application is of any size at all you've got some property files written in XML, YAML, or other similar language. Good developers probably used some variant of UML to conceptualize the design before they started.
The idea that one language can do everything is pretty silly.
Since you are pushing standardisation I assume your current environment is not standardised. Let's say you choose Java. What are you going to do with all those
And since somebody mentioned golf... how many professional golfers do you see standardised on 1 club?
I've worked in a number of large companies, and I've seen the damage caused by trying to force technological decisions (like which programming language to use, or which communication package to use) down on everyone from upper management. As a result of these experiences, I believe that most technology decisions should be made locally - at the group level - rather than at the department or enterprise level.
:-)
Software development is a team activity. It works best when the teams are small (< 6 people) and relatively autonomous. The team members and team leader are ultimately judged by the success or failure of what they deliver, and it should be up to them to decide which technologies they want to use.
This doesn't necessarily mean that you shouldn't have rules at higher levels, it just means that the higher you go the more general your rules should be. Rules like "you must use languages X, Y, and Z" are inappropriate for the enterprise level. On the contrary, a rule like "before a language can be adopted, there must be at least N employees who are familiar with it" is a lot more sensible.
From what I've seen in this discussion and heard elsewhere, the basic argument of language standardization boils down to two contradictory mandates:
1) use the right tool for the job
2) use a tool that others are familiar with
Placing the decision at the team level allows you to make a nice compromise. You get the flexibility to pick the right tool and the guarantee that the ones who are going to be most involved with the tool will be familiar with it.
The disadvantage to this approach is that you can end up with "islands of technology" in your enterprise, where a team builds a successful product with an obscure technology and then moves on, leaving the company with something that must be supported but cannot be maintained. Note that this can also happen even with familiar technologies - you can make a mess in any language.
The best guard against this scenario is to make teams responsible for supporting what they have built. There's a lot of stuff that goes along with this idea, but that's a separate discussion.
This is a concern, for the 0.01% of programs for which multithreading is actually a wise design decision. And, although there are some options for Python, if your program truly falls into that category, perhaps you should use another language.
In my experience, though, most choices to multithread programs are ill-advised, and seem to be made because that's the decider's familiar hammer. The costs associated with multithreading are huge, and should not be chosen without long contemplation.
"Not an actor, but he plays one on TV."
I know your list wasn't meant to be complete, but you missed one case that tends to get ignored a lot on slashdot. That's OK, the bulk of the people hanging out here are developers or have a development focus, so they tend to forget about the rest of the IT staff. ;)
Think of all the scripting that gets done by the network and system administrators to keep everything humming along. It's almost always unrealistic for that staff to fall into line behind a single corporate wide language that was chosen to support a completely different set of design requirements. Heck, in their case it's virtually impossible to pick a single language due to differences between platforms and availability of tools. For example, in most cases they're happy if they only have to worry about choosing between Perl, Python, shell scripts, and/or batch files on *nices and/or Windows. Then there's JCL or ?? for the big iron plus Ghu knows what for rarer platforms like Tandems.
None of the above takes into account the network admins who, in addition to worrying about the differences between (again, for example only) Cisco and Juniper, also have to have at least a basic understanding of whatever scripting language(s) their management consoles support.
Anyhow, I agree that the idea that all coding done by a company can be done in a single language is wrong for all the reasons that you enumerated, and I agree that a list of standard choices based upon requirements is very important. That single sheet of paper probably needs to grow to a sheet and a half or two sheets to cover all the possibilities, though.
The question of client value is one that has been ignored up until very recently, with areas like interaction design, and Agile methodologies incorporating client needs and goals into the day to day programming work. It comes down to this - only do what work has obvious value to the customer . The only question for these standardizers is : what value does this peice of work have? I would purport that standarizing on a language across multiple disparate teams for it's own sake has no value. So whats the reason these people have for wasting company time and money? Are they backed up in their claims by metrics, prior experience of a successful changeover, or published works backing them up? OR are they, as I would assume, going with a bad idea through lack of imagination? Trollish as it may sound, lack of imagination in people who have big ideas is a bigger problem than people realise. Those who come to the idea first, and quickly, are those who are most unwilling to change (src: http://www.poppendieck.com/ Lean development techniques). It is exactly these types of personality which graduate towards management positions, pushing bad ideas until they are proven irrevocably wrong. Who are they anyway? Are they programmers themselves? (in which case I'd be inclined to dismiss their opinion on the basis they are naturally biased to one language anyway) or are they managers? (in which case I'd be inclined to dismiss their opinion on the basis they don't know what they're talking about)
That's the key distinction. It's also, to some extent worth thinking about Using multiple methods for a given purpose just creates more of a legacy liability.
For instance, I once set down a rule for a .net programmer - all database access must be wrapped in a stored procedure or view. It was simply for consistency sake. That any database processing could be more easily understood as it would be in the SQL Server, and no-one would have to look in two places.
In another company, no program reporting method was agreed. So, some people were firing out to Crystal reports, others were using a homebrew PDF generator, and someone else was using Excel. The key problem was not that anyone was wrong, but that there was an inconsistent approach which introduced problems in maintenance. In such situations, it can become a battle of egos, with each defending their option. It's up to managers to resolve such conflict.
From what I understand, Toyota takes the approach of "consistent method", but makes sure that the method is constantly under review. If someone finds a better way to do something, they suggest it to the team, who consider its merits and then get on with implementing it.
Yes.. and no.
Developers will tend to use what they are familiar with. For example you unfortunately will get unix buzzheads writing perl scripts and crap for use in WinXP but the same effect could have easily been handled in a few lines of a batch file. been there and seen it...over and over again and that is just for the "little" stuff.
The answer is not so much having a rigorous standard that all apps must be written in, but a flexible, yet defined, architecture that allows for the right things to be done in the right language. Unfortunately most companies don't have the IT managment support to create an "architectures and standards/strategies" team to help define and guide the devlopment process, it gets deferred to whatever the assigned programmers know how to code.
Sorry, I can't imagine a situation where one programming language can do something another programming language can't. There all turing complete, of course, but more then that, all the major languages have rich apis that let you do whatever you want. Yeah, it might be easier to whip up a quick'n'dirty web app in PHP then in JSP, but that dosn't mean you can't use JSP.
The only reason I can think of to use multiple languages is to get quick access to an already existing module. If most of your work involves tying together pre-existing modules (where most of your code is already written and you just need to tie it together) you're going to need multiple languages.
If the majority of the code is going to be written by yourself and your team standardizing on one (or maybe two or three) languages is a much better idea.
I would prefer two or three languages with a standard way of communicating between them. Like for app logic, C++ for low level OS stuff, and maybe PHP for web stuff, with standard agreed upon ways of communicating (like JNI for java->C++, PHP's java extension for PHP -> java)
Unless you're lucky enough to work somewhere were every programmer can use any language (not too many places, sadly) it's much better to have a standard, so everyone can follow along.
autopr0n is like, down and stuff.
You definitely need to standardize, but don't do it on one language. I've been programming for a decade and I have yet to meet a language that did everything I could ever want a language to do.
So, decide what sorts of different problems your programmers have to solve and which kinds of applications they create. If you have teams in charge of different areas then it's safe for them to choose their own language(s). For instance, your web programmers might want PHP, Ruby and Java, so let them do it. Don't let them pick some unknown language, though.
Depending on how diverse your programming tasks are you can probably standardize on three or four languages that do everything you need. Say, Java, C, Perl and PHP. Maybe throw Ruby or Python in there as well, but having Perl, Ruby and Python is kind of overkill on similar languages. Also make sure you actually choose languages that make sense. Don't decide to throw out PHP because your web programmers can use Java because if their work can be done with PHP then they'll get more work done with PHP than if they used Java.
The global economy is a great thing until you feel it locally.
couldn't you just have netcat pipe it to your brainfuck program?
We have standardized on a single language (C#), and it has worked for us. We have a significant base of legacy code, including C++, Java, and Visual Basic. I can tell you from personal experience that 90% of the agony we endure is related to the legacy code, specifically maintenance of said code. Keeping enough people up-to-speed with skills to work in more than one or two languages is a tough challenge. Organizationally speaking, my life would be vastly easier if we could get down to 100% of our code in a single language.
Of course, that's never going to happen, so we do try to retain the people who have experience with our legacy code base. We also try to assign new people to work on the legacy code whenever it looks like we're getting short of experience in any one area.
I'm a coder by trade and experience -- this management stuff is definitely new to me. I have always personally enjoyed learning new languages/techs/whatever as a developer...but from an architectural and business standpoint, I can definitely point to reasons to standardize on a single language or development platform. We are transitioning to a product line architecture, where deliveries are based on off-the-shelf in-house components (new development as necessary, of course). Customers *hate* it when we tell them "after you install this, you'll have .Net 1.1, Java 1.5 and VisualBasic runtimes on your machine, along with all the support libraries, etc." They would much prefer a homogeneous environment with minimal footprint.
There are also issues within a product line with mixed-platform development. Unless you work *really* hard on decoupling components at exactly the right places, mixing platforms makes it difficult or even impossible to develop a solid product line. I'm starting to think that it's actually impossible without going to a full-out service based architecture.
So don't dismiss the idea of standardizing on a single language. Just because you're a developer and you want to play with the latest cool toys, that doesn't mean there is a defensible business reason to allow that.
Maybe all companies should standardize on one programming languages. Maybe none of them should. Whichever it is, the last thing we want is a big mess where some companies do and others don't. Sheesh, let's have a standard here!
Seems a better choice would be: Pick one from each group:
And then exceptions should occur for anyone who needs more advanced capabilities from their languages (Haskell, ML, the K language, Lisp, etc).
Unfortunetly there are not really enough non-halfwits to go around. It would be nice if all software could be written by CS-Gods, but that's never going to happen.
It's always better to hire the best, and pay for it, but most bosses don't see the value. And some projects can be done by less then the best, if there simple enough (of course, for a non-technical person to figure out which are which are which isn't always so easy)
autopr0n is like, down and stuff.
Just ask yourselves a question? On what lang would you standardize 2 years ago?? 5 years ago?? 10?? 15??
standardization that changes every couple of years due to vast technological changes isn't standardization after all.. Who would choose C# 5 years ago as the standard?? Java 10 years ago?? It makes no sense..
My $0.02
www.lemonodor.com A mostly Lisp weblog
Corporate level standards should be about the process, not the implementation. I headed up the SQA effort for a well known company that does embedded systems in the audio arena, but the points carry over well into a more general context. Given the variance of platfrom and already in use and tested code base, standardizing on a language would be ludicrous. Should a tiny piece of software running on an 8 bit microcontroller really be written in the same language as the multi-megabyte user interface tool? Of course not. If you don't pick the right tool for the right task, you completely throw away the fundamental premise of Software Engineering.
Want to standardize? That is good. Standardize on thing like:
1) What should be documented in order for a product to be released?
2) What kind of comments (not format, substance) should be in the source?
3) How you will handle configuration management (Clearcase? CVS? Cervasia?)
4) What kind of code reviews will happen, and what documentation must be provide to prepare for them?
5) How will requirements be gathered and approved, and how will that be documented?
6) How will testing be done? What amount and method is appropriate? (need to avoid Godel incompleteness and minimize Heissenburg Uncertainty)
7) On a project by project basis, what criteria will be considered during the process of selecting the language and associated development tools to be used?
.. and that is just the short list.
Unless all of your products are remarkeably similiar in all aspects, mandate of implementation method (e.g. language) is a VeryBadThing(tm). It shows that there is little understanding of what Software Engineering is, and a confusion between programming as a task performed during the implementation phase of an engineering endeavor, and programming/hacking as the beggining and end of software development.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
We tried to standardize on Java but it turns out that java wasn't the best solution for all situations. It "can" theoretically do everything since it was cross platform in our environment.
Since that disaster, we approached to using what we felt was the best solution for us for each project even though we were going to have a mixed environment. We used perl and python for testing, maintenance, web apps and utility scripts. Java was still being used for larger web applications. Like you wouldn't write a java application just to sent email reminders via cronjobs. Throw away scripts work well for that sort of thing. And now C# became the solution for us for building GUI applications.
"If a show of teeth is not enough, bite
In my experience, inter-language boundaries have been a chronic problem that can eat up a lot of engineering resources.
Examples: (1) having to link Pascal, C, C++, and others together in a single EXE; (2) maintaining a binary datagram layout in multiple languages; (3) re-writing the same functionality multiple times, each version tailored for the unique strenghts and limitations of a particular language.
In every case, we would have had a very significant advantage if we had the luxury of a single language.
We've been standardizing on C# for the past 2 years, and we're starting to see the tremendous benefits of having every piece of code being naturally compatible with all other pieces of code. It's starting to create a level of productivity that we have never seen before in the long history of our group.
When your only tool is a hammer, every problem looks like a nail.
Really was limited. And you couldn't just emulate it with function pointers like you can in C.
autopr0n is like, down and stuff.
Today: Give absolute liberty to a "hacker type" to arbitrarily choose languages and libraries for any significant project without having a good reason for it.
The rest of the life of that software: Pay for it by having bugfixes and improvements take 10x more time because of the learning curve for some obscure language or library or because some of the used libraries aren't supported anymore and have bugs.
[Did i mention that the "hacker type" that did the project (and had his fun) is now long gone from the company leaving behind a string of applications, all done in different ways and all needing to be maintained?]
In my book, as somebody that has been both in the making side (started as a "hacker type" myself) and in the taking side (as freelancer i often have to maintain/upgrade software done by said "hacker types"), no "hacker type" ever makes the grade past "junior software developer" before he/she has had to maintain his/her own software a year or more after the software's first version was in production.
Unfortunatly our industry has many self-masturbating "hacker types" that never have to clean the mess afterwards
There have been historical examples of languages that hit large sweet spots of "general use". Fortran, C, Lisp, Pascal, Java, C#...all of these are usable for probably 90% of programming tasks. There has been a break from "true" general purpose languages with those that require GC, they aren't suitable for system development as delivered. (I do think there's a lot of interesting stuff to be done on the hardware end to make GC and memory systems in general work better.) Back to my original point, I think it would be unbelievably beneficial to the computer science world if there was a single dominant language for most general-purpose programming, to include system and embedded programming.
How much money and time would be saved if most programmers could have a productive career only learning and using one language? How good would the compilers be if 90% of compiler companies focussed on improving and optimizing one language? How good would programmers be if they focussed on mainly one language for their entire careers? Java is trying to fill this niche, but I don't think it's a great fit, read on to find out why.
I find it puzzling that so much focus is currently on VM oriented languages. With the focus on the hardware end of things on "performance per Watt", one should realize that software is an extremely important part of the performance equation. I think the days of massive, gratuitous abstraction for the sake of abstraction may be drawing to a close. I also think that VM based languages had better "walk the walk" of compiled language performance, or they'll become yesterdays technology (p-System Pascal all over again). Those who don't study history...
All that said, for me if there is to be a single dominant language, it must be:
I'll take these on one by one.
"Performant" means "performs as close as possible to the theoretical maximum". A good starting goal would be 90% the performance of hand-tuned assembler.
"Safe" means "it requires effort to blow my leg off". (Something like Java's security model might be added as a layer if necessary, but wouldn't be part of the base language due to performance concerns.)
"Portable" means the usual thing - programs will compile on multiple architectures and operating systems, and produce similar results.
"Extensible" means the language can be extended in meaningful ways without a new compiler. Lisp, Scheme, and Dylan are all examples of languages that provide a good deal of this type of functionality.
"Interoperable" means that the language can efficiently interoperate with legacy and other code, e.g. an efficient C calling interface.
"All-level" means that, ideally, the language should naturally lend itself to systems running the gamut from small, possibly hard realtime, embedded systems, to the largest distributed systems. It should well address all problem domains from numerics to string manipulation to parallel processing. Ideally, it should provide a subset of some kind that works well as an interpreted scripting language, so that once again the cognitive overload of having to learn and remember many computer languages is reduced.
"Available" means that not only must it exist ;-) it must be obtainable at low or no cost. Many very good languages *cough* Smalltalk *cough* have died on the vine since few wanted to spend the money to play with them.
I've been looking for a reasonable fit to these criteria for a long time. The best thing I've found so far is Dylan. It's not perfect, but it is quite good. It even fu
Galileo: "The Earth revolves around the Sun!"
Score: -1 100% Flamebait
"John, I want you to build me a house. And I want you to build it with just a hammer."
One approach my company uses is multiple standard languages.
Core tools by design teams use C/C++, and define their own strategies (for example, banning inheritance).
Flow design teams that use scripting languages allow Perl 5.61/5.8 and Tcsh. No Bash, Ruby, Python or Java: there are too many people working on this code to achieve working competence in so many langauges, so focus on two. Programmers are not allowed to write official flows in anything but Perl or TCSH.
There are two simulators written in LISP, but these are third-party tools, and the people who own deployment of them go to the ISV site for an intense training program (in LISP and the tool).
So basically, we standardized to 3 major languages, and 1 due to ISV constraints.
And it still has problems. People that have more breadth in Perl do things that confuse the hell out of noobs (and noobs are a part of life, folks!). In general, I like it, because it means I don't have to master 12 languages, just three.
https://www.accountkiller.com/removal-requested
It depends on your environment.
If you have a bevy of Java programmers, and you're developing web-centric B2B applications, mixed environments don't make sense. However, if you're a game developer that also provides web-based content and features (such as Clans in some MMORPG games) then a mixed environment makes much more sense (C++ for game dev, Java and/or PHP for web dev).
The original question, however, said they were considering standardizing on a single language, which is a dumb idea. It sounds to me like they're conflating the good idea of having standards with the bad idea of having a standard that doesn't respond to requirements.
If you are a desktop apps or embedded library company, you might want to standardize on C++; if you are a server-side enterprise software company, you will want to standardize on Java.
But there will always situations where one language is not the best choice, and that choice should remain developer's choice and not a management decision.
Important factors in the standardization debate are: is the language an ISO standard? Does it have tool support (compilers, libraries) on all relevant platforms? Is the language mature? Is the language general purpose? Is the language difficult to learn? Does the language have a large enough user base?
In the EU, there are many official languages, and this diversity a political statement in favour of a pluralistic society and multi-culturalism. But it comes at a cost: a large budget is waste...erm spent on translation. Same holds for programming: for a while I have developed Java library, nowadays I use a lot of C++, and get what, I have found myself re-implement my own libraries in another language, so bear in mind the cost benefits for reuse.
Just lettin every one do what he wants is just as stupid. You'll get a big mess. The best way is that the design teem for each project pics the best tool for that job. You might add some guidance that "best" should strongly concider ease of meaintancance.
Butif you have a smaller company that only did projects that were all very much alike then they could standardize. Even then you need to look at eceptions. What if the standard is C++. Does this mean you can't write a shell script?
Different OSes, Langauges have different advantages...
... you may have to merge both ways to do that thing into
Choosing one is a mistake. Excluding some for certain uses
however, may make sense. It should be for a good reason like
a security requirement. If it later meets the requirement it
should be avialable.
Systems sometimes do a useful thing that should only be done once.
Those systems should export a stable API in addition to that nifty
web form thats always there.
So the department that needs an extra field can call _that_ one and
its own function.
This real problem requires leadership and inter-department exchange of ideas/people ect...
Its the exchange of people and ideas that is important _not_ that
everything is done in one langauge. You will still get people doing
things more than once even if you have one laungauge. (This is not
even bad necessarily depending on what the function does as it may make
a future API changes _less_ disasterous) Additionally, if one codebase
rules them all
one codebase! (ick)
So the point is. Make sure people meet, give talks to each other's
departments or sit in on each other's meetings, know thier peers or
counterparts names, ect.
Thats what matters.
If you must standardize something. Have central resources _available_
using open standards to foster interoperability. A central LDAP server,
a central CA, KDC, SQL server. Don't force people to use them. Reward
departments and people that do.
Garick
It's a funny thing. Multi-language proponents are right, on the face of it. But human languages have the same kinds of limits as programming languages. Some are naturally better at discussing certain ideas, or at creating certain atmospheres. To see why companies want to standardize on one programming language, ask yourself why you only use one natural language in your thinking and speaking. Why not add an Asian language to your toolkit? A modern-ish language like Esperanto? The same personal limitations that cause you to be stuck with English (at least as you read this!) are the personal limitations that keep programmers from being fluent in multiple programming languages.
There are lots of reasons to attempt to standardize on one language, but I'd be wary of it. But not for the reasons you'd expect.
The primary reasons for standardization given are typically future compatibility and cost. Future compability is a valid reason - if the language you're using is going out of use, eliminating it from your systems allows you to continue to use your systems, plain and simple. Your system must survive.
Cost is a different issue. If you are using language X, where the vendor charges ever increasing $$$ to supply the compiler, a switch may be necessary. But in some of the large companies I've worked at, the standardization and cost savings do NOT come from these areas. They come from decreased cost of labour. i.e. programmers become cheaper.
In a company of 300,000 , if they could somehow standardize on Java as THE ONLY language they use, it would be of huge benefit to the company. they could move people from one project to another so much easier. Hire directly out of college. develop standard costing metrics and procedures. but where do the savings come from? they no longer need the C++ and cobol programmers. The value of any individual programmer goes down - way down - because they can so easily be replaced. And it would have a ripple effect outside the company as well. Java programmers would be dime-a-dozen.
I'm all for efficiency. Heck as a CS I think it's ingrained. But I recognize my value comes from the skills I have that other's DON'T have. Not the commonality. Specialization can mean unemployment, but it also means a limited work pool. and reasonable wages.
This doesn't apply to small companies, since they don't have the ability to drive down their internal costs by standardization, other than eliminating positions that become redundant.
if they want to standardize, tell them to standardize on a language: ENGLISH. Seriously. Next document that get's published must check all words against the Webster dictionary. Any acronyms or industry specific jargon must be removed. Then think about standardizing your programming languages. It'll look completely different then.
The company I work for is a Fortune 500 defense shop. Standardization would be a terrible thing. If you can think of a language, we probably use it.
C / C++ / Ada / Fortran / Java / C# / Tcl / VB / Pascal / Matlab are just the languages I've seen in use PERSONALLY in the last 5 years here. I'm sure there are more that I havn't encountered. And no, having all these different languages hasn't caused a problem, because it's fairly easy to retrain people on new languages.
Standardizing on one language not only kills your flexibility, but it artificially stunts your room for growth. If you standardize on one language, then how do you decide when it's best to jump to the next language?
In my company, some projects are at the fore-front of new languages, while others use older, more established languages. It depends a lot on what the customer wants, and how much you can reuse previous projects. Now, that's not to say we havn't "standardized" in a way...we've naturally gravitated toward C++, because we are an embedded house. This gives us most of the benefits of an organization that has totally standardized on C++: lots of experienced C++ coders, and lots of reusable code, without being locked-in.
Man is the animal that laughs.
And occasionally whores for Karma.
One that we have here at times, only under differing guises. To end the arguement early I would ask "Why cant we just do everything in Perl?", and the response would be "Perl hardly makes sense in a multitude of situations, for instance you wouldnt use perl to build a packet router".
And I would say "and C hardly makes sense when you want a scriptable telemetry data simulator". So we use at least two languages here as long as you dont count the cases where we use C# for win32 gui's, java for some corba interfacing stuff, VB for program/device monitoring (on win32), etc.
There is no 'silver bullet' language so why would you force yourself into treating one like it was? Any time you might have saved by not having to learn a new language will be eaten alive by the time spent trying to shoehorn a problem into a your chosen languages paradigm.
Really, all languages suck, some less than others, but its really contextual.
To really break the arguemtn you might say something like "When we standardize on a language we will also standardize on the types of problems we can address competitivly".
At least thats the way I figure it.
I think you underestimate just how much I just dont care.
The lion tamer that runs into the cage armed with nothing but an innocent air and a blindfold doesn't stay a lion tamer for long;-)
On the other hand, you could choose not to work with a feral beast that will bite your limbs off for the macho thrill of it and get a nice loyal dog that does what you tell it instead. YMMV.
If it's for-profit but free, you're not the customer -- you're the product (e.g., the Slashdot Beta's "audience").
This whole 'standarization' thing is just plain stupid the way most companies do nowadays. And here is why: it makes almost no difference in standardizing stuff to one language if your programmers are shit.
... so we end up with standardizing on one language to produce shitty apps that run in different app containers. And don't any of you tell me that a WAR can be deployed in any J2EE compliant container. Maybe an example pet store WAR can, certainly not a complex app, and much less if it's written in a pretty shitty way.
At work we have all this apps written in CF and Java, and most of them are just shity work done by software engineers with skills comparable to a sophomore student. So take a shitty CF application and translated to java by a shitty programmer, and what you get? A shitty java application.
Right now I have a whole bunch of apps written in Java, a lot of them converted to it from CF in a stardarization effort. I would have preferred that these morons never had touched anything. What's worse (and which I've seen in several places already) is that you end up having shitty java apps, some of them poorly written to run on tomcat, others poorly written to run on weblogic and so on and so on...
My take, based on developing, admin and support experience is "if it ain't broke, don't touch it." But in this world full of shitty programmers and dev team leaders, that will be like wishing for world peace or something.
Standardizing on good coding techniques and enforcing them is at least as important as the language its written in. It could be that some languages lend themselves more readily towards abuse then others (Perl vs Java?), but bad code is a nightmare wherever it shows up.
Standardizing on anything (language, IDE, RCS, anything) should be done for a clear business purpose. The first question to ask is "what business purpose are we trying to accomplish?"
> The pro-standardization guys say that a single language (like Java) will save everyone time.
What is the current cost of lost time to your business? How much time will you save by going to a single language, and what will the dollar return be? If you can't answer these questions, then standardization -for the purpose- of saving time is premature.
> The anti-standardization guys are advocating a mixed environment (of
> languages like Python, Ruby, and C#), and argue that the whole discussion is
> as silly as a manufacturing firm standardizing on screwdrivers for all their screw/nail/glue fastening needs.
How many types of needs has your company had, historically? Do you write 2 or 3 different types of applications, or 20 or 30? What procedures have been considered for allowing a new language when needed? Who reviews the proposal? How long will it take?
It's useful to choose standard tools, standard procedures. It's also a common cause of failure when the company can no longer react quickly.
I have never know a successful firm that standardized on -one- language. I've known several that standardized on a few, for different purposes. I can't honestly say that, on average, they were more successful than the many successful firms I've know that never standardized on programming languages at all. As far as I can tell, standardizing on a few languages had no impact at all on the business.
One final thought; in my experience -language- is one element, and not the most important element, of application development. If your company haas effective development standards that deal with most other aspects of software development, feel free to look at language. If you haven't, -don't- start with standardizing the language. Start with standardizing the higher level elements of the development process.
I've worked in a larege software company and they didn't standardized on the programming language but standardized structure and methods. This is a way if you many hardware platforms, operating systems and programming languages an person on another platform can have an idea what they looking at.
I currently work in small shop and we use primarily open source and I noticed that each programming language has it capabilities and pitfalls so I use many of them.
I don't think the problem space addressable by a particular language is all that narrow. For instance, at my company we write web-based, rich-client, distributed enterprise software that helps companies run marketing campaigns. One of the products we sell is primarily written in C++, and it's a nightmare compared to Java. Turns out that if "networked enterprise app" turns up in your list of requirements, Java's going to be a better bet than C++. The functionality of that code has not increased nearly as much as the Java product I work on. While those guys twiddle bits and try to find memory leaks, we add features. Several of the C++ programmers have realized this in the last year or two and are all trying to transition over to the product I work on because they're tired of the spaghetti that comes with overtaxed, underfunded development. The business is unwilling to devote the resources to their project because, even in their hey dey when the product was first developed, they couldn't add features as quickly as we can (mysterious linker errors, non-standard threading tools, memory problems, etc).
The management consoles that run each of our products are written in VB. We had one guy that did that, and wrote the installers for our software, which required a smattering of Java, C++, and VB working with InstallShield (I think--I don't really know, I've never looked into it, but that's my impression). He left. Now we have to find someone to replace him that can and wants to do all of those things, which is impossible. So we've made the more sensible choice to obviate the need for such a person by redoing our consoles in Java. This will not only make the code easier to maintain, but it will allow us to add a whole raft of features we couldn't reasonably add in VB.
I've worked for big blue-chip companies to small startups. I've done consulting. The one constant I've seen of successful business is that a well-run business is trying to solve a problem or related set of problems. Most of the time those problems, if well-defined, map to a solution space that can be addressed with a limited range of technology that is intended to work in that particular space--if they're not, the business is split into divisions and those divisions are run separately, as when I was at GE.
Sometimes companies choose technologies that aren't designed for that solution space because they're familiar with it, and that's usually a bad mistake, but more frequently, and worse, I've seen companies adopt the approach that everyone at a low level should make the decisions on a case-by-case basis, as if the business unit isn't addressing a problem domain that is in some way a cohesive whole. Every company I've been at that does this winds up like my current company...they eventually bump up against the limits of the inappropriate technologies and run into manpower and hiring constraints that could have been avoided.
but have you considered the following argument: shut up.
What is the set of problems the business as a whole is trying to solve using software? Tell us that, and maybe someone can take a stab at this question.
but have you considered the following argument: shut up.
I know the parent is talking about the programming language ADA, but when I first saw the title, I thought about the Americans with Disabilities Act.
What if some programmer suffered a head trauma and is unable to learn the new language but was still able to function at a proficient level in his language of choice. Wouldn't it constitute discrimination to force him to use the new language and then fire him for incompetence?
Think about it: we're required to have elevators in 2-story buildings because it's discrimination to say the guy in the wheel chair can't have an office on the 2nd floor. Part of the argument goes: what if someone gets in a car wreck and then becomes incapable of making it up to his/her 2nd floor office.
So can't I say "you hired me for my knowledge of C, and now you want to standardize on Java; therefore, I'm going to sue under the ADA!" ?
I don't see the relevance of your question about my assembly skills. The point is, I could program in assembly in industry if I wanted to, but that doesn't mean I'd like a job doing Java and assembly. It's nearly always more productive to specialize in one area, know the hell out of it, and do that.
Incidentally, as it happens, by pure chance alone, my experience with assembly is relevant to this discussion; I worked with assembly/C/Objective-C/C++ for a year for an R&D-type project and wrote an operating system. An OS is an example where the problem domain maps to a solution space that must cross all levels of software capability (by definition, in fact). In that case, it was appropriate to have people that devoted time to each--at least until the project got large enough to allow segmentation of skills (it never did).
Basically, I agree with you about Java. It is a pretty boring language. Programming languages in general are boring. I've probably written in over a dozen and I would claim some level of expertise in half a dozen. Does that make me a better Java programmer? You bet! Does it mean that my current job should exercise all those languages? Absolutely not! The desire of some coders to keep all their language skills sharp misses the forest for the trees (in possibly the best application of this cliche I've ever used). If you're focused on languages, you're not focused on problems. In my way of thinking, it's the problems that are interesting, not the tools, just as a concert pianist will tell you it's the music that's interesting, not the piano keys.
In fact, I'll go one step further. I *like* my programming languages boring--boring and predictable. It's the excitement caused by all the memory leaks and mysterious linker errors that make C++ such misery. If you're not finding Java a fun language, but C++ is, it's perhaps because the problems you're solving are so boring you need to erect artificial obstacles to make it interesting and appealing to your underutilized brain.
If a business is well-conceived and well-run, the problems that your business unit is focused on solving ought to be related enough to solve using a limited set of technologies. This is basic KISS principle stuff, I don't understand why so many coders think their field is somehow exempt...it's like the great Einstein said: make it as simple as possible, but no simpler. That means it's probably not a good idea to chuck in every technology under the sun if it's unnecessary.
If I go to work for a telco company, they have a couple of problems to solve: they want to provision services ordered by their customers, they want to bill their customers for those services, and they want some kind of on-line portal that allows customers to do account and order management. I should not have to be a Renaissance Man of Technology in order to contribute to that company's fairly tight set of goals. It's networked, enterprise software, there's a web component, so it's a Java stack: XML, EJBs, etc. You might like C++, you might like Delphi, you might like Scheme--they are simply not appropriate for such a business. Most businesses are like this--most businesses do not do small-scale OS-type projects that have to cross several solution spaces wrt technology.
In the past I've worked for such businesses, and I have felt very important as I was recognized as a Renaissance Man of Technology--I had little trouble moving from one to the next, and it was a very satisfying space for me to be in praise-wise and during 6-month review time. The rest of the time it wasn't so great--I spent more time dealing with integration problems that were a function of our technology choices and less time dealing with problems related to business logic that would actually make customers happier, bring in more revenue, and take over the marketspace. And that same skillset that made me such a boon to my bosses was required of *everyone* I worked with. For you developers out there: how many places have you worked where every last person was compet
but have you considered the following argument: shut up.
Variety does not always mean good. For instance, if your job includes new and interesting problems and that's the variety being added, great. If your boss wants to add to that list dancing like a monkey while he throws golf balls at you, that's certainly an increase in variety, but I would not consider it good.
Still, it would be a tough choice between that and going back to C++ from Java.
but have you considered the following argument: shut up.
Howdy -- I'm interested in writing apps with Erlang/OTP as well. Any tips? It appears there is a close-knit community and lots of experience in clumps here and there, by not much published material. Cheers, aristus@gmail.com
Sometimes seventeen/Syllables aren't enough to/Express a complete
Hi!
I work for an electronics manufacturing company--and develop software. I'd recommend standardizing on a very limited number of development tools, and standardizing on a limited number of fasteners.
First, the development tools
There have been 3.2 zillion posts already arguing whether to use a single language or to use any language anybody wants. That's not really the point: what you need to consider is the number of technologies, or skill sets, that you will support. Competency in a language is a skill set--but so is competency with a database server (in addition to the server's database language, like Transact-SQL or PL/SQL), or competency with different libraries or third-party tools. How you decide which skill sets are important is where you demonstrate your wisdom and skill as a manager--but it is crucial to your long-term survival to keep that number as low as possible.
If you've been around application software long enough, you've probably been on a project that included a bunch of this-will-save-so-much-time tools--custom controls, third-party libraries, etc. And then discovered that your team was totally, utterly, fsck'ed when you went to release version 2, and discovered that the libraries had changed, the custom control vendor had gone out of business (or his mother made him get a real job), etc.
It isn't just the risk that the third-party tool won't change with your product--you are also dependent upon the one or two people on your team who mastered that particular tool. If they're gone, you now have to figure out who to task with taking over responsibility of being the GridDotWhatever guru. The more of these skill sets you have to support, the tougher it is to manage a team--and the more bodies you need to keep on a maintenance staff when it is time to scale the development of that product down.
In short--count up all the skill sets your company uses, and do what you can to reduce the number. That's a good strategy.
Limit the number of fasteners, too
The original post includes a comment that standardizing on a language would be just as silly as standardizing on a particular fastener. Well, guess what: you should.
In the real world of manufacturing there are a zillion bits and pieces that go into a product line. If you can use the same micro-processor across a broad range of products, you can achieve economies of scale in purchasing, and you can achieve economies of scale in other areas, like writing code for that particular micro family.
The same is true in lots of other areas--all the way down to screws. If you standardize on a particular screw (say, for instance, 4mm metric-threaded hex-heads of various lengths) you can achieve substantial economies of scale in purchasing, but in all of your manufacturing operations. Machine tools can be fit with bits to drill appropriate holes, robots can be equipped with nut drivers for the 4mm hex head, and so forth. If you permit the kind of anarchy in your mechanical engineering department that the OP's colleagues think is good for programming, you'd have a disaster on your hands.
There's an engineering point, here
There are people who think that software is a form of engineering. I'm not one of them--and this article is a good example of why. There is lots that we can learn from engineering--and there is oodles of stuff that real engineers have known and practiced for a long, long time that we still don't know enough about to even ask. But that's another rant for another time....
One of the recent buzzwords in the industry is Service Oriented Architecture.
That is, if your business logic is wrapped up in various services and events, things you can publish and subscribe to... something. It doesn't matter whether it's written in Java, C#, or COBOL.
I'd say anybody who thinks code reuse involves cut-n-paste, has no coherent vision.
Standardization lasts for a while. Then the paradigm changes. I remember back in 1998 hearing some old greybeard rant about how all development at the company was done in COBOL on the mainframe. That was the standard. Anything else was verboten!
He no longer works there, thank god.
First a comment;
I have never seen a company that believed standardization of language was an important issue and stayed in business longer than 3 years.
That said, you are already probably doing something at where you work.
The new guys should conform to what everyone else is doing.
If they want to do something different, they should be the ones to provide evidence that the new way will be better.
Ask them for it.
-- Should you believe authority without question?
[I object to .NET because] Gee, what if I have to write software for something other than an Intel-based PC?
Like Java technology, the Common Language Infrastructure is based on a virtual machine that may be ported to any architecture, memory permitting. Or are you talking about systems whose RAM Is measured in kilobytes?
software should be written in languages that are based on international standards.
The CLI is an international standard (ECMA 334), and the C# language is another international standard (ECMA 335).
Usually the programming language barrier is only a minor one. As long as you generally understand pretty common computer science and programming principles, you can pick up on any new language relatively quickly.
Usually the much larger barrier (to employees within a company switching to different projects/products) is all the "insider knowledge" about the architecture of the codebase, build process, runtime architecture, awarness of the existence of shared libraries/functions in the codebase that should be picked up and used rather than reinventing the wheel, etc. In my experience it can take anywhere from 6 months to 2 years for even a very competent and experienced developer to learn all that stuff well enough to be fully productive on a new codebase.
Also, in my experience, the biggest way to combat that is not with documentation, but through quality face-to-face education and quality code analysis/understanding tools such as Source Insight. Anything that allows you to more easily grep the architecture of the codebase and find existing helper functions across a huge codebase is a major help. And it's also my opinion that whenever a new project or development cycle begins, it would save all the newer developers a lot of pain and time if the seasoned developers on the project/product would proactively host educational training sessions outlining the high-level architecture of the code/build process/etc.
Moderator hint: a comment is neither "Flamebait" nor "Troll" if it is true.
at which point they shut them down with patent infringement lawsuits.
Have you read Mono's page about this issue? Microsoft has already permissively licensed any patents that are used in the portions of the .NET framework that have been submitted to ECMA. The worst thing that could happen is that ASP.NET, ADO.NET, and Windows.Forms might get yanked, but from what I've seen so far, most of Windows.Forms is similar enough to prior art. Or if you are publishing your own programs for the .NET framework, you can use Gtk# on Windows too.
How many system has the complete .NET framework, including compilers and libraries, been ported to?
It may not yet be as widespread as the UCSD p-System was at its peak, but it's getting there. See Mono supported platforms.
you don't use a hammer for inserting and removing screws, right? You should also not use VisualBasic for developing an operating system, and you should not use Assembly for rapid application development. Languages are like tools, so you use the right tool for the right job. I would also go even further to suggest that we should use multiple languages per software project, when possible. Obviously I am against language standardisation.
There's a difference. Projects should standardize on a set of languages/systems appropriate for the requirements. If the system is a web application, it does not make sense to use MySQL for some things and Microsoft SQL Server for others and to mix ModPerl and ASP and Java and C or C++ CGI applications all together. You'll end up writing tons of buggy interface code to pass data around. So at a project level, it makes a lot of sense to standardize on what tools you will use and to not add tools without good reason.
At a company-wide level, it makes less sense. Some projects may need to be as fast as possible and will need to be written in C and assembly and tuned for particular hardware. Some projects may be a web server application that just needs to run on any IIS server with SQL and only needs to handle 100 transactions per minute. Maybe there is a project like a user application that needs to run pretty reliably on any Windows XP machine, but doesn't need to run very fast. Maybe there is a project that just needs to translate or reformat large amounts of data, but it doesn't matter if it takes 1 hour or 1 day, as long as it runs. There is a lot of variation in what may need to be done and each project should choose the right tool for the job.
Btw, developers can pick up any language pretty quickly. They'll quickly learn the tricks about why one language is more suited to a particular task or development style (object-oriented, procedural, functional, et cetera). Ultimately, you'll end up with better more experienced developers.
My other first post is car post.
That is a very good point, and I realise that I am being hypocritical in not liking Java after not using it professionally, when asking if you didnt like assembly because you hadnt used it professionaly (or maybe that wasnt so much hypocrisy as just checking that you hadnt had the same experience as me). Thankfully I dont consider C++ so spectacular that I use it for everything.. I learned how to develope apps using Delphi before going to uni and still prefer to use Delphi just because it's quick and it works (though it does have some quirks).
Also I'd just say that building an OS doesnt necessarily 'cross all levels of software capability', as you can design a basic OS, then have third parties add on stuff like 3D libraries and all the device drivers. So building an OS doesnt even necessarily cover all levels of hardware or software, though it maybe could if you were someone like Apple.
And going back to your saying that problems should be more interesting than the languages, that again is one reason I didnt enjoy university at all. EVERYTHING seems to be about the web these days, and I have always had an interest in networks, but if I was going to code a networked app I'd prefer it to be a multiplayer game rather than the web front end stuff we were doing at uni - anything at all to do with the internet seems to be spectacularly boring to work on. I always tend to wish I was a coder in the 80s! - when code had to actually be written well to get the best out of hardware etc.. these days I expect most people write quite inneficient algorithms etc and expect the computer to do the hard work.. maybe I dont give people enough credit though. And I know it's possible to write efficient code while still making it readable if you document it well.
which is totally what she said
Jeff Duntemann called Eiffel "ada done right", and he's a guy I trust for knowing what he's talking about ( my first "it works for me" assembler book was wrotened by 'im ), and he found the programming-by-contract paradigm and the .. sorry, but the concept-shape in my memory translates as "sustainable-correctness" .. of it to be worth-getting, and what I know about Erlang could be printed on the period at the middle of this sentence ( yes I've just glanced at erlang.org's beginner-stuff ), so I'm asking you which should I learn, for what process-reasons, for what problem-domain-reasons, in essence why would you recommend Eiffel over Erlang, and why would you recommend Erlang over Eiffel ( I want to get your sense of where each is better, since you've very-seriously considered Erlang, see )?
I'd decided, already, to standardize me on Ruby ( agility & clarity ), Eiffel ( for high-integrity infrastructure that needs to be compiled rather-than scripted ), possibly OCaml ( just because what I've read of-it indicates it's good for engineering type problems ), and possibly Pliant ( No Weak Points, rather-than good-for one particular kind of problem/domain or kind-of-thinking. . . )
I want at-most 4 languages, orthogonal to each other ( enough ), to clarify my mind, so I'm concentrating on the problem-solution rather-than wrestling-with arbitrary or bizarre language curlicues, and therefore have much-greater probability of rooting-out the problems, wrong-assumptions, wrong-paradigms, etc, as compared-with ones who are caught in lower-level-thinking, or being "caught in the groove" of the technology, if you see what I mean. . .
This is sorta like my decision to standardize on English, Japanese, Arabic, and UML2, since one is structural-implication, one is indirectness, one is emotion, and one is schematic, and if one's mind is in the habit of knowing in these four profoundly-different kinds of ways ( and in not being raptured by roccoco detail ), then one isn't very likely to be thrown by some problem-assumption as others are, eh?
( FYI, I'd be using http://www.pimsleur.com/ language-training for the human-language stuff, since I've already experienced how it blows-away the conventional competition, for effectiveness in training/learning. . . they're awesomely good, in how well they work. . . )
IPTables enhancement Fail2Ban bans cracker-login's
4 years ago my manager decided that we should standardize on a single programming language. She wanted it to be Visual Basic, since she felt it was easier to learn, and therefore there were more VB programmers out there. I was (and still am) the only developer in the company, but instead of feeling threatened I made a point of voicing my concerns, and then agreeing to do whatever she decided.
:-)
Well, a project came up shortly after, and I began in it Visual Basic knowing full well that it was going to be a pain. Getting an idea of the scope, I put forth a time estimate that she didn't like. I then ran down how I would accomplish various items in VB, and how I would do it in C, which would be easier. I then detailed out why the C method would work using VB.
After explaining that I wasn't trying to get her to change the policy, and her inquiring with some other developers elsewhere about how they would accomplish the task in VB, she decided that we would instead allow VB and C.
Then we added Perl to the list.
Now she is no longer employed here.
Smalltalk is highly legiable. Any new language style you learn is obviously unfamiliar at first seems unusual. Smalltalk's syntax is simplier than most langugages (C, Java, ...) and is easy to learn. (See the example in the other responses to the above (parent) message).
Smalltalk.org has free online books and links available for learning Smalltalk, including tutorials for those familar with languages such as C, C++, Java... See http://smalltalk.org/smalltalk/learning.html.
when everyone uses java, everywhere.
If it were done when 'tis done, then t'were well it were done quickly... MacBeth