Forgot your password?
Programming IT Technology

What Makes a Powerful Programming Language? 1332

Posted by Cliff
from the blueprints-for-next-generation-computing dept.
A not-so Anonymous Coward queries: "My company is about to start development on a new project, and I have to decide on a language and development environment. My boss gave me a set of criteria which needs to be filled: intuitive and easy to use IDE; simplified GUI design and event handling; advanced error handling; advanced object oriented design including multiple inheritance, abstract classes, and garbage collection; full support for operator and function overloading; and portable (at compile-time) across various platforms. I have already looked at C++, Java, C++, C#, Eiffel, and even; I may be missing something but as far as I can tell all of these languages are missing something from this list. Is there a language available that has all of these features? I thought that someone from Slashdot would be able to point me in the right direction?" If you were to design a language from the ground up, what features would you include and why?
This discussion has been archived. No new comments can be posted.

What Makes a Powerful Programming Language?

Comments Filter:
  • Python (Score:5, Insightful)

    by javaaddikt (385701) on Monday February 11, 2002 @05:33PM (#2989489)
    of course. All of the above, and rapid development. And you'll actually be able to maintain your code base 1 year from now.
  • I wouldn't do it (Score:1, Insightful)

    by GuyZero (303599) on Monday February 11, 2002 @05:33PM (#2989491)
    If I were to design a language from the ground up, I wouldn't do it.

    The whole idea is to use something standard so that it's simple to bring new people up to speed and apply techniques that other developers have discovered.

    It would be akin to building a bridge using a completely new, untested building material. Not my idea of a good engineering decision.
  • Simplicity is good (Score:3, Insightful)

    by jdesbonnet (22) on Monday February 11, 2002 @05:34PM (#2989507)
    All those features used together is going
    to make a big mess, IMHO. I think your
    boss needs some education in computer science.

    I'd recommend you look at Java and Python.
    Operator overloading is not a good idea I think.
  • by Anonymous Coward on Monday February 11, 2002 @05:35PM (#2989514)
    More importantly, what is the project, and why is your boss specifying language features rather than project design goals?
  • One question... (Score:3, Insightful)

    by thrash_ (34661) <[brad] [at] []> on Monday February 11, 2002 @05:35PM (#2989515)
    Do all features need to be included in the language, or is an addon a possibility? C++ has all but one. Garbage collection, but that can be found in a 3rd-party library. Java lacks only operator overloading, which isn't really necessary. It is purely syntactic sugar. I cannot speak for the other languages, as I have little experience in those areas. You perhaps should have your boss prioritize the requirements, and pick the one that most meets the goals.
  • Simple. (Score:5, Insightful)

    by PsiPsiStar (95676) on Monday February 11, 2002 @05:35PM (#2989516)
    Hype! hype makes a language powerful! The IT departments are run on hype. It's a hell of a lot easier for business types to understand 'buzz' than actual code. Right? Of course right!
  • Re:Why doesn't... (Score:2, Insightful)

    by ADRA (37398) on Monday February 11, 2002 @05:36PM (#2989531)
    Doesn't support multiple inheritance, only interface polymophism. The GUI isn't as intuitive and straight forward as one would hope, but at least a tool like Jbuilder can reduce this somewhat.

    Java or C++ is probably the best fit for the job, especially when portability is a concern.

  • by jc42 (318812) on Monday February 11, 2002 @05:36PM (#2989539) Homepage Journal
    Well, I'd try to get your boss into a discussion with the (unstated) goal of trying to learn what language the boss has already decided is the correct answer.

    When people have a long shopping list of specific details, it almost always means that they have decided and have set up the requirements so that only the one answer is correct.

    This is, of course, a conventional way of doing "open" hiring or purchasing. You just write up the specs so that only one person or product can fit. It works just as well with software.

  • for starters (Score:5, Insightful)

    by Sebastopol (189276) on Monday February 11, 2002 @05:38PM (#2989557) Homepage
    Your query is so vast that it demontrates a complete lack of planning or thought. Post more details, or hire someone else to figure them out beforehand.

    This is what pisses me off. If you would put some thought into the product and the design abstraction, this would be an easy question. Instead, people charge off with grandiose ideas and big buzzwords (event handling, GUI, object oriented).

    People wonder why there is so much crap software out there. This is one reason: sitting around discussing the language without discussing the problem.

    I know I'm being kinda mean, but it's how I feel when I read such a newbie question from someone claiming to be attempting such an important task. I hope this post lasts long enough for discussion before being modded down to -1.

  • by cdmoyer (86798) on Monday February 11, 2002 @05:38PM (#2989566) Homepage Journal
    Less than 20 comments and already I see three(over +1) that say, "Java does all that!".

    You may feel that java is the answer for the poster, but it doesn't meet the criteria. Even ignoring the vague, flame-provoking concepts of "intuitive and easy to use IDE" and "simplified GUI design and event handling"... Java doesn't do multiple inheritance or operator overloading.

    Perhaps you think that no project needs these... great, at least tell us why in your response, rather that spouting, "Java... Java... Java"

  • Re:Why doesn't... (Score:2, Insightful)

    by sdwr98 (157983) on Monday February 11, 2002 @05:40PM (#2989592)
    Yes, but perhaps one should examine the reasons for wanting operator overloading and multiple inheritance. If this is just so that the project is fully "buzzword-compliant", then perhaps the priority list should be tweaked a little.

    I have found that being able to do multiple inheritance often leads to more confusion than help when doing software development.
  • The best programming language is the one that is used by your company's best programmers. If they are intimately familiar with it then they are able to use it to its fullest and will be able to make the language do what you want it to do.
  • by ubergnome (242049) on Monday February 11, 2002 @05:42PM (#2989610)
    Operator overloading is just fine. As long as you follow the logic of the other uses of the operator. Sometimes you don't even have to do that.

    Look at the '+' operator for strings in the C++ standard library. That is definitely an overloaded operator, and it does something way different. I think that this operator is definitely a good thing (sure beats the pants off of strcat).

    I think operator overloading is a good idea. Just use the power wisely.
  • by Urban Garlic (447282) on Monday February 11, 2002 @05:42PM (#2989621)
    A lot of applications these days seem to be being written along a sort of "engine plus glue" model -- I am involved in a project that uses Python and C++ this way. While there certainly are interface issues, you can get something that approaches the best of both worlds, playing to the strengths of the different languages at different points in the app.
  • by Anonymous Coward on Monday February 11, 2002 @05:42PM (#2989624)
    My experience is that Perl does whatever you need to do. I use it on Unix systems, but on the Windows side, I have heard nothing but great things about ActiveState Perl, which comes with a compiler. It is also now available for Unix. I don't about a Unix GUI, but there is Emacs :-) The object oriented mechanism is simple but easily extendible (this is Perl, after all!)
  • by trenton (53581) <> on Monday February 11, 2002 @05:42PM (#2989628) Homepage
    You're in a great place because you can choose which language to use. Most aren't that lucky. Instead of choosing a language based on a list of random features, start thinking through the problem and think of language features that would make solving the problem easier. The language you choose will be a natural selection.

    Making a list of neat features won't do you any good. It's this approach to problem that causes bloatware. If a product is guaranteed to solve all your problems, you can be assured, it will solve none. It's all marketing!

  • Re:Why doesn't... (Score:5, Insightful)

    by MisterBlister (539957) on Monday February 11, 2002 @05:43PM (#2989630) Homepage
    Java lacks support for operator overloading and multiple inheritence (which was on the list above). However, Java's 'lack' of these features is IMO, for the better.

    Please note, I do 90% of my professional programming in C++ -- I'm no Java zealot, but I do have issues with the idea that Java is somehow broken because it doesn't support these features.

    Java doesn't have multiple inheritence because it doesn't need it. Though there is some debate on the subject, the vast majority of people who have a lot of experience doing OOP will tell you to avoid multiple inheritence at all costs. It exists in C++ because there's no root 'Object' in C++ (not pure OO) and therefore you sometimes need MI to bridge gaps between two different libraries that wouldn't exist if every class derived from a common base class. Multiple inheritence is confusing for the programmer and sometimes even confusing for the compiler (name collisions). Use it only as a last resort. Don't use its existence as a basis for picking your language! That's just ridiculous.

    Operator overloading is less clear cut. While I must admit its nice to have matrix or vector (eg, 3d coordinates, not arrays) classes that you can just add using the + operator, operator overloading is so often misused that I'm inclined to think in general its not such a good idea. Of course I don't feel nearly as strongly as this as I do about MI, I could take operator overloading or leave it.

    Anyway the real point of my post is to encourage the original person asking to rethink what it is that makes up a powerful OO language -- don't look at the bullet-point features (in short all you did was list what C++ can do; no other language will completely fit the bill), look at the principles behind the language and how well it supports OO concepts in their generalized form!

  • by Moosifer (168884) on Monday February 11, 2002 @05:43PM (#2989632)
    For commercial or "enterprise" applications, a widely adopted language can often prove to be the most powerful. The more popular the language, the easier it will be to find mature or talented resources to keep the product going. Going with a relatively obscure language, even if it is somewhat better suited to the task, might only serve to hinder the evolution of the product.
  • Re:for starters (Score:2, Insightful)

    by foogoobers (144585) on Monday February 11, 2002 @05:44PM (#2989650)
    I agree! Go read "Essential COM" by Don Box for a good discussion of pragmatic OO design issues. How do you know you NEED all these features? Have you prototyped the system yet? Have you done your UML diagrams yet? I think that most of the languages you mentioned could fit the bill (of course, this forum is heavily non-M$, so expect to see VB downplayed).

  • by BitwizeGHC (145393) on Monday February 11, 2002 @05:44PM (#2989658) Homepage
    Smart managers will let their programmers use whatever gets the job done.

    Smart programmers will choose the most powerful tools for their job.

    They don't get the mainstream IT press headlines that Java, C#, .NET, and even Python do, but really "cool" languages like Smalltalk and LISP are seeing heavy use out there in the Real World. The bulk of C# and Java work will be the domain of code monkeys; the really cool stuff is being done with a variety of tools and languages.
  • by felipeal (177452) on Monday February 11, 2002 @05:45PM (#2989663) Homepage
    All those features used together is going to make a big mess, IMHO

    I agree. Most of those requirements does not make sense, they seem to be pure buzzwords bullshit by your boss []
    Java, for instance, fullfill most of them (except by the multiple inheritance and operator overloading, as already pointed out), but not all. Are you going to discard it just because of these 2 lacking features? Do you really need them? What else does you need that java does not offer, templates?
  • by CDWert (450988) on Monday February 11, 2002 @05:45PM (#2989675) Homepage
    Python has all you need, If I were to design a language from the ground up it would act and look alot like Python, that said, there is already something there and no need to push the edge of insanity writing my own language again, I did when I was younger, in the early 80's. No enough caffiene on the planet to try it again.

    Python will, if designed properly handle any load you could want to throw at it, it is portable as it gets, its easy to debug.

    I cannot imagine what you are writing, or your boss thinks youre going to write that needs all that in one place at the same time. My bet is this is a buzzword hyped dude that has no Idea of the actual functional requirments. He wants an IDE and RAD, Im assuming so any 12$ an hour lackey can help support it at a later date as well as speed initial development. If portablity is the least of your concerns(in short term) would be the choice. In about 2 years programmers will be like VB programmers are now....a dime a dozen. That has more value than you can imagine on a large scale project whose lifecycle is indeterminite.

    Screw em all and write it in assy, dont let em see any progress and then unleash it upon them complete, debugging is easy, if its wrong it dosent run. Its portable, from same architecture to same architecture(snicker), it actually will scale(buzzword insert)BUT THE SINGULAR MOST IMPORTANT PART is Youll have a job for life, at whatever you want em to pay you to maintain it :)
  • by DonkeyHote (521235) on Monday February 11, 2002 @05:46PM (#2989682) Homepage Journal
    Thank the good lord above for the creation of perl!

    RWD 2002, Fear the Retards for we are Legion

    xfbs fuif hfscj mt p guifo jhi u
  • by Jerf (17166) on Monday February 11, 2002 @05:47PM (#2989707) Journal
    Of course they're all missing something! No One Language can be all things to all people. In particular, "intuitive and easy-to-use IDE" and "simplified GUI" is a hard mix. (I'm not going to call Visual Studio intuitive.)

    You probably ought to try to weasel more requirements out of your boss.

    That said, the closest match to your problem is almost certain Python. The only "bullet point" missing is "abstract classes", but in Python, the term "abstract class" is nearly meaningless; they aren't necessary. But if it makes you feel better to create them, do so. Some people do for stylistic reasons.

    Functions are overloadable, you just have to do it by checking types. For paying that price, you also get some cute stuff with *args and **kwargs (look at the docs for those things until you understand them), which can be lifesavers when you want them.

    As for the "simplified GUI coding", you get *many* choices: Tk ships by default, and while ugly, is fast and effective for many uses. wxWindows is well-supported (in all senses of the word), looks native on all supported platforms, and is extremely flexible. (I'd rather program in wxWindows then MFC, even if I were doing a Windows only program! And it's a rare MFC program that couldn't be done in wxWindows.) Various IDEs are available for these things; you often don't need them. And there are many other choices as well.

    If Python lacks the Hype Veneer and you think your boss cares about that, then you've probably got to go Java, along with the purchase of an IDE. You don't get simplified GUI programming, but I don't know of *any* hyped language that has simplified GUI coding.
  • Hold your horses! (Score:5, Insightful)

    by Hard_Code (49548) on Monday February 11, 2002 @05:48PM (#2989737)
    "My boss gave me a set of criteria"

    Hold your horses! Have you really taken the time to understand the *problem* yet? This post is just a laundry list of various programming language features and buzzwords. Choosing a programming language is not like choosing a car, and just adding on all possible accessories and upgrades. More features does not a better language make. I'd have your boss clarify the reason for each and every feature (and yeah, "programmers are familiar with this" probably is a valid response - but there should at least *be* a response). Does your boss even know what multiple inheritence and operator overloading is, and why one would even want it? Until you can justify the features you want, there can't be a debate on "what is the most powerful programming language?". It's like "what is the best religion?", or "what is the best color?".
  • by ddkilzer (79953) on Monday February 11, 2002 @05:49PM (#2989748)

    A couple other languages/environments you may wish to look at are:

    I don't have much experience with Delphi 6/Kylix or Object Pascal, but Perl 5 will handle most of your requirements.

    Personally, I would go back to your boss and ask why he needs all these features. The list of requirements sounds more like a buzzword-compliant list of programming language features that a typical PHB would come up with than a real requirements list. For example, if a design document hasn't been created, it's likely that this list of requirements is bogus.

    NOTE: I found Cliff's question appended to the end of this story very confusing. It's orthogonal to the original question, at best. At worst, it's going to cause two entirely separate topics of discussion which will be difficult to distinguish when reading comments.

  • Re:for starters (Score:2, Insightful)

    by bsadler (472925) on Monday February 11, 2002 @05:49PM (#2989756) Homepage
    Right on... You don't start a job like this by looking at a language. Get your design goals straight and then find what fits them... of course, if you have already done this nevermind.
  • by RevAaron (125240) < minus city> on Monday February 11, 2002 @05:50PM (#2989768) Homepage
    No, but when developments come to pass, be it in the field of programming languages or building materials, they are tested and applied in ways that approach their potential. If this didn't happen, and wasn't supposed to happen, we'd have nothing more than COBOL, FORTRAN, and LISP (forget about one of the nice lisps, like CL, MacLisp, ISLISP, Scheme - just the original). Maybe Algol-60, but with your reasoning, we would've just stuck with the first three.
  • by gartogg (317481) <sdaman@mindBOYSE ... .tld minus berry> on Monday February 11, 2002 @05:51PM (#2989782) Homepage Journal
    If the boss knew, he would have given out a set of criteria that actually defined an extant language, instead of a set of imnpossible criteria.

    I would go back and engage him in a discussion on which of these goals are most important, with the (unstated) goal of trying to convince him that whatever language you think would be best really is best.

    Istead of looking at his criteria, look at the project and the goals, and make your own decision. It seems as though he wants a good language that's also easy enough for all of the programmers to use, so if you randomly pick C++ or java for instance, you could convincve him that it would do fine because almost everyone knows it well enough to code in it anyways, and it fits the requirements as well as any of the languages do. (This isn't an endorsement of C++, Java, or of any other language.)
  • by Lethyos (408045) on Monday February 11, 2002 @05:55PM (#2989846) Journal
    "When all you have is a hammer, everything looks like a nail."

    It's just plain silly to ask "what's the best programming language." That's like asking: "which is better, a hammer or a screw driver?" The reverse of the proverb is also true. If you have a diverse toolkit, and nothing but screws to drive, then everything in your kit looks like a screw driver.

    It comes down to using the right tool for the right job. It's not a simple question to ask, mind you, but your question is too vague to be answered at all. If you are doing text processing, use Perl (ignoring the argument that Perl does everything, of course) or some type of stream editor. If you are writing an operating system, use C. If you are doing artificial intelligence, use Lisp or Prolog. If you're writing a document, use HT/SG/XML or LaTeX. Building a GUI app *really* fast? Use Tcl+Tk.

    Let me rephrase your question with more specifics. "Which is the best programming language: Perl, C++, LaTeX, CSS, Japanese, or ASM?" That's nonsense (although everyone knows that Perl is better ;).

    It still baffles me how such stupid questions get posted as Ask Slashdot topics. The editors are genuinely retarded [].
  • by Kaz Kylheku (1484) on Monday February 11, 2002 @06:00PM (#2989902) Homepage
    It's not true that there exists some simple linear power spectrum along which all languages can be neatly lined up.

    What is relevant is this: does the language support all the right abstractions so that the programming solution to a given problem within a given domain can be expressed using elements that closely correspond to the ideal objects understood by the experts in that problem domain.

    Now a language that does this may be very domain-specific, and not flexible at all for solving problems in other domains. Or it may be very flexible so that it allows abstractons to be created to new domains that were not even known when that language was created.

    So, returning to the vague notion of power, when can we at least tentatively say that one language is more powerful than another? When for a large body of different problems, that language can rise to the occasion and provide the ideal abstractions for expressing the solutions for those problems, whereas the other language fails to do so, and only for a few, if any, problems the reverse is true.

    Lastly, what does it mean to have the ideal abstraction? It means not to worry about managing the representational or procedural details of the computation that are not relevant to the solution domain, or having to transform, rename, reshape, reinterpret anything. Unfortunately, this rules out nearly all languages whose only abstraction-making mechanism is making class or function libaries, because not every abstraction in a problem domain neatly corresponds to an object with methods. Only languages which are programmable---meaning that they allow you to write your own sublanguages and provide them as easily as function libraries to other programmers---can support this shape shifting, to produce abstractions to unforseen domains. People can develop custom sublanguages for anything: solving logic problems, querying databases, composing music, generating markup, whatever. You can do these things with object frameworks, but then you lose abstraction; the object programming gadgets rear their ugly head with details like what to instantiate and how to hook it up to something else, etc.

    Think about your while() loop in C or Java. The while loop is an ancient abstraction of control flow that someone had to invent. Yet your objects are not powerful enough to implement even this simple abstraction from scratch; you can't make a ``WhileClass'' whose instances do the job of a while loop.

  • Re:Ruby (Score:2, Insightful)

    by gartogg (317481) <sdaman@mindBOYSE ... .tld minus berry> on Monday February 11, 2002 @06:01PM (#2989914) Homepage Journal
    It looks nifty and i just started reading the docs to see if I want to use it, but in a production environment using a new language is suicide, even if the people envolved DID know it already (training takes time), because there are probably bugs. It's also a scripting language and it doesn't compile, not a listed requirement but probably useful if you want to use the program in a corporate environment (though the specs weren't specific enough to be able to tell...)
  • by Jack William Bell (84469) on Monday February 11, 2002 @06:04PM (#2989946) Homepage Journal

    You see this so often here on /., an article that seems designed to get the different UI/OS/License/Programming Language camps at each other's throats. Clearly the /. editors think controversy is a good thing.

    I would tend to agree with that, except that I am still stinging from the response to a recent /. post where I opined that open standards and competition are better than the the alternative [].

    The surprising thing for the above article? Seeing the Python people (who I tend to agree with) and the Smalltalk weenies speaking up more authoritatively than the Java contingent. Cool!

    Jack William Bell

  • Perl (Score:1, Insightful)

    by Anonymous Coward on Monday February 11, 2002 @06:06PM (#2989967)
    Everyone is suggesting Python, but Perl and Python have very similar semantics -- so, if you're considering Python, why not consider Perl too?
  • by SirSlud (67381) on Monday February 11, 2002 @06:07PM (#2989971) Homepage
    Ah, I'm in love. MI is nearly useless for the exact reasons he points out.

    It's a kludge to bridge some of C++'s implentation problems, namely that its kinda silly to have an OO language without a global base type (of course, I realize that C++ was to take advantage of the fact that everyone knew C). MI creates more problems than it solves, which is why it should remain the kludge it is, never to be included in a language design spec every again (although I'm sure it has been).

    I do, however, have to disagree with operator overloading. I feel that due to, historically, how we notate math, it's very natural for programmers to want to do operations on objects of similar-types in the A+A way. Until we start doing math in reverse polish notation, operator overloading can save crudloads of space and do wonders for the readability of code, although his points about it being misused (or 'over'used, haha) often are dead on.

    Of course, try explaining this to the CS grads equipped with a hammer coming out of school .. everything seems to look like a nail to them!
  • by InvalidSyntax (261050) on Monday February 11, 2002 @06:08PM (#2989984)
    Your boss needs to re-examine the requirement for multiple inheritance. I've got 15 years experience OO development experience. MI is something that looks good in the design but is a maintenance nightmare. Avoid MI at all costs.

  • Re:Python (Score:1, Insightful)

    by Anonymous Coward on Monday February 11, 2002 @06:08PM (#2989990)
    Where's the simple IDE & GUI stuff?
    (please don't say emacs!!)
  • java (Score:1, Insightful)

    by Anonymous Coward on Monday February 11, 2002 @06:11PM (#2990024)
    Why is it a necessity to use operator overloading? It's not a good idea to base your abstract designs on some semantic aspect of the language.

    A similar thing can be said for multiple inheritance. Is this truly a necessity of your design? BTW, Java *does* support multiple inheritance, but only on the interface level (eg, "myInterface extends X, Y"). That aside:

    -far, far less multiplatform issues, by far
    -extensive tool library included. This is better than it may seem at first: if you want to someday interact with some 3rd party application (or vice versa), integration is magnitudes easier if you're all building off the same tool set.
    -builtin i18n, if you need that kind of thing
    -nice GUI IDE environments: skip JBuilder, try NetBeans/Forte, IntelliJ, etc.

    Now that aside, before choosing a language, make sure that your design is always given the upper hand. The language should be a mere tool for implementing the design; it should not dictate important aspects of the design.

    A student asked Daigon, "But, does that not apply directly to Java with respect to multiple inheritance?" Daigon stepped to the right and said, "There is no multiple inheritance."

    At that moment, the student was enlightened.

  • by Emugamer (143719) on Monday February 11, 2002 @06:17PM (#2990089) Homepage Journal
    Actually it is... almost all people here aren't qualified to write their own compiler/language and to be brave enough to say so is a lot more then most here would do. Therefor it was a +1 Brave/Insightful/... If you aren't an architect/civil Engineer/Mechanical Engineer, stay away from the freaking bridge building, just because you crossed a few and jumped off one doesn't give you the knowlege needed to build your own
  • Ridiculous List (Score:4, Insightful)

    by harlows_monkeys (106428) on Monday February 11, 2002 @06:22PM (#2990140) Homepage
    You need to find out what the real requirements are. That thing from your boss is just a list of every language/environment feature and buzzword he has ever heard.
  • Re:Why doesn't... (Score:0, Insightful)

    by Anonymous Coward on Monday February 11, 2002 @06:26PM (#2990177)
    The combination of multiple inheritance, operator overloading, and templates is amazingly powerful. Templates + overloading gives you the STL. Templates + multiple inheritance gives you the Loki library - if you haven't yet, read Modern C++ Design by Andrei Alexandrescu, it'll change the way you think about C++.

    Also, I've seen a lot of posts about how operator overloading makes math stuff cleaner, but nothing about an application much more generally useful - smart pointers. There's some good stuff about that in Andrei's book too.

  • Java=SLOW (Score:1, Insightful)

    by Anonymous Coward on Monday February 11, 2002 @06:27PM (#2990185)
    Java Doesn't fit the bill because it's freaking slow.

  • Re:Why doesn't... (Score:2, Insightful)

    by notfancy (113542) <> on Monday February 11, 2002 @06:27PM (#2990195) Homepage

    Operator overloading is less clear cut. While I must admit its nice to have matrix or vector (eg, 3d coordinates, not arrays) classes that you can just add using the + operator, operator overloading is so often misused that I'm inclined to think in general its not such a good idea. Of course I don't feel nearly as strongly as this as I do about MI, I could take operator overloading or leave it.

    Operator overloading is a notational convenience, what is most commonly referred as syntactic sugar. The mechanism biggest advantage is that it enables to express succintly a potentially complicated operation on composite (and potentially complicated) objects. This promotes encapsulation, separation of concerns and a higher level of abstraction. The idea comes, of course, from Mathematics (and Mathematical Physics), where new concepts are built from old, e.g. matrix multiplication from dot product. Its biggest disadvantage is that it hides the cost of a (potentially expensive) operation behind a seemingly simple operator, leading to very unexpected behavior.

    A further disadvantage often quoted is that by overloading, the language can be made to lie, by defining the real semantics (say, "integer addition") of an operator (say, "*") to be different to the normal, expected, non-overloaded semantics of the same operator (say, "integer multiplication").

    My personal guru, Edsger W. Dijkstra, insists that operators should stand only for associative binary operations, where (a*b)*c = a*(b*c) for any objects a, b, c, thus enabling one to write a*b*c without concern for grouping. On that grounds, not even floating-point addition should have an operator ('+', the exact same symbol, to add injury to insult, as integer addition which is associative on any computer, two's complement or not).

    This may sound too stiff and removed from reality, but you will understand it as very real-world and pragmatic if you were bitten even once by floating-point cancellation, for instance, or by the huge run-time costs that some naïve implementations of matrix algebra in C++ incur.

    That said, operator overloading is a very useful notational convenience when the underlying domain the objects model is well-known and already equipped with those operators; for instance, vector and matrix algebra, complex numbers, string concatenation and subscription, et cetera.

  • by curtoid (415759) <> on Monday February 11, 2002 @06:27PM (#2990197) Homepage Journal
    .Net and Java??? Wait a minute here....

    This is a better way off looking at it:

    C - For raw speed (OS, including RTOS and Drivers)
    ASM - For the REALLY impatient
    C++ - For Fast, Powerful Apps - Engineers only, please, from here up...
    Java - For the Sophisticated "Runs Anywhere" Jock
    .Net - For the Microsoft Loyal Developer

  • Re:Why doesn't... (Score:3, Insightful)

    by jmccay (70985) on Monday February 11, 2002 @06:27PM (#2990198) Journal
    Java doesn't have true multiple inheritance. If you want multiple inheritance, you must use interfaces, and that means you must find a way to duplicate the functionality of the interfaced classes because an interface is empty.

    I don't this there is a language that truely means the bill. There may be a RAD (Rapid Applicaiton Development) tool that does meet the requirements. If it is on the Windows Environment, try C++ Builder. If I remember correctly is supports most if not all of those features. It has been a while since I did anyhting in it. Delphi (object Pascal) might also fit the requirements. Both are from Borland.
    Borland adds some stuff to C++ Builder to make it as easy to use as Visual Basic interms of GUI & IDE, but it still maintains the power of C++. They have an event model for most of there classes they provide. In truth, C++ Builder is everything Visual C++ should have been. Try C+ Builder.

    Other than that, don't look specifically at languages because rarely does a langauge specification include the IDE and GUI aspects. You need to look at the tools used to build programs in that langauge. You need to find a tool that supports RAD (rapid application development) becuase the requirements you listed are a lot of the stuff that goes into a good RAD tool (like C++ Builder). Delphi is the fastest and most powerful way to develope applications for windows and I think C++ Builder is next. Then VB, but vb is only a pseudo-OOP BASIC, and let's face it, BASIC wasn't all that powerful. Best of luck.
  • by aleksey (1519) on Monday February 11, 2002 @06:28PM (#2990206) Homepage Journal

    You should check out OCaml []. It is a modern functional programming language. It has parametric polymorphism, as well as subtyping polymorphism and dynamic dispatch, is garbage collected, features an advanced module system to help you structure code, and ports are available for all the usual platforms.

    In addition, OCaml interfaces well with Gtk (including using Glade to design GUIs), has database libraries, as well as all many other libraries that one would expect.

    OCaml can be either compiled to a portable bytecode, or directly to machine code. It compiles to very efficient code, and it is popular folklore that it can easily match C in terms of execution speed in many circumstances.

    The language is at a good point in its evolution right now to be used in commercial circumstances. It has been around long enough that it is well-understood and a lot of useful libraries are available, and its compiler is very robust, but at the same time it is not so old that a lot of the really new and interesting developments in language design haven't made their way into it. Although I prefer Haskell [] for small one-off programs, I would use OCaml for large projects.

    Another language which has had great success in industry (especially telecom equipment, as it was developed at Ericsson to write million-line switching software) is Erlang. Although I have not used it myself, its proponents swear by it as the best tradeoff between elegant PL theory, and the reality of writing large software.

    You will note that my recommendations all have a functional programming slant to them, and this is only due to my own preferences. I have not kept up with developments in OO language design, and so I cannot recommend one readily.

    If I may step on a soapbox for a moment, however, I would like to say that especially for the design of large systems, a strongly-typed modern funcitonal programming language with a good module system is a very good solution, to rival OO Design Patterns. As modern type systems allow you to express very precise invariants about your modules' behavior, they can be used to help many programmers together write large pieces of code that can then be checked at compile time to behave in a consistent manner. This can save both development time and money. Those are good things.

  • by t_hunger (449259) on Monday February 11, 2002 @06:29PM (#2990221)
    The best language is the one *you* know.

    I don't mean know in the sense of 'having read the most about it', but the one you did a real project in. There simply is no perfect language, there are just languages that you know how to work yround its shortcomings.

    Yes, some languages are better suited for certain tasks, but what good is that for you if you have to look up each command in a book? It takes a few month to get 'fluent' in a language. Do you have that time available to get your project finished? If you skip this learning time you will redo much of what you did in the beginning, just because you are ashamed of the ugly code;-)


  • by Graspee_Leemoor (302316) on Monday February 11, 2002 @06:29PM (#2990222) Homepage Journal
    "What I would love to see in a language is something merges the power of Perl (mainly regular expressions) w/ something like Visual C++ (OO + GUI), AND allows easy distribution (doesn't require a special runtime module, and is not a pain in the neck for Joe Blow to install on his machine)"

    Check out rebol ( It doesn't have rad, but the gui stuff is really easy to do, but anyway the really good feature you'll like is that it's incredibly easy to install on an end user's machine- one exe file to run.

    It runs on all major platforms too, and has regexps, and the internet protocols are very well handled.

    I am not a paid astro-turfer of rebol, but maybe it wouldn't hurt to send them my cv...


  • by bADlOGIN (133391) on Monday February 11, 2002 @06:32PM (#2990248) Homepage
    "My boss gave me a set of criteria which needs to be filled: intuitive and easy to use IDE; simplified GUI design and event handling; advanced error handling; advanced object oriented design including multiple inheritance, abstract classes, and garbage collection; full support for operator and function overloading; and portable (at compile-time) across various platforms."

    Your boss is most likely a tech ignorant (or worse tech wannabe) that has no business diticating a list of requirements like this and, from the sound of it, has no experience shipping software. If all of these are hard and fast requirements, then C++ fails to make it on the Garbage Collection and advanced error handling, Java fails on the multiple inheritance and operator overloading, and VB.not and C-Hash fail on the cross platform (unless the M$ shills in the audience can point me to the respective Mac || *NIX compilers for them AND assoc. libraries). Don't even get started on the IDE issue - nothing like a three way flame war between DevStudio sheep, Emacs evangelists, and VI virtuosos. If you're even thinking about dictating an IDE for developers to use, you're going to be in for a real fun time.

    Languages/platforms don't even get chosen in for-profit software endevors because they meet a laundry list of requirements like this. For better or (usually) worse, there's the practicality of developer experience, cost of maintainance (inc. compiler/ide licences), and above all market perception (just try to go off and sell that great tool written in Sather with TCL/TK UI bindings that runs on any *BSD desktop).

    Despite this, it's not the things ON the list that disturb me, it's the thinks left OFF the list. No specification of multi-threading support? No question about parsers for XML? Don't need a networking library? How about ODBC drivers? What about support contracts or consulting rates if you run into a big problem and need a hired gun? And dear GOD why the HELL is there no mention of automated build and testing harnesses for any of it?!?!?

    See what you can do to get a boss who's been through an actual product lifecycle. Otherwise, get ready learn what "deathmarch" means firsthand.

  • by Kaz Kylheku (1484) on Monday February 11, 2002 @06:52PM (#2990461) Homepage
    [Sorry about the ugly plain text formatting, but it's sometimes the only way to get code examples in properly on SlashDot.]

    I hope it's obvious to you how inferior this is. The real while loop doesn't require you to package up your test and body as a function. When you do that, you have introduced a problem of context, which breaks the abstraction.

    By the way, in Common Lisp, you CAN implement the while loop as a function, and yet provide it as a ``language-level'' abstraction as well. Here is how:

    (defun while-func (expr-fun body-fun)
    ((funcall expr-fun)
    (funcall body-fun)
    (go :again))
    (t (return-from while-func (values))))))

    (defmacro while (expr &body body)
    `(while-func #'(lambda () ,expr) #'(lambda () ,@body)))

    So you can now write something like this loop, which prints numbers from 0 to 9:

    (let ((i 0))
    (while (< i 10) (print i) (incf i)))

    Note how the while body can still refer refer to the local variable i, even though our implementation choice was to package up the expressions and use a function. This is the crucial difference, which sets this apart from the solution that uses functions only. Nobody would use your proposed while loop class, because they would have to carve their program into functions in a completely stupid way, with no access to local variables. Even if you had closures in the language, people wouldn't use it; if you gave a Lisp programmer the above while-func only, he or she would find it necessary to invent the while macro to actualy make it easy to use.

    Now to respond to your comment:

    > But since there's already a built-in while, what was with the stupid fake example?

    Sorry that I touched some sore nerves. I just wanted to pick a very simple example of an extremely simple control abstraction that cannot be implemented in these languages; it's not relevant that they already have it, because the implication is that it's impossible to make other abstractions that they do NOT have.

    >What are you trying to prove? That these languages are geared towards efficiency and
    >readable syntax instead of generalized object-oriented programming? Well, if so
    >you're right.

    Not at all. The point is that they have limited abstraction-making ability, because you are stuck with one rigid syntax. I won't respond to your remark about efficiency, whatever you mean by that. (Execution efficiency? Programmer efficiency?)

    When you have a rigid syntax, the language is good for certain domains. When you try to solve certain problems, though, the rigidity will get in your way. You may have readability at the microscopic level, due to the use of a small repertoire of built-in syntactic forms, but that readability will be drowned in the morass of code that you will have to crank out. Remember, assembly language is readable too. You have a few instructions, a few addressing modes and everything is in nice columns. But once you crank out a large body of assembly language, it may still be readable, but it's not *grokkable*. Whereas the corresponding C program may be quite grokkable.
  • by augustz (18082) on Monday February 11, 2002 @07:04PM (#2990563) Homepage
    Folks seem to be missing sheer idiocy and irony of this.

    We have a CLASSIC boss who just wants to be buzzword compliant. I mean, look at that list. Reminds me of all the .bombs (and I assume this company is now on that shortlist) who could fill endless pages with buzzwords sometimes without actually knowing a thing about anything.

    So make *SURE* your boss who is making these technical decisions really has the CS degree he has to have to make them.

    There are countless books out there on doing it right. Some key points are:

    - Reuse knowladge of your team.
    - If you think starting from scratch with 300 buzzwords will make a better product, think again.
    - Reuse work that has gone before. If you've listed every major language and found they don't have what you want, perhaps there is a reason. Perhaps folks who designed Java/C# actually thought for a few minutes before they designed the language.
    - Boss can make the decisions about goals, money etc. Make sure the folks making the technical decisions are stakeholders (ie, have to live with it). Why is the boss making this vs the lead developer. He'd better be the guy who'll be coding the most.
    - If you specify the tool you're going to use before laying out the problem, if you pick a hammer you'd better hope the problem is nailing nails and not playing Bach.
    - Give standardized/open source languages a shot (C++/C#/etc) before propriatery (Java etc). - They've renamed Ask Slashdot to Ask to Be Called a Fool. Why? Because folks posting in tend to be. You'll get great advice though, especially with respect to programming/development.

    Sounds like this company is virtually certain to built the garganutan pile of multi-inheritance pile of crap folks who end up having to maintain will loathe. I happen to dislike multi-inheritance except for a relatively limited arena of problems. That's just a personal opinon though.

  • Wrong question (Score:5, Insightful)

    by Lumpish Scholar (17107) on Monday February 11, 2002 @07:07PM (#2990585) Homepage Journal
    You don't want a powerful programming language unless you have a significant budget (say, $2000 US and 1-2 months per person) to train all the would-be developers. The biggest problem with C++ is how little of it most alleged "C++ programmers" really know about the language! Java may be no better. (Larry O'Brien: "Claiming Java is easier than C++ is like saying that K2 is shorter than Everest.")

    If I was picking a programming language from scratch, I would pick a very simple language, such as Python [] (which actually meets most of the boss's criteria) or Smalltalk.

    Like most everyone else, I advise you to ask the boss what he really wants, or at least what's behind his wish list.
  • by Pinky (738) on Monday February 11, 2002 @07:32PM (#2990790) Homepage
    void big_hairy_multipage_function(void)
    // Need to lock the foo resource while we do this
    Lock_a_resource x(foo);
    ... more big hairy code ...


    Yes.. I needed that property where you need to know that some code will be done at the end of a function.. oddly enough Java supports this with less of a hack! I was quite suprised to...

    do this:

    try {
    code blah blah

    } finaly {
    //stuff to do on exit.

    it turns out that finaly in try blocks is done differently then I expected.. finally is ALWAYS CALLED! There's no way to get out form a try block without calling finaly. You can try throwing exceptions, returns.. everything goes through the finally first... so you just put the semaphore unlock in there... no need to do that destructor hack like in C. I do it quite a bit in my code.


    Oh yes.. and of course there's the finalize routine in Java although using it.. well,, don't and save yourself pain.
  • by Pemdas (33265) on Monday February 11, 2002 @07:34PM (#2990801) Journal
    You just given a great case in point of why operator overloading is often just a Bad Idea.

    Matrix a, b, c;

    a = b + c;

    Did you realize that, in coding this way, you invoke a Matrix constructor and destructor every single time you use such syntax? This is the kind of hidden cost that just kills program efficiency. C++ allows you to define a copy constructor which would alleviate some of the superfluous constructor overhead iff you use this syntax:

    Matrix b, c;
    Matrix a = b + c;

    Anyone who argues that's intuative ought to be taken out and put out of their own misery. Beyond that, though, There is no way to get rid of the destructor overhead when using operator overloading . Nope. Can't do it. Not supported by the language.

    Operator overloading arguably makes for more intuitive correct code. But it makes for far less intuative efficient code.

  • by DaveWood (101146) on Monday February 11, 2002 @07:39PM (#2990824) Homepage
    The two things it doesn't have that you "think" you want are multiple inheritance and operator overloading.

    Multiple Inheritance: People claim that this isn't a good feature, but I disagree. I've run into times writing Java code where MI just obviously would be the right thing to do. However, A) these cases are rare, and B) there's always a workaround which is almost as good as the MI solution. In trade, not having MI has the added bonus of making your code simpler to understand, but most importantly, preventing people who think they know what they're doing (but don't) from using MI to make a complete mess of your model.

    Operator overloading: I left the best for last. :) Operator overloading is, in my experience, a real nightmare. To be clear: it offers you nothing functionally. It's a purely cosmetic feature. People often like to write a String or Matrix class with a + operator. Well, I take only minor umbrage with Java's special + operator functionality for strings - it hides the underlying work too well (one simple character = potentially a lot of VM activity) - but I can live with it. Otherwise almost every case where an operator could be used is in some way or another ambiguous. This is the equivalent of picking a one-letter function name, with the added bonuses of syntactic complexity and obfuscation with existing arithmetic and logical metaphors.

    I've seen and suffered through abuses of operator overloading often enough to become convinced that it's important not to have it, so that less-than-gifted programmers will never be tempted to use it.

    So I say again, unless you're doing anything inordinately complex with audio or video, use Java. Or use a worse tool, and suffer like everyone else does. :)
  • by jaoswald (63789) on Monday February 11, 2002 @07:39PM (#2990826) Homepage
    1) reference counting cannot handle circular references. Of course, C++ programmers hardly ever want to create anything able to handle such abstraction.

    2) you have ignored any time performance. Reference counting adds overhead even if you never accumulate a significant amount of garbage.
  • Delphi (Score:4, Insightful)

    by NDSalerno (465736) on Monday February 11, 2002 @07:41PM (#2990839) Homepage
    Damn! This sucks that there are so many comments already, this probably won't be read. Anyways.

    I am sadened by the fact that nobody cares about Delphi, and that the only comments that mention Delphi aren't moderated up. I have used many languages (and I was impressed to see that this person mentioned looking at Eiffel, a nice language).

    First off I have to say this, even at the risk of being flamed and called a troll. Either the geek culture is just ignorant, scared, or both. Stop feeling so insecure to the point where you have to use a difficult language to boost your ego. What I mean is try using a language that actually makes your life easier. I am so annoyed by these people who suggest C++. I have many years exprerience in C++ and let me tell you that it is not exactly your best friend on large projects, especially with coworkers who do not know the pitfalls of C++ programming.

    Also, all you people suggesting ruby, or other new and/or obscure scripting languages, please give me a break. I like cool languages like Lisp and Snobol as much as the next, but I must admit to the reality that no real business and business project is going to go with these languages as the main development tool. There are some business that use Lisp and Smalltalk, which is cool. However, the reality is that the dominant language is C++, Java, VB, and maybe even C#. Stop suggesting languages that no clueless boss is ever going to approve of (cluesless bosses only know to use C++/Java, the buzzword language).

    Now on to Delphi. Delphi is what you are looking for. First off, your requirements list is too unrealistic. You are going to to have to make some trade offs.

    Delphi doesn't have operator overloading. Guess what? That is not critical. What's the difference between a + b and a.Add(b)? None.

    Delphi doesn't do multiple inheritence. Guess what? If you are a good enough OO designer, you won't need it. Delphi supports single inheritence, multiple interface implementation style, just like Java and Smalltalk. So don't give that shit that multiple inheritence is needed, it is not.

    Here is a quick OO design tip. I have noticed that C++ programmers like the multiple inheritence because they can have a class inherit from one class to gain capability, and then have it inherite from another class to establish communication (usually through an abstract interface). THIS IS A MISTAKE!! Golden rule of thumb, favor aggregation over inheritence. I am not going to exlpain myself on this (it would make this post too long). Take it from me, I have seen this in real projects, don't use inheritence to establish communication between objects. Use inherietence to vary state/behavior of a particular entity. Net result, designs such as these do not require multiple inheritence and are far more flexible and reusable.

    Delphi is natively compiled, not like that p-code shit VB does. Delphi is made by Borland, which employs some of the brightest compiler designers around. Delphi is far more efficient than C++.

    I have used C++ most of my career and I am still learning Delphi. I was skeptical of Delphi at first. But I gave it a try and did performance tests. For example, Delphi's for loops kick the shit out of C++ for loops. Another examle, Delphi's TList kicks the shit out of the STL vector and list containers. Don't be so ignorant, give it a try. I DARE YOU ALL YOU TROLL GEEK C++ PROGRAMMERS WHO FIND IT EASIER TO SAY DELPHI SUCKS RATHER THAN TRY IT!!

    As for GUI, no contest! No contest!. You know easy VB is with GUI development, Delphi is even better (with more components by default than VB). People have mentioned Qt. I like Qt. It is orders of magnitude better than MFC (which is the WORST LIBRARY IN THE WORLD!!). But Delhpi's VCL is better than Qt.

    Delphi does not have garbage collection. That is ok, its interfaces are automatically reference counted ;-) By the way, Delphi's interfaces were modeled after MS COM, and as a result COM programming is a HELL of a lot easier in Delphi than in Visual C++, including MS's stupid ATL crap.

    I thought that Delphi would not be portable, but it turns out that Borland implemented something to simulate a lot of the Windows stuff under Kylix. As a result, porting should not be hard. I will not say that porting is a snap. I would be lying. However, porting should not be that bad, but YMMV.

    End result, I used to love C++. But after using many other languages I started to despise C++. Delphi was the language that made me loathe C++. I do respect Troll Tech for making an excellent product. Qt is very impressive, but MS's MFC library is the cold reality that C++ is very deadly in the wrong hands. Visual C++ with MFC has to have caused more project slippage/failure than any other language in the history of programming (well, that is my opinion). I dare anyone to check out Borland's case studies of Delphi. Check out Deja news list of compilers, where the programmers got to vote. Delphi, despite probably the least used langugae, was voted number 1, followed by Borland's C++ Bulder. Visuall C++ and VB were at the bottom of the list with negative comments too!
  • what about pascal (Score:1, Insightful)

    by Anonymous Coward on Monday February 11, 2002 @07:41PM (#2990840)
    i think an object oriented pascal ide for qt may be a good idea, as it would be cross platform, and pretty much fit everything. i know delphi/kylix sor of does this for their gui toolkit, but something that didnt run in wine would be good, especially if it used qt.
  • by aoihai (518418) on Monday February 11, 2002 @07:51PM (#2990908)
    Delphi. It does everything and can be used by (clever) monkeys. It's main disadvantage is a lack of third-party support.
  • by namespan (225296) <(gro.liametile) (ta) (napseman)> on Monday February 11, 2002 @08:22PM (#2991132) Journal
    What if no one else in the office knows Prolog? You end up with read-only code

    Prolog syntax should take about 15 minutes to pick up. Programming patterns should take another half day by anyone who's done functional programming -- i.e., anyone who really knows their CS. After that, it's just a matter unraveling someone elses code, and possibly mastering a specific library or API -- no easy task in ANY language. Code in general writes easier than it reads.

    In general, I think it's very odd that people look for programmers experienced in a particular language. Once you've learned to solve problems using a few programming paradigms, most of your stuttering is going to be syntactical, and in using libraries/frameworks. I can appreciate that an employer might want someone who knows and API or library or protocol backwards and forwards -- that would save some time. But there's a lot of jobs I've seen calling for years of language specific experience when any competent programmer could do the job with a good manual (whether good manuals exist is another story, but hey...).

    Finally, there probably are more people out there who know Prolog/ML/Haskell/name-your-favorite-minority-lang uage than you might think. I picked up Prolog as an undergrad working on some projects over summers. No big deal. I'm sure I'm not the only one.
  • by Eric Damron (553630) on Monday February 11, 2002 @08:53PM (#2991319)
    Here are a couple more things that should be considered.

    1. Maintainability - How easy is this project going to be to maintain. The language you choose will affect that.

    2. What's the learning curve for the language? C++ fits most of your list but the learning curve can be steep. Do you want to take nine months of doing nothing but learn a complex framework?
  • by Virile Garbageman (548110) on Monday February 11, 2002 @09:08PM (#2991417)

    There is the notion of the right tool for the right job and, as you can tell from these threads, everyone seems to have a different idea about what the right tool is. I don't quite understand why your boss feels like you need to find this one super-language. Most development projects these days span multiple platforms and software domains, from desktop to server to web. Different languages offer different strengths in different areas. Different programmers have different skill levels in different languages, and different preferences in development environments. What is the percentage in attempting to enforce such a heterogenous environment? Wouldn't you be better off to find a compatible suite of tools based upon the platform and the problem? Couldn't you better capitalize on the strengths of your development team by choosing appropriate languages and tools for each application layer? One size doesn't fit all, otherwise we'd all be programming in Java.

  • Why not ask... (Score:2, Insightful)

    by ttys00 (235472) on Monday February 11, 2002 @10:31PM (#2991898)
    ...the people who will be developing the software ie. the dev team?

    Surely they will prefer to do things in a language they prefer rather than do what the boss says.

    They might even say they want to do some parts of the project in one language and some parts in another.
  • by xski (113281) on Monday February 11, 2002 @10:48PM (#2991964)
    My boss gave me a set of criteria which needs to be filled:
    • intuitive and easy to use IDE
    • simplified GUI design and event handling
    • advanced error handling
    • advanced object oriented design including
      • multiple inheritance
      • abstract classes
      • and garbage collection
    • full support for operator and function overloading
    • and portable (at compile-time) across various platforms.

    Looks like he read the latest development management magazine and picked out the buzzphrases with a 'Good' connotation attached.

    There are other posts that have excellent suggestions, so I wont rehash 'em here. I just couldn't resist as I'm particularly pissed at managers with no technical background in software that think they have a clue how to design software or write code much less lay down criteria for language selection. Oh, Please! Deliver me from stoopit people.


  • by Ozx (529611) on Monday February 11, 2002 @11:51PM (#2992196) Homepage
    Java makes a compiler/vm issue a programmer issue... So instead you "twiddle" your thumbs when you want to store your numeric results in a collection... Yeah, that's real bright...
  • by camusatan (554328) on Tuesday February 12, 2002 @12:00AM (#2992249) Homepage
    Shouldn't the 'boss' character either be giving less detailed requirements, or just choose the language him/herself? My gut instinct is that if someone has such a strong idea of what is required, and has such detailed specifics, that that person is just a few tiny steps away from the final decision anyways. Either that, or the PHB just put every single programming buzzword into the requirements document to sound 'cool'.
  • Re:Java Interfaces (Score:2, Insightful)

    by God! Awful (181117) on Tuesday February 12, 2002 @12:08AM (#2992281) Journal
    I program mostly in C++ but I've done a bit a Java. I found the main problem with Java was the amount of glue code I had to write. Glue code is the programming equivalent of paperwork. It's boring and mindless, but necessary if you want to stay organized.

    C++ requires some glue code in order to get good modularity, but in Java the bloat is ridiculous. Having to create a whole new wrapper class just to simulate the effect of a non-const pointer!?

    Interfaces are a good feature. I've implemented the equivalent in C++ using either multiple inheritance template classes, but Java interfaces are cleaner (and safer). However, as before, the glue code puts a burden on the programmer. I found myself giving up on code reuse because the burden is just to high.

    After declaring an interface which accepts a listner and another which acts as a listener, it occurs to me that I used to write a callback function to do this in one tenth the time, and at no expense to modularity.

  • Re:for starters (Score:3, Insightful)

    by dubl-u (51156) <2523987012.pota@to> on Tuesday February 12, 2002 @01:33AM (#2992572)
    A while ago I did a comparative study of the graphical design tools on which UML is based. My conclusion was that the idea was a pretty bad one and all of them became more trouble than they were worth as they attempted to track every feature of C++ or such graphically. As the projects grew in scope the diagrams became less and less useful.

    Amen. Diagrams, like any other documentation, should be carefully abstracted summaries of the code, not 1:1 duplication of it. 99% of the UML I do is on a white board or on scratch paper, which is where it belongs.
  • by mauddib~ (126018) on Tuesday February 12, 2002 @07:24AM (#2993233) Homepage
    Unfortunately, there are still people who have prejudices about certain languages, without having programmed in them at the first place.

    Common Lisp has grown alot in the past years, but it's expresiveness of theoretical problems is superb above most other languages. Wether you are a programmer with no mathematical background, or a mathematician with no programming background, CL will be easy to learn.

    One should definitely have a look at CLOS (Common Lisp Object System), which beats most other Object Systems with ease (especially because of the metaobject protocol).

    Then take C (and all derived languages, such as C++, Java (and Perl)). Most OO paradigms in these languages are hacks, not expresive, not extendible, no reflection. I'm not saying these languages are bad; these are just the languages in which most work has been done for the past 30 years. But there are more languages to see and to learn.

    You should definitely have a good look at Lisp, for me it was an eye-opener.
  • by Anonymous Coward on Tuesday February 12, 2002 @08:36AM (#2993365)
    You are all clearly too weak to understand the greatness of Perl, the magic Camel that lives in the Cave in the land called Hon'a'lee, and Perl::Tk

    Well many of Python users actually know Perl. That's why they choose Python.

  • by Anonymous Coward on Tuesday February 12, 2002 @09:53AM (#2993618)
    For those of you too braindead to see it, this is a troll. CL is only getting started... In 10 years time, the MS/CLR and Java communities will probably have reinvented CL, poorly.
  • by tedgyz (515156) on Tuesday February 12, 2002 @10:02AM (#2993676) Homepage

    This is like putting the cart before the horse. Your boss is defining the solution instead of the problem.

    I am a strong advocate of simplicity, which is why I think Java is a great choice. Multiple inheritance and operator overloading are not sorely missed. Other threads on this topic explain why multiple inheritance is not a problem in Java.

    More importantly, IMHO, Java eliminates the #1 bug producer in languages like C++ - pointers and the subsequent memory errors. I surely do not miss managing my own memory in C++, etc.

    Java is not perfect. For example, EJBs have been WAY overhyped and overused. Most of the time their usage in the real world is akin to using an excavator to dig a hole for a mailbox post.
  • Re:C++ (Score:1, Insightful)

    by Anonymous Coward on Tuesday February 12, 2002 @10:27AM (#2993801)
    I guess the key question is, who is it owned by. Whoever owns the resource is responsible for acquiring and releasing it. If views don't have any legitimate claim of "ownership" to documents, they shouldn't own counted references to them either (this amounts to them having a shared ownership of those documents).

    That's true, but the "ownership" can change. Example: Internet Chess GUI - as long as you are playing the game, it's the server which updates the current game - when the game is finished you (and the GUI) get exclusive rights about editing and changing the game. You can also play without GUI, or just observe a game, etc... It's easy to see you can use a "lock" about the game (probably a pattern "ExclusiveObserver", or a SerializedControled) for avoiding you to edit a played game, but it's also easy to see that if you are managing a set of games.

    I don't see how. Memory management is about resource ownership, and that is very much related to the problem domain.

    I disagree. A problem domain *may* give a clear resource ownership model (so you are right in this sense), but then there is absolutly no proof that this model can hold if you are making changes which are still perfectly consistent with OO. This is especially a big problem if you want your design to scale. When your problem is complex enough or your program is changing fast enough, you have to use "interfaces" which are the anti-thesis of allowed object memory management (you may have references to several "interfaces" coming from the same object, and often no ownership - even if the object comes from a factory and you are actually the exclusive holder).

    No one prevents you to create an object with references to objects on one domain and with references to objects to another domain ; in fact you are encouraged to do so, if it fits the problem you are trying to solve (you are spliting complexity and reusing abstractions). And the references can be backwards.

    Manual memory management 1) gets in the way of architecturing properly your program (you have to use extra classes or extra responsabilities) 2) might need a overhaul if you are using your classes in a different contexts (ruining code reuse) 3) might need a overhaul if you are modifying your OO datastructures, or simply OO responsabilities.

    Example: if you are using objects which are for some reason organized as a tree, then the clear way is to have the parent to own the child. Suddenly you realize that it makes sense in some case to have an "acyclic graph" (i.e. shared children). Kaboom! You have to change to reference counting. Then some comes and use your objects (which do 100x times more than just being a tree, remember the program is scaling to more and more complex features), and holds references to your objects in some objects which are organized as a priority queue. That's ok, keep on using reference counting. Then someone, not knowing anything about how your objects are organized nor the second persons' objects are organized ever, just gives to your tree an objects which hold indirectly a reference to the priority queue: Kaboom! you now have a cycle. And why did this happen? It's because the third person had no idea of how your objects or the second person objects are organized, because they are encapsulated behind OO. More, the third person has NO BUSINESS, looking how internally the objects are used: she is just using the interfaces that are provided, and gives you an object providing a third interface (creating a loop). I agree that if you have only simple architecture, it's ok... but the bigger and bigger the program gets, the more and more indirect (unknown) references are going to happen.

    In this particular case, I'd suggest that the document should probably be managed by some other party.

    If the document has enough information, it is managed by itself. In the case of a chess game, it is a simple datastructure, which just vanish when no one is using it. The "other party" you are talking about is just an artefact built because there is no trivial memory management (ownership) possible. This is ok, but when you have 100 classes pointing at each other, it's not, your other party is going to have to know about the internals of the links. Add a reference from one class to another (even if it is just to make mostly superfluous stuff like statistics), and voila!, your other managing party (other parties) might need to be changed.

    In this particular case, I'd suggest that the document should probably be managed by some other party.

    It's useful if they are written/stored on disk ("do you really want to loose your changes?"), but again this is orthogonal... Document/View can be applied in situation when "Document" isn't a real document in the sense of "Book" or "2D Drawing", it can be has small as displaying one statistic in a corner of a 1 GB data structure updated in parallel by one object... If like the chess games, they aren't persistent, then there might be no such party.

    In any case, I don't see a document as a very strong candidate for a reference counted model under normal circumstances.

    Yes, but in OO, you only see the top of the iceberg... consider chess games again: an option might be to have an engine calculating some positions, and at the same time have a database check the current position in a chess DB to see if the position is know, and also to have a "sound" observer yelling "check" each time the observed position has check, and a endings database to check/compute if the result of the game is already known in infamous "table bases". The problem here, is that you probably want to reuse all your classes, for instance if you want to program a chess engine with no GUI (only program to program UI), but with a chess openings database/chess endings database, or a GUI with no server interaction but only the endings database (teaching mode), or a GUI which is only a view, when _computing_ the endings database, to report current status or debug. Or better a program that does all that based on command line arguments.

  • by aWalrus (239802) <sergio&overcaffeinated,net> on Tuesday February 12, 2002 @12:09PM (#2994333) Homepage Journal
    Mmmhhh.... been reading some of your past posts, and I have to say that you sound quite bitter... If you don't like programming and hate most of the IT business so much, you should maybe look for another job.

    As for the monkey with a keyboard thing... mmhhh... could you define what a real programmer is to you first please?

  • Flamebait Post? (Score:2, Insightful)

    by SloppyElvis (450156) on Tuesday February 12, 2002 @12:16PM (#2994380)
    My language is bigger than your language.

    Please, do we need such a post? I am surprised nobody posted that assembly would be a good choice; your limitations will be minimized.

    Slashdot readers as a whole write in just about any language out there, and everybody has a reason their favorite is the best.

    As many have pointed out, without a problem spec, the choice has little to go on. In general, pick a language that either has a base of programmers who are familiar with it, or that is easy to learn. That way, you can find employees. Judging from the fact that your boss's requirements are not satisfied entirely by any language, you should hope his requirements for employees are not so.

    Programmer Requirements:
    Doesn't write bugs
    Doesn't complain about vague specs
    Is vigilant about maintaining perfect documentation
    Doesn't blame hardware
    Shows up on time at 7:00am
    Displays elegant mastery of multiple-inheritence, however is incapable of preventing leaks without the help of a garbage collector.
    Doesn't waste company time reading SlashDot

    Best of luck to you.

You are in a maze of little twisting passages, all alike.