Slashdot Mirror
What Makes a Powerful Programming Language?
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 VB.net; 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?
no operator overloading
You know, Pure Fcking Magic
I Heart Sorting Networks
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.
No multiple inheritance. No operator overloading.
More importantly, what is the project, and why is your boss specifying language features rather than project design goals?
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.
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!
___
It's the end of my comment as I know it and I feel fine.
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.
Bye!
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.
Those who do study history are doomed to stand helplessly by while everyone else repeats it.
... is Smalltalk. In its standard form it's missing multiple inheritance, but is powerful enough to tackle just about any OOP task, even without MI. What the IDE is like depends on the environment you get; but I hear great things about VisualAge.
N4st0r, trixx0r h0bb1tz0rz! Th3y st0l3 0ur pr3c10uzz!
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.
https://www.accountkiller.com/removal-requested
Don't know of a GUI as nice as, say, VS.net, but here are few in the works that look quite promising. Other than that, Ruby fits your needs quite well.
Java is the blue pill
Choose the red pill
I would go with Java. It is really object-oriented and clear structured, there are many implementations out there (Sun's Official, gcj, IBMs), it is cross-platform and if you tweal it a little it can be fast.
Boycot? Blackout? Subscriptions?
I don't care!
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"
/* CDM */
1. Its what "everyone else" is perceived to be using,
2. Programming cannot be suitably be turned into a MacJob until the variance in the toolset is reduced.
Microsoft's .Net and Java are going to occupy 70% of the brainspace for programming in the next ten years, and these languages conform to my description above.
Sure, Lisp is cool - its also dead in the market, so stop trying to resurrect it based on its coolness. No one cares.
Unless you have pretty strong performance requirements, Java is your language.
I think it fills all the requrements, except for the somewhat misplaced "full support for operator and function overloading".
Why operator overloading would be a mission critical feature for a language beats me. It was excluded from Java for a reason! I assume the reason is how hopelessly confusing it can be to read code where + or && doesn't do what you'd expect them to do. It should be clear when a function is called and when it's not.
you can do both those in java if you know how..
...on what you are writing. I use Java for a lot of work, but I wouldn't use it for anything that needed a *lot* of speed, or low level hardware access. However, Java does have a rich API and good portability.
The best solution is ultimately probably using two languages - perhaps Java for interface work / portability, but also C for anything that needs to interface to hardware, or needs the performance. I'm only using Java and C as examples - but other languages are the same.
Most languages can't do everything. Pick the best for the task required and the skills available.
I think that there are 5 main elements that make a programming language powerful.
Simple sequence
Do While
Do Until
If Then Else
Case
Of course I'm from the school of thought where anything can be solved by using the logic. But what do I know? I'm not even 25 yet.
Starkle, starkle, little twink.
Objective C and the Cocoa framework provided with Mac OSX is quite possibly the most powerful API I have ever encountered. You can also use Java with Cocoa is you don't want to learn some weird syntax, but I'd reccomend sticking with Objective C since it provides some small and useful benefits over Java.
Also, all the development tools come free with the operating system(OS X). Project Builder and Interface builder are first rate development tools. WebObjects(not free. 700 bucks) also provides a great medium towards database driven web based applications.
Obviously this depends on whether or not you want to limit yourself to OS X. Who knows, maybe they'll port OS X to x86 =).
-Jacques
jc@cs.washington.edu
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.
"If you were to design a language from the ground up, what features would you include and why?"
Since we're in a complete fantasy realm here where all of use have the brainpower, patience, trust fund, and buckets of countless free hours required to even BEGIN such a task...
...can I have a pony?
------
Today's Top Deals
Operator Overloading
Multiple Inheritance
You CAN however code aggressive garbage collection for C++. A quick search over the net should yeild a HEARTY list of garbage collection routines. It just doesn't come built in...
I don't get it; what's wrong with good ol' C++, according to that list?
I can only see two possible deficiencies according to your requirements. The first is the lack of a truly portable GUI library (though you can get libraries like Qt that are reasonably cross-platform in some cases). The second is the garbage collection, but (a) you can use a garbage collector for C++ (if you must...) and (b) using the right basic tools and techniques, garbage collection is largely unnecessary in a C++ program anyway.
The biggest problem with C++ is getting people who program it, as opposed to C-with-bolted-on-classes-here-and-there. But if you've got a half-decent team and someone with smarts in charge, all of your concerns should be non-issues.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
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.
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!
Too big to fail? Does that make me to small to succeed?
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.
You can write code to handle all the things that it doesn't do. ;)
This is why C/C++ is so powerfully. You want to do something thats not part of the "default" syntax, write a class, or function(as per your needs) that does it.
VB is not cross platform.
C# is propritary.
Java is also propritary.
There are IDEs for C++ on all major platforms.
There are quite a few developer that know c++. heck, some of them even understand it!
The Kruger Dunning explains most post on
just read this
(It's not like I want to spend an hour pimping a language when there's a site devoted to it.)
No Zen is good zen
It's strange that your boss has so many requirements for the language but yet he didn't want chose the language himself.
You have the difficult choice to buy a car in any color, provided the color is black.
Here's a thought - what langauge would your current programmers feel confident producing the final product in? Barring that, what do they want to work with? Happy programmers working in a familiar environment yield way more productivty than any langauge change will ever give you - even if that means F77 or SNOBOL (Ok, perhaps that's a little extreme).
As for myself, I would choose Java as you can get the best features of MI through Interface MI, and I've always found operator oerloading to be overrated (though handy in some spots). But again, you should what best suits the situation and the people there.
And here's a personal plea from users all over the earth - whatever you pick, please design the GUI to handle resizing correctly!
"There is more worth loving than we have strength to love." - Brian Jay Stanley
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) VB.net would be the choice. In about 2 years VB.net 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
Sig went tro...aahemmm.....fishing........
Just stick to a language that already works and has a following. C++ is a great bet because lots of people use it and there are plenty of tools out to support it.
I gave up on the perfect language. Doing so is doomed to failure. Make it powerful, and you miss out on simplicity. Make it simple and you can't use it for much. Try to make a good balance for power users that fits your spec, and you'll end up with something that looks like a mix between C#, C++, Java, and Eiffel, slightly better designed, with different syntax and no actual support from anybody but the language creator.
Plus, there are some who believe that no language is complete without functional programming and/or aspects. Some big and cool projects have been done using modern functional languages.
Your best bet is C++ with a cross-platform GUI library like wxWindows or qt. If you want, you can try using one of the garbage collectors for C++ that's available and then you'll have most everything. Or you could just use bounds checker and manage your memory by hand.
Gentoo Sucks
For instance, if you're looking at languages and find that you like what C++ has to offer but you need garbage collection it can sometimes be reasonable to write a memory manager which takes care of that for you. If programming resources are an issue, or if writing a memory manager is just too daunting (no shame there, that's a tough problem) there are third party memory managers available in the world.
This is true for at least some of the other features you listed as well. The language doesn't have to do everything natively, you just have to be able to get it done somehow.
Also, some things that might be missing are really there, just with different names. For instance, multiple inheritence may not exist in java, but it does have interfaces, which sure a very, very similar purpose. Just because it's not multiple inheritance doesn't me it won't meet your needs.
Ultimately it sounds to me like you boss has heard too many buzzwords recently. It might be helpful to ask him why he chose to put each of those requirements on the list. Knowing what needs to be accomplished rather than how he thinks it should be accomplished might just help you find a solution which will actually meet all the needs of the project.
Behold the Power of Cheese!
"Must have multiple inheritance!" That reeks of someone spouting buzzwords. Complex inheritance hierarchies are probably one of the biggest factors working against OOP. Polymorphism is great, but when it takes 20 min to figure out which base class resolved the function call, something is wrong with the design. My favorite cross-platform UI dev environment is QT using KDevelop. No garbage collection, but you can't have everything. BTW, Java does not support multiple inheritance, but its support for interfaces usually does the trick.
You try doing proper generics without it. :-)
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
This has to be the dumbest, most trollerific Ask Slashdot ever. What's next? 'Which operating system is best?' 'What's the best text editor?' 'Is Bill Gates Cooler, As Cool or Less Cool than Linus?' .... They must be having a really slow news day there over at OSDN.
- undoware.ca
Ask your boss what the project is going to do, and what it really needs out of a development environment, instead of just giving you a long list of buzzwords.
The list of requirements he's given you reads like a job description that's been through the HR department. The first thing you do when responding to a job ad stating "Position requires at least 5 years C/C++, Java, Perl, and SQL experience on multiple platforms," is ask "What do you really want?" The same applies here.
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.
If you're looking for good, portable, cross platform GUI development it's hard to go wrong with SpecTCL. It is a Tcl/Tk visual development environment which can generate code in Tcl, Perl, Python, Ruby, and Java. There are versions of SpecTCL available on Windows, Mac, UNIX and any other platform on which you can get a working Tcl/Tk environment. There is a related project SpecTix which appears to provide a more complete IDE, but I've not used it. I'm also really (really!) impressed with Apple's new IDE, Project Builder. If you've not seen a demo, you need to ask someone with a Mac running OS X to pop in the developer CD and try it for yourself. It allows you to do rapid application development to the Cocoa APIs in C, C++, Objective C and Java. What's cool about writing to the Cocoa APIs is that they're not only available on OS X, they're available on most UNIXes via the GNUstep implementation. I'd really love to get some time to find out just how portable Project Builder's resulting code is to other OpenStep implementations.
Brandon D. Valentine
He's not asking what WE'D like in an IDE, he needs something that already has all those features, and I don't think the project he's talking about is writing a new language/IDE.
But to answer the real question as best I can, I can't think of anything that has all those features. But what I'd do if I were you, is to rank the importance of each of those features as it applies to the upcoming project.
Based on my experiences, I'm quite happy with Delphi. It doesn't have multiple inheritence or operator overloading, but it does have function overloading at least. These features aren't generally show stoppers though. I haven't tried Kylix yet so I'm not sure how smooth the transition would be to linux.
In any case, what it comes down to is just pick an language. They ALL have shortcomings and nuances that will take time to learn and overcome if you aren't already familiar with them. So just pick something, code some sample projects, possibly code a prototype of your project if time persists. You can always use this as a chance to learn something new to add to your resume.
...and you're right, none of those programming languages will fit all the bills.
I haven't been programming as long as some, but in my experience I've never come across a particular programming language that covers all the bases. You might be better off deciding which of your specifications is of the highest priority before giving weight to any language.
Also, since no one programming language fits all these specs, you might want to start documenting (or digging up documents) on which ones support the most of your specs.
Just from what you've asked for here, I'd say you're asking more for something like C++ than VB/VB.NET. You've thrown "simplified GUI design" into your specs, and, aside from Java, that's almost always anti-portability. Assuming you go with the most widely-used simple GUI language, VB, you're pretty much locked into MS OS's. Since OS-lock-in seems to be a polar opposite from what your other specs aim for, I'll say you don't want to use VB.
Ruling out the simplified GUI design as the highest priority, I'd say you're best off with C++ or Java. There are C++ compilers and Java Virtual Machines for a variety of platforms (that's an understatement). I lean towards C++ - what with it's pointers, truly compiled code, etc - but that's mostly personal preference. I've got some experience with Java and I've got mostly good things to say about it. But all my C++ apps have outperformed my Java apps, so the optimization geek in me leans to C++.
My sigs always suck.
"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?".
It's 10 PM. Do you know if you're un-American?
It sounds like C++ and/or Java is your best bet based on the list of requirements, and what your boss probably wants. However, how important are each of these items? Different languages have different levels of support for all of these, and different ways of accomplishing the same tasks.
...
:)
For example, garbage collection in Java or Perl is generally not very good compared to a modern Lisp / Scheme interpreter. C++ has templates, while Scheme has functions as a first-class type. Scheme and Perl have closures, which can be used to build complicated object-oriented systems from the ground up, while Java has inner classes, which is not quite the same
Also, please realize that object-oriented programming, multiple inheritance, garbage collection, and operator/function overloading are all very powerful language features that require careful design and consideration to use correctly. There are times when each of these is a massive help to the programmer, and there are other times when they can each create intractable messes.
So figure out why you need each feature, and what its role is in the project, and if you could use other language features to fulfill the same roles. The language you're looking for probably doesn't exist, and even if it does, there's no guarantee you'd want to use it.
Also, if you really want this (imaginary) language, I'm sure you can write it in C; that's what they do for all the other languages I've mentioned.
pb Reply or e-mail; don't vaguely moderate.
Oh and here is Why Java will always be slower than C++
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.
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.
Working toward a usable PDA environment in the spirit of Newton OS: Dynapad
Since they're "open" to new languages (although, given the specificity of the requirements, it seems someone already made up their mind), Delphi would make a very good choice. They seem to want a good RAD IDE and OO, which are both a "check" with Delphi. It doesn't do gc, but then again, how many x-platform languages with operator overloading do? Many people tend to mean Unix (and often Linux) and Windows when demanding x-platform capabilities, and Delphi addresses both to a very large extent (except the few percent of non-x86 Linux machines). Plus, it's got real to-the-metal horsepower, as opposed to most gc'ed languages.
No. You cannot.
It's 10 PM. Do you know if you're un-American?
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.)
I'm a concientious
You can have all those features and many more if you use a commercial Lisp implementation (the free ones have no decent IDE or GUI yet).
If you have a serious budget, take a look at Allegro Common Lisp. The other choice would be LispWorks, which is a little cheaper and without run-time fees.
They both have an excellent IDE and come with Interface Builders using CLIM, meaning your apps run under Windows, Macintosh and Unix (Motif) without a big hassle using native widgets.
-- The plural of 'anecdote' is not 'data'.
Let us take a look at how C++ compares.
Intuitive, easy-to-use UI, check. This is a stupid requirement for a language, though, as any reasonable language should allow your choice of UIs. I've used Visual Studio for C++ as well as emacs and, currently, KDevelop, which I like quite a lot.
Simplified GUI design and event handling. C++ does not determine how GUIs are handled but we use Qt which works very well for what we want. Visual Studio lets you do GUI design inside of it, as does Borland C++ Builder.
Advanced Error Handling. Define advanced. C++ gives you try-catch, etc. and provided you put a big of work into it, can be pretty good at error handling.
Advanced object oriented design including multiple inheritance, abstract classes, and garbage collection. Well, C++ is the language most people think of when someone says OO. That said, C++ does not have any built-in garbage collection which is in my opinion a shame. Still, you can plug in garbage collection if you want, though the URLs escape me. In my experience, this has slowed down the execution of my C++ applications considerably but that said, my applications tend to allocate and deallocate memory quite frequently.
Full support for operator and function overloading. Yes, C++ provides this.
Portable (at compile-time) across various platforms. Well, C++ is NOT, in my experience, as portable as Java is. That said, if you use a platform independent GUI library such as Qt and you are smart in how you code, you shouldn't have any great problems. Gnu Autoconf, Automake, and Libtool, published by New Riders, will help you out here.
So is C++ the language for you? That is impossible for me to say. The two major things it is missing is a GUI library (though Qt is excellent for this) and garbage collection (though this may not be a big issue). Personally, I find it easier to code in Java, mostly because Java does not allow things like multiple inheritence or operator overloading. Don't get me wrong, there is good reason to use these (and my C++ code occasionally does) but on the other hand, it can lead to much hassles. Very few projects really need multiple inheritence, for example, and MI can lead to all kinds of nasty problems. Do you really want to sink to the level of virtual inheritence, for example?
Really, though, we cannot help you out all that much more without knowing what kind of project you are working on. Your requirements seem to indicate this is not a small project. As a result, I'd advise against VB.Net, having spent a year working in VB on a project about a third of a million lines of code long. C# has potential (it is a blunted-scissors version of C++) but really isn't mature enough at the moment. Eiffel I have no experience with. Java is great in SOME circumstances but I'd hesitate to recommend it to you without more information. And then there's C++, which I have spoken about in great length here. But C++ is a tricky language to use correctly.
Oceania has always been at war with Eastasia.
Actually, Java ITSELF overloads the '+' operator; therefore, it's obviously a good thing just so long as no one ELSE can do it.
That's one thing I dislike about Java; it intentionally cripples the features available to the user whilst using similar features in the design of the language. For example, you wouldn't want to write Java in Java, because it just isn't functional enough to do a decent job.
pb Reply or e-mail; don't vaguely moderate.
I know powerbuilder has it's problems...but seriously it has everything you are asking for..
Basically the best way I've ever been able to describe it is that powerbuilder has the ease of design like VB but the power of VC++ behind it. For those who don't know it's sybase's baby, and I'll admit it does have bugs (but honestly what software doesn't).
But it's what we're using at my job and I'm happy with it.
You don't start with language, you start with requirements.
If this is a one shot project that won't need much maintance, then use whatever the majority of your devolpers know best. C/C++ have a large number of experts now for low level embedded work. VB has a lot of experts in the graphical front end area. Pytohon/Perl for (unix) scripts. If you are hiring new programers those are your choices.
GUI frontends are tools. If you do'nt like the ones you can buy write your own. In C vi vs emacs wars have been going on for years with no winner. In the mean time MS has sold a lot of compilers that use their IDE. There are dozens more in the free/shareware area, not to mention some compercial compititors. However I always have to ask WHY whenever someone writes a requirement to use any particular one. I can see saying that you will use MS's compiler for instance, but to require their tools is a mistake. Let the programer use their own, with the warning that you only support the offical ones. Make sure though that you can bypass the IDE you chose.
If this is projet that you intend to support for years, then there are a lot of C++ experts, which is a good arguement for using it, since you will have to deal with turnover. OTOH, a good programer can learn any language quick enough, and there are a lot of C in a C++ wrapper programers.
Through ugly hacks. You can support all of the features Java provides in assembly using similar ugly hacks, but you're still stuck using ugly hacks.
Working toward a usable PDA environment in the spirit of Newton OS: Dynapad
"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.
Why bother.
These requirements are terrible. Requirements should not specify implementation details. While abstractly saying things like Object Oriented Design with good GUI tools that supports event handling and good error or exception handling is fine, saying we HAVE to be able to have ths syntax: object1 + object2 is ridiculous.
1) Advanced OO design.
Ok, I can understand wanting OOD/OO Programming constructs explicitly supported. Abstract classes (and/or) interfaces and inheritance, etc. are all good OO constructs. But REQUIRING multiple-inheritance? Why? There are many good OO languages that don't do multiple inheritence. And GC has nothing to do with OO - while it might be a good criterion on its own.
2) Operator overloading.
This is such a crock. Is there anything that can not be accomplished without Operator Overloading? There are many arguments against using operator overloading in fact even in languages that support it. (Non-intuitive nature of it sometimes, the failure to implement all operators including comparisons, etc.)
If you take out the 2 dumb requirements above, you open the door to all kinds of languages:
Java, Python, Smalltalk, etc.
Then you can truly evaluate them on the availble RADs for the language, performance and suitability to the end project requirements.
Fire your boss!
Your boss has obviously taken a bunch of buzzwords with no clue what they mean and is making them requirements.
For example: "simplified GUI design and event handling;" Simplified compared to *what*? Xt is simpler design and event handling than Xlib. Tk is (imo) simpler than X.
Why does he know that he's going to need garbage collection or operator overloading?
The real thing he needs to do is look at the requirements of the project, the skills of the available designers, budget and time and go from there. I'd be really annoyed if my boss came to me and said "You're not supposed to be using C++ because it doesn't have garbage collection built-on."
Make someone else pick the language, and be sure to work like a dog on it.
You won't get blamed if the project ends up in the dumpster, but you will be recognized for trying to make it work.
If the project goes well, then you'll be remembered for you contribution but the person who picked the language will be forgotten.
Cynical, yah, but what do you expect when most managers have pointy-hair.
From the: Mind-Behind-The-Project Dept.
The real power of the language exists in the hands of the maker. The programmer. I've seen people take languages like BASIC and make a masterpiece out of it, better than a C++ programmer could have done.
Certain functionality is often needed for management reasons. Sure, you could use a language that doesn't support functions (hello, Applesoft BASIC?), but it'd be a pain to maintain. You could use a language that didn't have portability but if you're cross-platform, you're screwed.
However, make sure you have good people on the job. If they don't know the language, they should be able to pick it up quickly and have good technique. I'd give a hundred bucks more for a programmer that knew his shit with a crappy language than someone who was a newbie in the latest buzzword language.
Blog,Twitter
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.
The interactive way to Go -- http://www.playgo.to/iwtg/en/
yes, that's right. The programmer is what makes any programming language powerfull. You might as well ask what color is prettier. It all comes down to the opinion of anybody who uses any particular programming language. There are those that will say Java is better, others will say that C++ is better, and still others that sneer at the C++ crowd and say that C is better. Just pick one that fits most of your criteria that you and/or others in the shop are most familiar with. It would be idiotic to go with a language nobody there knows just because it fits all the criteria since the time spent learning the language well enough to make something good with it will end up costing more than the project is worth.
Steve's Computer Service, Hobbs, NM
On a large project you will have backend, middleware (sometimes several layers), and a front end. there is no reason these need to be the same language.
Remember the OSI model (which isn't always best). You should be able to take your top layer, running on Appletalk over token ring, you should be able to change it to IPX running on Hyperchannel without changing your application code at all.
You should be able to write your layers in several independanat parts, and change. Most programs are written in a language, but scripted in a different one. VB is a poor choice for time critical high speed data movement, but excellent for scripting a windows application (even if it is basic). Hand coded assembly is poor for user interfraes, but when you need fast code in little memory nothing beats it. (assuming good programers)
ps, brownie points if you know what hyperchannel is...
Language: C++
IDE: Emacs
GUI toolkit: GTK
GUI designer: Glade, Libglade
It all works; it's all free (in both senses of the word).
BTW, GTK, in my experience, works just fine with C++, despite the fact that it's written in C.
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
- -
Are you an SF Fan? Are you a Tru-Fan?
take a look at WxWindows. It's also been ported to work with other languages such as Perl and Python. IMHO it's prettier-looking than Tk and nicer-feeling to code in (more OO).
News for Geeks in Austin, TX
If Larry Wall is God, does that make Heidi Jesus?
I really got to get out more.
graspee
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.
It generates temporary objects that are created and deleted behind the scenes.
Note that if your operator is inlined and the compiler is reasonably smart, these temporaries are often optimized away. Usually when they aren't, the cost of the copy is low compared to the overall cost of the operation.
Ooh, a sarcasm detector. Oh, that's a real useful invention.
... the MCF (Mongolian Cluster Fsck), which sadly occurs when a committee gets together to decide things.
It's Linux, damnit! Pay no attention to renaming attempts by self-aggrandizing blowhards.
To answer the subject (rather than the submitted question), a language is made powerful by being turing-complete.
A language is also made dangerous by being turing-complete, since useful things like knowing if any given program will halt immediately become impossible.
To me, a good language would be one which has two modes: turing-complete, and turing-incomplete. If you need to write an operating system, go for the turing-complete mode, and code very carefully; if you're writing application software, turing-incomplete mode should be sufficient, and the compiler should be able to alert you to all sorts of bugs (eg, finding all possible infinite loops, deadlocks, race conditions, et cetera).
Tarsnap: Online backups for the truly paranoid
Depends on which version you are using. I've heard 6 made some huge executables. But you also have to know what to put in your uses clause. Take out what you don't need. Shoot, if you are willing to make the api calls, you can just put windows in your uses clause and you can get quite small apps.
If there is one downside to Delphi is that it doesn't make it clear that you can remove things from the default uses clause if you don't need them. Someone just starting out might assume that everything there must be there. Not so.
I'd pick Delphi too.
The question that really matters is what languages the programmers know and how capable they are when it comes to using a new language if it comes to it.
Why operator overloading should be in that list isn't clear. It's useful for math work, but confusing for almost everything else.
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
Not only that, but solve as little of the problem as possible. Someone else has probably already solved much of your problem and made available library/framework code that you can build on. The perfect language isn't if you have to re-invent every wheel with it. I do try to follow my own advice -- the availability of a partial solution for one of my problem domains is why I use Tcl a fair bit despite hating the language. OTOH if you want a language with cool features for the sake of coolness, I'd go with O'Caml.
really, it does.
Paul
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.
Hi,
do yourself a favour and take a look at
Objective C and the typical Frameworks
like Openstep or even more recent Cocoa.
As a converted Linux, now Mac User I recently
discovered those goodies and I really don't
understand why they didn't take off in the past
(NextStep has been around since the 80ies).
Objective C is such a powerful dynamic language
and it is real fun to write programs with it.
You have a clean and lean Smalltalk-in-C object
oriented syntax and are able to use all those
low-level C APIs... I don't know any better.
PS: For the use with Windows try to get one
of the OpenStep 4.2 packages one often find
at ebay. Besides the native Next/Sun/i386
OpenStep OSes it includes a devkit for
the use under WinNT... If use ever had to
use COM and alike, you will really, really love
OpenStep....
PS: There is even a GNU implementation of the
OpenStep API... -> GNUStep
Pointers:
http://www.stepwise.com
http://www.gnustep.org
I agree with everything here except for the part about Python. Ruby has more of the features listed by him like operator overloading and such, but I wouldn't recommend it because it is fairly immature compared to Java and I don't know about building GUI's in it. It also has some funked up syntax in some aspects and will take a little getting used to. I think that java is the way to go. The only other option is Objective-C which is definitly worth a look. Objective-C on OS X is probably the cleanest, easiest, and most complete API out there, especially when used with all the development tools that come with it right from the start. Objective C won't be as portable as Java, and when using it on OS X it will be even less so because the only thing you have is the GNUstep project to shift your code around.
This Wiki Feeds You TV and Anime - vidwiki.org
Often it simply doesn't pay to use a minority language, even if it seems better suited to the problem.
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.
--
Not exactly correct. If a product is guarunteed to solve all of your problems the odds are that it will solve a great many of your problems, but less than optimally.
There will be *some* problems that that it cannot solve at all.
It wall also solve *no* problems optimally.
The same largely applies to any purely mechnical device that claims to be "self adjusting and/or maintainence free." They always are, until they need adjusting or maintainence, which you then discover is impossible.
KFG
example:
---------
std::string a = "hello", b=", ", c="world", d=".";
std::string e = a+b+c+d;
std::cout << e << std::endl;
---------
No c++ compiler can optimize the temporaries out. Each temporary created calls the default allocator for string, which usually is malloc and free which are usually dead slow in an smp/multithreaded environment.
In this case, using strcat is many many times faster that operator +.
--Jeff
ipv6 is my vpn
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;-)
Regards,
Tobias
Regards, Tobias
"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 (www.rebol.com). 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...
graspee
If you have to have all those features, then you should be using C++ and instead of useing the normal memory allocation routines, just use a C++ Garbage Collector library. They are free, just use google to find them. C++ is the most supported language. It has every feature, and just because it has them doesn't mean that you should use them.
Personally I think that you should go with java, then only features that it doesn't have is operator overloading and multiple inheritance. Java has good graphical IDE and the code is more portable then C/C++
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.
*** Sigs are a stupid waste of bandwidth.
The java compiler is written in java so I really don't see what you mean by "Java in Java". Now perl, for instance, is an example of a language that can't build itself.
development.lombardi.com
I don't think there is anything that will satisfy each and every item on your laundry list. No offense, but it seems like a lot of buzzwords linked together. If your boss has any idea about the technologies available, he would not have put this list together. Looks like someone read too many "IT for managers" articles.
Seriously, how do you know you will need multiple inheritance? Or garbage collection? You have to do a very thorough analysis of your problem before you can come to these requirements.
MSN 8: Now Microsoft even has bugs in their ad campaigns.
So, here's my list
Does such a thing exist??? Every language has an IDE. Visual Studios, JBuilder, Emacs, KDevelopers, etc.
Well, this really depends on the operating system. Java's the good place to go here. If that can't be done, GTK and Qt are good libraries and they use the standard X style callback mechanism which is so much nicer than message based systems. What your really looking though is for a WYSIWYG GUI designer so I'd recommend Glade or whatever comes with the IDE you go with.
Such a buzz word... Java and C++ both use exceptions. Good error handling has more to do with a projects design though and not really the particular language...
Lets get our terminology right
IMHO, MI is necessary for advanced projects but Java interfaces _almost_ make MI unnecessary. You may do well to evaluate whether you truly need MI. What really matters, is how good your development team is.
This really should be in Java if you ask me but it isn't. You really don't need it. You could use interfaces instead. Of course, C++ support for operator overloading is great. Again though, you should really evaluate if you truly need such an advanced feature. If you just going to use it to concat strings then you don't need it.
Java or GCC. C++ is portable as long as it's GCC on both platforms
I think I'd have to agree with the general sentiment that you really need to evaluate your requirements because they are extremely unjustified and appear to be either (1) a bad manager, (2) pressure from employees to obtain "resume builder" skills, or (3) a very complicated project which you are not providing very much required information for
No language can satisify all your requirements perfectly. C++ comes closest. A combiniation of C++ and Java would do the job nicely.
int func(int a);
func((b += 3, b));
First off, gently tell your boss he's nuts to choose an implimentation language or environment by that list. Second, use C++. I don't like it, I don't know many that do like it but it is the standard. When the project is old and dusty there will still be C++ people who can hack on it. When you hire a new programmer, it will be easy to find one that knows C++. When your boss complains that the language and IDE's may not have all those features built in then explain to him that it is more valuable to have competent programmers with "good" tools than idiot programmers with "excellent" tools. If your boss can't see that using either C++ Builder or VC++ for Windows or the myriad options (GCC!) available for UNIX and kin then he isn't the least bit practical and you have to try to get someone else to grandfather a decision into your workgroup (e.g. a higher up boss says: You will use Borland!).
If you truely feel in your heart that your project would better benfit from Perl, Python, Java, Lisp, etc. and that benefit would last the lifetime of the project then make the case for that language or environment to you boss.
That laundry list of features is a bunch of bologna. Be practical.
I'd say drop that requirement and go with Smalltalk!! Post a few questions to comp.lang.smalltalk to get more details. It's proven, reliable, syntactically very easy and there's smalltalkers available to staff up with.
Why spend time solving language issues when you can solve the problems people are paying you for?
Just my cents: 2.
managers...why god invented purgatory
Delphi is great. As far as I know, Object Pascal is single inheritance, so that would fail the list of requirements.
Of course, the thing that Delphi has going against it is that it's not C++ or Java. That's why Borland released C++ Builder and JBuilder...
MSN 8: Now Microsoft even has bugs in their ad campaigns.
Interestingly I make my living providing this type of support to organizations. So here is my standard lead in... "There is no silver bullet." Okay, it is cliché, but it is so for a reason. No product does everything for everyone all the time. Those that get close are often ineffective because the overhead of running them is unexpected costs (system resources, training, or response time).
Are you planning to retrain your team to the tool and language of choice? Have you prepared for the cost and lost time due to incorporating a new tool and language? Are you prepared for the "first timer" punishment or will you be bringing in experts? Do you know how to tell if they are experts? Can you identify the difference between a consultant and contractor?
You mention support for multiple-inheritance. Some people argue that if it exists in an application you did not understand what you were doing. Are they correct? How would you know? "portable (at compile-time) across various platforms." Do you know which platforms? Across Linux, SUN, and AIX will be a different list than across Windows, AS400 and MVS. Support for "advanced error handling" and "advanced object oriented design". How would that differ from "standard" version? Does your organization understand how to weigh these features against their long term support and run time costs?
My experience has been when people ask questions like this, the building is on fire, and they hope someone will have a "tool" to fix a project that is 15 months behind schedule and $3 million over budget. Even if that does not describe you today, it may in 24 months. Determine your project feature needs, consider where you want to be in 5 years, look at the resources (people, $$$, hardware, software) in both cost and availability. These determine your potential for success. Then try to match products against the project.
If this describes your organization and you are taking this approach I strongly advise reading Rapid Development : Taming Wild Software Schedules It will provide the hard data to show your organization why you cannot tool out of a project issue.
When the time comes to choose a tool, the significant key is choose something that does not lock you in to anything. As you saw in your initial scoping of products, something will always be better in one product over another. Just avoid the position that a tool vendor must survive for your company to survive.
However, operator overloading is simply syntactic sugar and can be supplied either through an advanced IDE (I may look at jEdit to see how hard it would be to implement there) or through a preprocessor (jpp is one such preprocessor, though it seems hard to find on the net these days).
When doing operator overloading, it would be good to eliminate temporaries if possible. If a 'c' array object already exists before the assignment, it would be nice if "c = a + b" generated "c.assign(a.plus(b))" rather than the naive "c = new Array(a.plus(b))", which causes heap thrashing and unnecessary overhead. My guess is that this kind of optimization would be easier with an IDE type approach. (I hope that made sense!)
299,792,458 m/s...not just a good idea, its the law!
Galileo: "The Earth revolves around the Sun!"
Score: -1 100% Flamebait
Any temporaries in something like A = B + C will typically be optimised away if the operators are properly written.
More significantly, some of the most advanced techniques in C++ (expression templates) use operator overloading for precisely the opposite effect, leading to some of the most efficient output code of any language going. It would be possible to achieve this without operator overloading, but it would rely on the programmer knowing exactly what he was doing. With operator overloading, the class designer can do the hard work, and the programmer just uses + and * as usual, getting great output without having to know why.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Aren't these the exact goals of Kylix? I haven't used it myself, but from what I've seen it is an intuitive programming language suitable for general application development, with a nice GUI system.
-John
Yes, actually, they can; see "expression templates". I don't know of any major library implementation that currently does this, but the leading ones are all looking at the possibilities.
That's not true either, I'm afraid. Modern string implementations now use much smarter allocation strategies to boost performance well beyond a naive malloc/free approach. There are a few dragging their heels, but it's unreasonable to judge C++ by its worst examples.
That's rather unfair; this is a quality-of-implementation issue, and C++ library developers haven't included the state of the art tricks in optimisation across the board yet. Play fair and give them a year or two; C has had a couple of decades' head start, after all!
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
I've been working in PHP and Perl for about a year and a half now, and all my university classes are all taught in Java. While there ARE regex libraries for Java, they aren't standard, and therefore aren't used when testing student submissions. I find myself pulling my hair out time and again when I run up against a problem that could be solved easily enough with a regex, but requires, due to the language, that I solve it the hard, long-winded slow way.
If you're gonna write a new language, make regexes native!
From a design standpoint, sometimes MI is required. Sometimes an object does need to be two separate things. I am not a Java expert, but I assume a member of an interface cannot be overridden (if it could, than interfaces are just classes that support MI). So, what happens when you have an object that needs to be treated as two entirely separate objects in different places in your code?
Lets say for example you have a class representing humans, well, you may want to have humans be both a Mammal and an Earthling. Let's assume that there is no interconnection between mammals and earthlings (I couldn't think of a better generic example). You may want to treat a human object as an earthling in one spot of the code, and as a mammal in another spot of the code.
Assume that each of these have virtual functions that are overridden by the human class.
If you use interfaces to solve this problem, then that may work, but it's fundamentally wrong because one should treat an interface as a generic object that implements these functions verses an object that actually is this thing.
MI has pitfalls and can be used very incorrectly, but that doesn't mean that it isn't needed in a good number of circumstances.
I think the real problem with C++ is that it doesn't have interfaces (or signatures as G++ has done). That makes it necessary to have a great number of abstract base classes that really should just be interfaces.
That's a whole other issue though...
int func(int a);
func((b += 3, b));
hey now it's not my fault if they teach us Ada in college.
BTW, the ONLY languages that cover the entire set of design criteria listed are Allegro Common Lisp by Franz, Inc. or LispWorks by Xanalys. But something tells me that your boss isn't interested in hearing that answer, either.
That is all.
VB has its place. It's nowhere near being as good as C/C++ for 3D, server apps, drivers, etc., but it makes one heck of a good tool for developing simple user apps.
You most certainly can tell a swing button to do that. Look at the Method class of the java.reflect api. Hell in java you can specify the name of the method and java can go find it for you. Check out java.reflect.Method and its all there for you.
Just because you don't know how to do it in java doesn't mean it cannot be done. You can do what you say runtime in java. I.e. prompt the user for the name of the class, the name of the method and the paramaters and pass them. Try doing that with C++.
Slashdot: Proof that a million monkeys at a million typewriters can create a masterpiece
Rather than looking for a buzzword-compliant language, might i STRONGLY suggest that you read "The Pragmatic Programmer", by Andrew Hunt and David Thomas? The clear, solid, *useful* ideas in that book will maybe, just maybe, cure you of your faith in buzzwords - or at least your willingness to blindly march over the cliff your PHB just sent you to investigate.
Language features will not in and of themselves make for a successful programming project. I'd argue that they're merely a convenience for good programmers, and often and impediment for poor ones.
That being said, look at a multi-language approach to development - an interpreted scripting language (Python, Perl, VB(ewww)) mixed with a stricter compiled language (Java, C++(ewww)). And don't forget SQL, which is a respectable language unto itself, and very important if your project involves a database.
Good luck, and may the God Murphy Goddess Eris have mercy on your soul.
Hand me that airplane glue and I'll tell you another story.
[Sorry about the ugly plain text formatting, but it's sometimes the only way to get code examples in properly on SlashDot.]
:again
:again))
,expr) #'(lambda () ,@body)))
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)
(tagbody
(cond
((funcall expr-fun)
(funcall body-fun)
(go
(t (return-from while-func (values))))))
(defmacro while (expr &body body)
`(while-func #'(lambda ()
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.
Sorry, but you've got me completely there. How is the result in any way "unspecified"? (Please don't throw Mickey Mouse arguments about overflowing at me; I won't be impressed.)
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
AMEN TO THAT. Someone mod him up +1 zillion insightful.
Java is a language for typists, not programmers. one brain, many code monkeys.
...the job to be done is properly defined. It probably has to include maintenance, provision for the programmer's leaving the company, and so on. In other words, it's more than just performing the task at hand, it's the long-term objective that the tool you're creating is trying to achieve.
"Biped! Good cranial development. Evidently considerable human ancestry."
One last thing:
int add_one(int n) { return add1(1, n); }
Is that really so hard to do?
Slashdot: Proof that a million monkeys at a million typewriters can create a masterpiece
Believe it or not, PHP might be a good option on a technical level. There are a few really nice IDEs available for PHP, and with the new release of PHPGTK, its really shaping up to be a good all around programming language.
Skiers and Riders -- http://www.snowjournal.com
Still, given your feature list, CommonLisp may be your best bet (the CMU CommonLisp implementation for Linux is pretty good). It's a very expressive language and compiles into reasonably good code, although it doesn't have much static type checking, the language definition is messy, C-like performance can be hard to achieve, its C interface is a bit cumbersome, its libraries are less than stellar, and its user community is tiny. Bigloo, a compiler for Scheme, interfaces more nicely with the rest of the world and generates reasonably good code, but lacks threads and has a less expressive object system.
If you want something statically typed, O'Caml is a great language, combining object oriented and functional programming. It generates good code and interfaces reasonably well with C. However, you don't get overloading.
For great libraries, reasonable performance, and good standardization, Java can't be beat, but the language itself can be a little tedious. C# fixes some of the tedium of Java, but its libraries and performance are nowhere near as good yet, and it's pretty much Microsoft-only for now.
And don't forget about C++. For complicated numerical algorithms that need to run fast, there is nothing better than C++. For complicated GUIs, and interactive applications there is almost nothing worse, however.
So, overall, there just isn't a single answer. Every language is an engineering tradeoff. Learn many of them, and you will benefit both from the experience and the choices you have.
Ruby!
All of the above in sensible doses. Plus it's more fun. And a prettier colour. (-:
BTW, XP isn't a cheap ripoff, just a clumsy one. I suspect that the TCO will work out noticeably worse than WinME. Windows started life without scaleable elevators (to pick a known example) because one William Henry Gates III told the developers to take them out again so that it looked more Mac-like. Dilbert of a few days ago is fitting commentary.
Dons asbestos undies, prepares to duck...
Got time? Spend some of it coding or testing
Get good programmers, get their input on your implementation language and tools, declare whatever you decide upon as your shop's standard and get to coding.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
I'd definately go for GNU-Script.
Now, just click that link, and you won't even have to make the choice any more. GNU-Script does that for you.
May we live long and die out
"Fashionable programming languages don't equal useful software" - Eve Andersson
Slightly off topic..... but not at the same time....
-Tripp
Ada95. Only missing the MI thing (and maybe the IDE, but that's irrelevant, IMHO).
All the other posters have pretty much nailed your problem: The Boss(tm) is specifying implementation, not requirements. You need to determine what you're trying to do before you actually spec out the language(s). And <AOL TYPE=ME-TOO>your boss is simply throwing in every single buzzword he's ever heard.</AOL>
Further, who says you need only ONE language: Example: in a previous life, we had to do some Windows code, using a custom third party ActiveX control. Hence, we did the UI in VB, and the backend code in C/C++.
Fascism starts when the efficiency of the government becomes more important than the rights of the people.
I know about expession templates, and also know why they are not used in std::string. The allocator I am not worried about - if there are no unnecessary temporaries, then there is no need for unnecessary allocations. However, at this point, many stl's are still doing this.
So, in summary, yes now it is slower but maybe not in the future.... Is that fair to say? Does that mean c++ is not ready for prime time? of course not, I use it all the time. But you gotta know when to forgo the syntactical sugar that causes c++ to be unnecessarily slower than C (even when the C is coded safely).
--jeff
ipv6 is my vpn
It's like walking into Home Depot and asking the contractor's desk, "Excuse me! What's the best tool?"
;)
...I'd #define away their ridiculous verbose names into something short and memorable ...
Instead of writing unreadable code, maybe you should check out a new text editor. If you start using xemacs, for example, you can use Meta-/ to fill out the rest of a word. So, for example, if you have ever typed the word "SimpleDateFormatter" and you want to type it gain, you can type in "Simp" and the editor fills it in for you.
While I agree that a preprocessor would be useful in very, very limited circumstances, introducing things like "I don't like the name of that object so I will #define it to something else" is exactly the reason java doesn't include one. We don't want each developer to make up his own standards, much less his own names for things.
-Mike
Folks seem to be missing sheer idiocy and irony of this.
.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.
We have a CLASSIC boss who just wants to be buzzword compliant. I mean, look at that list. Reminds me of all the
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.
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.
Stupid job ads, weird spam, occasional insight at
You forgot to mention that with strcat, you are responsible for buffer allocation/deallocation.
For C++ you can write
--------
std::string a="hello", b=", ", c="world", d=".";
std::string e;
e.reserve( a.size() + b.size() + c.size() + d.size() );
// or e.reserve( SOME_APPROPRIATE_CONSTANT_VALUE );
e = a;
e += b;
e += c;
e += d;
std::cout e std::endl;
--------
Modern C++ implementations wouldn't create a temporary in this case because the target buffer has already been made large enough for the source data. The only reason you don't have to worry about it (and strcat seems faster in your mind) is that you have already made the multiple calls to strlen to make sure that the target buffer is large enough or you have chosen what you consider a large enough target buffer (which is subject to buffer overrun errors in some circumstances).
And it's still easier to use than strcat. AND this probably isn't your program's hotspot anyway. Premature optimization and all that.
- I don't need to go outside, my CRT tan'll do me just fine.
I have a dream, that one day people will know what they are talking about before they spout off like morons.
autopr0n is like, down and stuff.
I've worked on several projects that were coded in multiple languages ... whether it was a client coded in Python and a server coded in Java, or a series of programs coded in C++ and Perl all tied together in one big Perl script, or whatever.
Given the criteria that you laid down, I'm not sure that ANY language will meet your criteria. However, you might want to explore using a combination of Python and C++, where you use Python to do the majority of development (including GUI development) and C++ to write the 20% of your code that runs 80% of the time. GUI development in Python is a snap, and it gets even easier if you use GLADE. The one major disadvantage to this technique is that you don't have a single, simple IDE; you may end up with two IDEs, such as Visual Python and Codewarrior C++.
Just my two cents, probably worth less than that.
Finding God in a Dog
"Java 2" has been out for quite some time. Ever since JDK1.2 was released with a hugly expanded API. It goes like this:
JDK1.0 - Java 1
JDK1.1 - Java 1
JDK1.2 - Java 2
JSDK1.3 - Java 2 (JSDK = java standard dev kit, but everyone still calls it JDK)
JSKD1.4 - Java 2
etc...
autopr0n is like, down and stuff.
Say you have: ComplexNumber a, b, c, d, e, f;
. add(b)))))
Would you rather have:
((a^b+e)/c*(d+b+a+b)
Or
(a.power(b.add(e)).divby(c.multiply(d.add(b.add(a
autopr0n is like, down and stuff.
Interfaces are a subset of multiple inheritance, so they cannot be more powerfull.
Honestly, to me it sounds like the original question was a hypothetical one. If somebody actually did have a boss that laid out the "requirements" of a project in terms of what fancy buzzword features the development environment would support, then the project is doomed to fail.
The requirements need to be in terms of: what will the user interface look like? Is it client server, standalone, what kind of network communication is required, and basically everything else involving what is this application supposed to do? If you don't know any of that, it makes no sense to even pick a language.
This is like your boss saying he wants you to construct a bridge, and you have to pick ahead of time whether your bridge is going to be a suspension bridge, cantilever bridge, truss... well it's kind of hard to make that decision if you don't know how high or long the friggin' thing has to be, what kind of load will be travelling over it, and whether you're gonna be going over water. If you pick the wrong technology for the job, your project will go way over budget and the developers will hate every minute of it.
-CausticPuppy "Of all the people I know, you're certainly one of them." -Somebody I don't know
The question is so vague, it could only lead to the flame wars. Seems that ~581 people fell for it so far. You bait us telling us you have a stupid boss that wants you to find or create the perfect language.
...
The "brilliant" slashdot community spends the rest of the time flaming the daylights out of each other. Java is the best, no C#, no C++, no Perl,
Nice fake hotmail account too. Why don't they just ask us the question what features do you think make up the perfect language. Even posting this is a waste of time!
Yes, I think so.
Always the way... It's important to realise that this is a quality-of-implementation issue, though, not an inherent limitation. In a better quality implementation, you might find that the combination of +s was actually better than strcats, because a well-written template to do multiple concatenations could get away with a single memory allocation for the result, instead of the 4 required by strcat here.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Read Larry's Apocalypses -- 1, 2, 3 and 4 -- to see what I mean.
~shiny
WILL HACK FOR $$$
The two things it doesn't have that you "think" you want are multiple inheritance and operator overloading.
:) 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.
:)
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.
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.
We're on the road to Tycho.
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.
Damn! This sucks that there are so many comments already, this probably won't be read. Anyways.
;-) 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 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
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!
I'm afraid that I have to agree with the rest of the posters who feel the question the Anonymous Coward asked is stupid.
In that situation the poster should obviously just use the programming language he is most familliar with. Learning a new language is always going to take longer than expected. This is going to delay the project and put it over budget.
Of course, if the poster was familliar with a programming language he would know how to deal with the pros and cons of the language and so he wouldn't even have to ask the stupid question.
On the other hand, the question that Cliff posed about what makes a powerful programming language is an interesting one. Perhaps he could ask it again without the Anonymous Coward.
Would most definately have to be Brainf*ck. I really think it fits the bill for what you are looking for. It has great OO support, and is extremely easy to learn. The code you will create with it is tight and fast, and the possibilities are endless with what you can do with it.
.NET with the upcoming * operator in version 6. Check it out, you wont be sorry.
Take for example the following chunk of bf code:
>+++++++++[<++++++++>-]<.>++++++[&l t;+++++>-]<-.+++++++..++
+.
>>+++++++[<++++++>-]+.>++++++++++.
That code is a complete program, and will actually print out..."Hello, World!" can you believe it? In only 4 lines? Surely you jest? I can honestly tell you the answer is no, and dont call me Shirly. There are even rumors of bf supporting
(B) + (D) + (B) + (D) = (K) + (&)
I personally prefer C++ - it allows you to embed assembly when you want speed, do procedural and/or object-oriented programming, and, through the miracle of templates, allows you to achieve generic/template based programming solutions as well. Check out Alexandrescu's book on Modern C++ programming. Some of that code is pure poetry.
If ever there was a more portable, swiss-army-knife language, I haven't seen it.
Frameworks abound for it, you can do it with any of a number of methods, from vi to nice polished IDEs.
--- Jump!! Fire!! Bullet time!! - Lego version of the Matrix
I work with Delphi on a daily basis. Delphi supports (fully) all of the following:
LOAD "SIG",8,1
LOADING...
READY.
RUN
Delphi. It does everything and can be used by (clever) monkeys. It's main disadvantage is a lack of third-party support.
You were eaten by a grue.
I would have to disagree pretty strongly with using STL. As a programmer of game consoles (read TIGHT memory constraints and tough shipping restrictions), we found that STL's internal memory management to be a real horror. STL can allocate and deallocate more or less whenever it wants. We were fighting to have no memory fragmentation (which we have now), but with STL, this becomes EXTREMELY hard. STL actually increased memory problems. Finally we put in our own memory manager, and found all those stl classes and cleaned 'em out.
Now if only *printf wouldn't use the internal memory routines (they can allocate on their own too, but we can override those memory allocation routines!)
"Of all days, the day on which one has not laughed is the most surely the one wasted." -Sebastian Roch Nicol
Smalltalk is a GUI/IDE/Runtime development all rolled into one. It's so object-oriented even the number '1' is an object! It compiles on the fly and runs in a fully cross-platform virtual machine that's been ported to almost every known architecture. Check out the Squeak implementation of Smalltalk, and see if that doesn't make you beg for a good ol' functional language like C.
Looking for a computer support specialist for your small business? Check out
The true alternative is multiple-precision integers, transparently equivalent to small integers. Such as in Lisp. Lisp integers are limited only by available memory.
Of course, C programmers are used to a world where "+" means addition modulo some arbitrary power of 2. The 2038 bug isn't a bug after all---it's just where time starts to repeat, right?
Sometimes less is more. Having spent about 5 years writing and designing in C++, and about 3 in Java I tend to agree with the previous poster -- Interfaces are a more useful concept than MI. MI more often gets you into problem situations, and C++ MI doesn't express the Java concept of Interfaces nearly as cleanly as Java does. Java strongly encourages the programmer to seperate interface from implementation; C++ programmers think that they've already done that by writing a header file, but headers in C++ aren't nearly as easily extended as a Java Interface.
Not that I think Java is a perfect language by any means. Personally I think that whoever put garbage collection in the language should be roundly chastised by the thousands of programmers who've had to go hunting for memory leaks, but that is another story.
In all I'd guess that the Manager in question was asking the engineer to pick 'any language so long at it is C++'.
LibBT: BitTorrent for C - small - fast - clean (Now Versio
What makes a powerful programming language? Programmers do! The author of Turbo Pascal and later C#, wrote Turbo Pascal in assembly language. Crazy, but he made it a powerful programming language.
Our company uses Visual Basic and Visual C++. Both powerful languages, in the right hands. Define your requirements, and then find a language that suits that. Don't define the language before the requirements. That's ridiculous. If a language meets your needs, and the ramp-up time for learning it is low, then it's a good language for the purpose.
As for cross-platform, there are a number of languages that are cross-platform. Python appears to meet your needs, but I haven't used it so I can't say. Personally, I don't care for it, but if that were a requirement, I might go that way.
C++ is pretty good if you don't target it for a single environment. There are multi-platform frameworks, if you want to go that way. If you're going with command-line related stuff, then C++ is pretty platform independent, if you write it properly.
I'm not sure where you can get a GC library, but they are out there and undoubtedly someone else has mentioned one or two of these.
As many others have said, Java, VB.Net etc. fall short. No operator overloading, templates, MI.
C++ and good libraries are your best bet.
No, Thursday's out. How about never - is never good for you?
And a good sign of it being an emotional topic is that almost all of the posts are below my viewing threshold. Far more than normal.
Here's my take: I used to be one of the biggest Java advocates around. (In fact, I was one of the winner's of Sun's Java Cup programming contest.) I fought off learning Perl for years, but today, my language of preference is now Perl. Here's why:
- Portability - Where Sun brags about "write one, run everywhere", Perl actually delivers. Java's available on a few platforms (and even fewer, supported by Sun). But Perl has *much* wider availability. As one example of many, FreeBSD didn't have a reliable, supported Java implementation until very recently (if even now), whereas Perl has been there for ages. And somewhat disturbing is that the most reliable Java implmentation is on Sparc Solaris. Even I386 Solaris has serious issues. I guess making sure you fix problems on your own platform is a natural tendency, but it does go against the reliable portability that Java promised. (As compared to MS's anti-competitive behaviour, this is small stuff, but an issue nonetheless.)
- Reliability - I've had JVM's cransh on me, run out of memory inappropriately, and have other ugly problems. I haven't seen this with perl, yet. I've looked to IBM, Sun, Symantec, TowerJ, and others, for a solid, fast JVM, and they all seem to have fatal weaknesses.
- Consistency - I've found far greater consistentcy in the behaviour, performance, and reliability of Perl across platforms, than Java. I've seen Java seriously choke under pressure, and run out of memory. It might be fine for lightweight, run-once applications. But for heavy-duty stuff, it's repeatedly disappointed me.
- String Manipulation - In the majority of applications I've come across, *especially* web application, most of the work you end up doing is string parsing and manipulation. Perl's regular expression functions far outshine Java in this aspect. A one liner replaces a fifty-liner. Yes, the person maintaining the code has to know Perl regular expressions inside out, but I don't have a problem with that requirement.
- API's - CPAN seems to have far more exhaustive support for standard API's, well in advance of Sun's. They are usually more fragmented initially, and I would prefer the centralized approach of Sun, if it could just keep up. But it can't (or at least doesn't).
- Open Source - While Sun talks a lot about being open source advocates, Java's source is far more restrictive and harder to get or legally use, than Perl's. (Although I am against the non-commercial restriction of GPL. Hmmm, Perl is GPL, isn't it? Have to check that, as I'm not 100% sure, but it's a good guess.)
- GUI - AWT was efficient, but hard to use. Swing is very cool looking, with great features, but *slow*. Perl/TK is fast, efficient, portable, easy to use. It's by far my preferred rapid GUI environment. (A bit of foreshadowing perhaps: On my winning JavaOne entry, I used PackerLayout [I think], which was a port of the Tk layout mechanism to Java. Okay, okay, packer actually originated with Tk, not Perl, but since Perl/Tk is more or less the defacto Perl GUI, it's not complete out of context
:-)
- Multithreading - This is actually one point where Java shines over Perl. Perl has no standard multithreading, which truly, truly, sucks.
- Elegance - This is another area where Perl fails, but another area where it doesn't matter
:-) Perl is ugly, Java is elegant and beautiful to look at. But I can do more with perl, more quickly. And super-efficient hashes as a core part of the langauge allow passing arguments as key-value types, as is encouraged in their object programming model. This, I find more elegant. So at the surface, Java is prettier. But one layer down, where it really counts, Pelr is more elegant.
So in short, I've "been there, done that" with Java. Perl is liberating me from a lot of the problems I had with Java.(And on a rather irrelevant, but rather appropriate bit of symbolism: I happened to be wearing a JavaOne Long Sleeved T-Shirt tonight as I wrote this. The wrists were a bit tight, shrunk from washing, I guess, so I tugged on them to loosen them a bit. The whole sleeve ripped. Kind of symbolizes my experiences with java. Shoddy merchandise, all around
-me
Love many, trust a few, do harm to none.
True, Ruby doesn't have multiple inheritance. But as you point out using Ruby's mixin feature (allows you to mix a module into a class thereby adding a module's behavior to a class) can often be used in place of MI.
Using MI tends to get messy anyway, especially when you end up with some kind of diamond inheritance tree. I personally tend to avoid MI even in languages that allow me to do it. I have to say that I much prefer Ruby's approach of using Mixins.
I'd rather have:
(/ (+ (exp a b) e) (* c (+ d (+ b (+ a b)))))
:)
Got friends?
What Makes a Powerful Programming Language?
Come to think of it, I can recall a recent conference of well known language developers where they asked the same question. As a matter of fact, thier conference could have been called, "What makes a powerful language?"
Unlike the "What's the best language?", this question has the potential for a lot of interesting answers and opinions. It allows people to think creatively to solve problems with the status-quo in the language world.
These question also goes beyond, "What's the best language?", because it challenges a people to solve the problems with our existing languages rather than defend the stupid quirks and idiosyncratic features of an existing language.
Personally, I think there is a lot of room for improvement for existing languages and development environments.
One feature I think lacks in many good languages is the Interpreter feature. It bugs me all to hell that C++ and Java don't come standard with an Interpreter. Why can't I have strong typing and a dynamic typing together?
I'd love to have the option to choose whether I'm going to use determanistic finalization or garbage collection. What about support for units of measurements?
var x = 6 feet / 3 seconds
print x; '2 feet/second
There are so many ways one could improve languages. I think asking Slashdot is just one way we can tap into the resources of many brains to find some good ideas.
"Communism is like having one [local] phone company " - Lenny Bruce
what is the best religion?
Dear Slashdot,
My boss gave me the assignment to find the best religion. Some requirements that he gave me are:
<UL>
<LI>Should keep one from everlasting suffering and torment in next life
<LI>Should help one eventually pass to nirvana-like existence, eternal increase and well-being, perhaps even an all-powerful/omniscient state
<LI> Should help one to acheive balance, peace of mind, and a strong feeling of being alive within this imperfect world
<LI> Should enable the occasional performance of miracles when called for
<LI> Should improve behavior of followers (make them charitable and courteous but zealous in good causes), and help them improve the world
<LI> Should have limited numbers of flawed adherents
<LI> Should have a consitent theology that makes total sense to rational minds and mystics alike, yet is accesable to the common man
<LI> Should provide insurance against armageddon-like scenarios
<LI> Should have a finite (yea, even small) set of clear, detailed, and consistent directions for acheiving all positive results (Goedel's theorem notwithstanding). Not to mention avoiding bad results.
<LI> Should be in line with the will of the universe's most powerful entity.
</UL>
I've looked at Christianity (Catholic, Eastern Orthodox, Melkite, Coptic, Protestants of several stripes), Islam, Buddhism, Hindu-ish faiths, and primitive animism, Kibology, Shirley Maclain, Scientology, Wiccan groups, secular humanism, and both U.S. political parties, but they all seem to be missing something. Can you point me in the right direction?
Libertarianism is rich wolves and poor sheep playing gambler's ruin for dinner.
Several other people have addressed the issue of callbacks, but I am interested in talking about your assertion that interfaces are only for callbacks. Interfaces are contracts that are at the heart of polymophism, a client doesn't care "what" your object is as long as it provides the services you need.
Others may disagree, but in my opinion, multiple inheritance in C++ is the result of confusion between polymorphism and reuse on the part of the language developers. If you want to reuse multiple objects and also provide similar services to two or more of those objects it is much clearer to the observer of your code if those parent classes implement interfaces describing their services and you include instances of the classes you need as private member variables and you delegate to those private member instances in your implementation of the interface methods that you need to provide.
I think this is much better than having tons of confusion over similar method names with grossly different semantics, figuring out which parent class a virtual method is tied to, dealing with virtual vs non-virtual inheritance, and the tons of other things that make deciding through inspection who exactly implements the bar() method on your class foo next to impossible without having 4 monitors.
personal attacks hurt, especially when deserved
-Michael
-Michael
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?
The race isn't always to the swift... but that's the way to bet!
Amen, brother
The worst are casting operators, such as "operator const char*()", that can really lead to bizarre code and hard-to-catch errors because if your finger slips on the keyboard while entering an operator, you will all of a sudden vastly change the semantics of your code while the syntax, at a glance, appears the same. And who outside of the secret, special cadre of C++ gurus can fully predict the results when you have a combination of casting operator overloading and method overloading on a call? I end up explicitly casting objects such as _bstr_t that misuse this behavior and do not provide an alternative named method to avoid confusion in my code.
The totally weirdest is, of course, in STL, where they have the function operator such as "result_type operator()(const argument_type& y) const;" where for object foo you would call "foo(argument_type_obj)", and the object reference behaves like a function pointer. This can create some really cool algorithmic constructs like a "for each" in C++, at the mere expense of zapping your noodle with pyschodelic hippie mind rays.
personal attacks hurt, especially when deserved
I'm mentioning squeak because I don't see it in the list yet, not because I think it's the panacea you're looking for. But it's pleasant, smalltalk-ish, and (tautology alert) its adherents like it.
Libertarianism is rich wolves and poor sheep playing gambler's ruin for dinner.
The two most hyped programming languages ever are Microsoft's "Visual Basic" and Sun Microsystem's "Java". Though some might argue and claim that C++ is the most hyped programming language. Anyone want to start a discussion on "The Most Hyped PLs"?
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.
Ok guys, I need help finding a car for a biz project that my company is working on. My boss says that the car must have the following features: side panel wood trim, a hatch back, 60-inch wheels, a blue stick shift, firestone tires, a fiberglass bumber, and oh yeah, to be hip with the latest trends, it has to be a SUV. I am just having so much trouble finding a car that has all of these features.
- Uses Object Pascal language; no bugs due to bad type matching; less chance of memory leaks; no undecypherable source code (because Pascal won't let you do "clever" tricks that in reality only obfuscate the source).
- The GUI interface is a pleasure to use, with it's automatic source-code completion features which lets you pick and choose amongst the valid, legal field/methods/properties names.
- The event handling is simple enough: you just plug an event handler into a table of possible events for every given component, and the code is called automagically when shit happens; no more parsing at the message stream.
- Object Pascal's OOP has everything to offer to advanced OOP jocks. And the source code stays readable, too.
- Garbage collection is no pain with Object Pascal; properly coded destructors is the name of the game here.
- You will never overload enough Object Pascal functions... Full overloading is wholly supported.
- Compiles on both your neighboorhood friendly Win32 or Linux platform.
'Nuff said. Don't listen to the C/C++ dopes, they're just toying around with a sophisticated front-panel toggle-switch array...1) circular references aren't terribly common to begin with and can be avoided.
2) this is true, but I assume that if one requires GC than there will be a significant amount of garbage. It's simply, relatively painless, and is used quite frequently in C++. Therefore, for a production environment, using reference counting may not be as efficent, but it is more likely to be effective as it is maintainable.
Unless there is a readily available GC for C++ that works really well and is Free as in speech and beer? If there is, then use it, but I don't know of one.
int func(int a);
func((b += 3, b));
This is a red herring. One uses reference counting when shared ownership makes sense. Mutual ownership is at odds with "shared ownership".
2) you have ignored any time performance. Reference counting adds overhead even if you never accumulate a significant amount of garbage.
The overhead is very small unless you use copy-on-write, or the objects are very small. You only pay during construction, destruction, and assignment. And even then, the cost is substantially less than that of a deep copy.
For very small objects, there are other memory management strategies that are more suitable than reference counting. These can also be implemented in C++.
intuitive and easy to use IDE
Overrated. It must be because I'm getting along pretty well with vi.
simplified GUI design and event handling
This is a tough one. The GUI frameworks are unconditionally complicated. Use what you're team is most familar with.
advanced error handling
errno? Just kidding. But real exception handling is pretty expensive. Those are really your only options besides maybe something like this.
advanced object oriented design including multiple inheritance, abstract classes, and garbage collection
This is kinda funny because multiple inheritance a feature that is only justified in a very small number of cases (I believe it should be avoided alltogther) and is a really good way to get into trouble lick-ity-split, abstact classes is mearly a convention and really doesn't buy you anything in terms of functionality and garbage collection makes languages far too forgiving to the idiot using crappy data structures and algorithms.
full support for operator and function overloading
Well, you just want everything and the kitchen sink don't you? They did that already, it's that morass of a language called C++. Do the next guy a favor and pick features that suit the needs of the application rather than features you think will make it easier for you or the result will be indecipherable.
and portable (at compile-time) across various platforms
Why? Is this really that great? The XOpen and ANSI standards are designed to reduce system dependancies to the point where this shouldn't be an that much of an issue. Even if you're not using C/C++ the language binding likely is. In either case, as long as you consider the scope of those specifications your code should be portable without too much effort. Of course if you cheat and call those Win32 API functions it wouldn't matter what language you're using.
Sounds like you're trolling for some super Java/C++ language. It will probably never happen and rightly so because it would undoubtedly result in unrecognisable code that's dog slow.
I'm willing to bet your application could be written very well with plain ANSI C a few additional libraries and some C++ for the GUI.
But reference counting often is. For example, the g++ implementation does use reference counting, so the example offered should perform as well as +=
Materials engineers call the equivalent thing in their field 'unobtainium,' I believe.
OO is only one attempted solution to the larger problem of making programming easier on the programmer.
No. You're thinking of MSVC++ and drag and drop programming. OO is about modeling and it can be very effective.
It does this by trying to compartmentalize functionality and seperate implementation from usage.
This is the stuff trolls are made of Jayson. OO does not "compartmentalize" and it is not about contract programming. You have a very superficial understanding of OO principles.
Each instance of an object in a program is a model. You think about what it is conceptually that you are modeling and derive classes for those concepts. In practice these objects usually have hierarchial and recursive relationships. For example a stock is a security but a security is not a stock because it could be a fund. Or a WWW document has elements and frames where frames may be sub documents. These relationships are found everywhere and can be modeled most effectively using OO priciples. That's not to say you should use OO for everything (e.g. you wouldn't want to represent each character in a document using a separate object). Indeed I don't beleive 9 out of 10 developers using an OO language are actually writing OO code. It's modular at best. To use it effectively is non-trivial.
To see how OO has eschewed its own features just look at how delegation is favored over inheritance. This is a functional way of programming.
Like I was saying above, the results of OO are most effective when used strategically. The highest level superstructure benifits greatly from an OO organization. But using OO to a fine degree is not necesarily good.
Much of Lisp lives on in Java (and its clone, C#). Sure, Java syntax can be a bit pedestrian at times, but look a bit deeper.
...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.
Consistency?!
Okay, perl-the-runtime may do well for consistancy, usually. Perl-the-language is not consistant at all -- not between versions, not between syntactical constructs, not anywhere. There are so many places in the documentation where words like "except", "excluding", "but" and company are required that it's practically impossible to remember all the little nuances of its syntax at a glance. And I had all sorts of code break between perl 5.005 and 5.6. Having a language that tries to read the developer's mind for the sake of TIMTOWTDI may sound like a good idea, but it leads to all sorts of problems (just like laws that place penalties based not on people's actions but what goes on in their heads). You can have TIMTOWTDI or you can have an internally consistant language -- not both. I pick consistancy -- TIMTOWTDI may be damn nice when it works, but it's a royal pain when it doesn't. I haven't had to read a language reference in Python since 2.0 came out (with a few new minor language features), whereas as a Perl coder I hit the language ref docs every day.
Python's PyGTK beats Perl/TK into the ground on both speed and ease of use. Build a really big grid of pushbuttons and labels and such in tk, and do it again in gtk. Then tell me tk's fast. (Never mind the usability differences between them -- unless you want to, in which it's another huge win for gtk). As for ease of use, I have one word: libglade.
Python's runtime environment is not only extremely reliable, but it's also readable, so mere mortals (who know C) can debug or otherwise toy with it. Try doing that with perl! (Further, Python can cross-compile, whereas cross-compiling perl is an evil, evil task -- I know, since I had to make it happen for my job). And writing bindings between C and Python (in either direction) is far, far easier than using Perl's XS interface.
Did I mention that Python uses PCREs? Yup, you get all your perl regular expression goodness, but with code that's actually maintainable. WooHOO!
As for the "elegance" argument... well, I don't even really have to argue it, do I?
Nicely put.
Check out Deja news list of compilers, where the programmers got to vote
Deja news? Was this post stuck in the queue since 1998? Seriously, got a link?
Pick Perl and then use whatever language you like.
Different languages have different strengths, and with no idea of even what industry you work in it is not easy to tell whether you are building real-time physical process management, security tools, or what. So right off the bat, I have to say you are going at this ass-backwards.
That said, Perl has all of the above functionality, and is the highest level language which does so. That means you can abstract as far away from the nitty gritty as you like, or you can hit the metal. It also is a superset of the languages you mentioned, so if you want you can program in Java, C, C++, or many other languages and insert that source code right into your Perl programs, Inline (not using XS). GUI through Tk, Qt, or other packages are possible. It is probably best for you, unless you already have a great Java team, or you are writing a video game or have a lot of flashy graphics. I was going to say, or if you want to sell your product as shrinkwrapped software, but that isn't true anymore with ActiveState's DevKit.
Python might be good, though it seems Perl is still going to have more support for different platforms and general ways to save yourself from trouble. I have to say I have way more experience with Perl than Python myself, though mainly this is because it wasn't mature enough when I was seriously considering a switch, and now because I have no need to change and the future for Perl looks very bright. I get more return on my effort with Perl, it's that simple. You could also use C/C++ with one of the popular cross-platform GUI toolkits, but the more flash the less portable in general.
Another person recommended English, another good choice. The closest language computers understand these days though is Perl, and the language itself is easily to extend. Maybe the best thing to do is figure out what you are building first, then pick the right language. Perl doesn't solve every possible problem, it just seems more likely to be all-powerful than anything else out there, that's why it is the glue of the Internet.
I haven't explored Python personally myself, but at last a couple of strong tecchie's that I know and respect, are big Python fans, which means a lot to me.
:-)
:-), running on the open source Risc hardware, yadda, yadda, yadda. I think we'll get there eventually, but we've got a few hurdles to clear before we get there. A fun time to be alive. :-)
I don't doubt that Python is more elegant and consistent than Perl. (It wouldn't be hard
But the *huge* libraries of supported API's on CPAN, and the fact that the differences between versions is *well* documented (with source available, even), and the fact that the source can easily detect what version it is running under, and make appropriate adjustments, makes it still preferrable to me. Predictability and API support can outweigh Elegance, in my book.
Yes, in theory, and in my heart, the more elegant solution is the best. (At heart, I prefer AWK to Perl. But in practice, I can't do as much with it, as easily.) So, in practice, I will still choose what lets me accomplish the goal, which today, is still Perl. I'll check out Python, but without the same CPAN support, I doubt I'll switch today, or any time soon.
I'd love to come back in two years with a future slashdot post, where I talk about how Perl came to let me down, and I've now moved on to the far superior, far more elegant, far more support, Xyzzz language. Let's hope. Maybe it'll run on the newly open sourced QNX
It's only going to get better folks, as long as we keep the monopolies (okay, monopoly) from completely eliminating our choices of platforms and OS's.
-me
Love many, trust a few, do harm to none.
Second, I am not one one of the "objects as real-world entities" people. I believe strongly that to effectively partition work -- to make programming more tractable -- many times you will create work partitions and create objects that have no correlation to the real-world. A contrived example would be a deck of cards. Imagine that you make each card an object, then you have a deck object, and a dealer object. In the real-world the dealer would shuffle a deck, but in our code this responsibility would fall on the deck, but the dealing mechanics would probably rest with the dealer.
I am the kind of programmer that believes in active objects. I am the kind of person that makes everything an object. I make all my constants objects (for type checking and I cannot stand it when people use integers for this) and slowly through most development I have done, these once data-only objects gain methods and no longer become just place-holding constants.
I think that to effectively use the OO paradigm, you need to really abuse it. I use dynamic dispatch for almost all my flow control; try finding even an 'if' statement in my code. I even have the_empty_tree_node objects that don't do anything except return so my tree recursions don't need a base case. This abuse is non-trivial; you are correct. I have spent alot of time abusing C++ and Java for it to come more naturally to me.
However, I don't think it will ever come as naturally to me as functional programming. I am not saying that I do not use OO techniques in my functional code. You can see a sort of dynamic dispatch mimicked by function passing and you can see pseudo-object in functions that return different functions, each operating on the same lexically captured bindings. I am just saying that OO is over-hyped and I feel that the functional paradigm effectively captures OO benefits.
APL's style of data oriented processing has also shown to be much faster and require far less code. Why develop a library when it only takes a single line implement the functionality? Also when you language supports dynamically evaluating a string code reuse in terms of modifying a string then evaluating is phenominal (plus the on-the-fly compiler gets to optimize the hell out of it).
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'.
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.
How to rationalize theft.
Sorry, Slashdot post length won't allow it. Your post doesn't demonstrate anything.
Why not try Borland Delphi? It meets all your requirements except Multiple Inheritance (can be emulated) and real platform portability (but so does C# and VB.Net). Atleast now you can develop Windows/Linux solutions using Delphi/Kylix. When it comes to good IDE's and easy GUI development Delphi is right on, you'll never look back. Tom.
However, for C++ check out The Lambda Library, it's an extension to STL that, among other things, blows my mind.
And while your programmers are all off on a three week course, your competition is releasing a slightly less elegant, but functionally equivalent soltuion before you are, because they just used the language they knew. Congrats, you're out of business!
It just isn't worth it in the long run to go with a minority language, even if it has features that are elegant. Yes this is dismal, but at some point the market for programming languages was going to become a two horse race. C'est la vie.
Congrats! You are now a purveyor and advocate of a minority language. Take a seat beside the COBOL programmers trying to eek a retirement out of the last contract they can land.
Its amusing to note how not one person on this article makes any mention of economic factors. Sure, go ahead, use ML. See you in two years.
It generates binaries for Windows, Mac (9&X) Linux, Solaris and bunch of other Unixes.
It has graphcial GUI design tools
It is programmable in a object-oriented language that reads like English.
You can extend it in C if you want.
It has a good free trial offer.
http://runrev.com
I built the Pocket GoogleWhacker in it for 4 platforms in under an hour.
URLs To backup my bald assertions below. Browse the sites and you'll see studies and numbers. Facts not Religious opinion. Adapower is a good start. Or the Ada Information Clearinghouse
IDE - there's a variety of freeware ones.
Simplified GUI - there's a variety of bindings to various APIs, from X-windows to SWING to W32. Plus many other simplified freeware ones, some thin, some thick. Pick which one is most appropriate. Ada (the language) doesn't have anything more advanced than stdio - but then again, neither does Java, it relies on the awt and swing libraries *shrug*
Advanced Error Handling - Java's exceptions contain more info than Ada's. Ada ones are more simple, easy to use, but I think Java's are better in most ways. They should be - both C++ and Java copied their exception handling from Ada's 1983 incarnation. OTOH most of the time all Java programmers (like me) do is make an exception without using any of the internal data, so YMMV.
Advanced OOD including multiple inheritance and abstract classes - As regards OOD. Ada's the most flexible of the lot. You can do strict OO, but don't have to. Methods are properties of Classes(actually packages) rather than objects, so you can say Wooden.paint(a_wooden_door) or Door.paint(a_wooden_door) rather than a_wooden_door.paint(). So you get all the advantages of multiple inheritance, without the horrendous penalties (which method are you inheriting, the paint for wooden things or the paint for doors?). Abstract classes are used all the time.
Garbage Collection - Ada doesn't produce garbage in general. You can do most things using statically allocated memory, or dynamic allocation within a statically-defined garbage-collected area. When you want dynamic allocation, you can choose to rely on the compiler's garbage collection, if it exists, but you're also given tools for explicit disposal of garbage. Note that Java has true garbage collection, but even Sun says that you can't rely on it, you should use explicit disposal. This is true not just for Java, but in general.
Operator/Function Overloading Ada has had this since 1983. Often copied, never bettered
Portable Stories abound of million- and 100,000-line Ada programs that require a dozen lines changed to make em work on different systems. My own personal war story is of a 20,000 liner developed on a 386 on an Irvine compiler, ported with 3 lines changed to a MicroVax using a DEC compiler, thence to a Vax using another DEC compiler, then to an embedded system using a DDC-I compiler. Was an AI to do anti-missile defence, people's lives depended on it. It's been in service since 1995. Cost less to make than the 7,000 lines of C in its test bed too. I've just help finish a 20,000 line piece of spaceflight avionics that makes not one Operating System call, even though it has 60+ simultaneous threads of execution. Oh yes, there's a shareware (or GNU licence? I forget) Ada compiler that produces Java bytecode, so will run on any Sun JVM.
So why isn't Ada-95 used by anyone? Because everyone knows it's too big (nearly as many keywords as C++,), needs a huge machine to run (bigger than a 286 running at 4 MHz - which was big in 1983 when Ada-83 was invented), it's designed by a committee (like Linux - one really good designer Jean Ichbiah, then peer review), and it's a product of the US Military (like Unix, and the Web - designed for not by). Oh yes, and expensive (GNAT is open source...) and uses a lot of risky concepts ( to wit, Operator Overloading, Object Oriented Design, Exceptions, all risky and untried in 1983 ). It's also obsolete, (the Ada-95 version being a little younger than C++). And it is used, for Avionics of all modern airliners ( Illyushin, Boeing, Lockheed, Airbus) and many satellites, railway- and air- traffic control systems, where quality is vital. It's not used much elsewhere, as there's a vested interest for software developers and programmers to keep software buggy (so they have job security) and quick to market (it takes a long time to develop reliable software).
So Ada's perfect, right? Wrong. It's just better than most general-purpose languages for many purposes. BUT It's not language of the month ( C# this month? ) so getting Ada programmers is very difficult. Though it's easy to learn, based like the similar Eiffel, Delphi, Object Pascal and Modula-2/3 on Pascal. If you've programmed hardware design in VDML, or used Oracle's access language, you've used Ada without knowing it.
Zoe Brain - Rocket Scientist
Intercal
"that's not encryption - it's a new perl script that I'm working on..." - from some Matrix parody
Correct, as long as you are not in a multi-threaded environment. If you are, then there will be synchronization overhead for all individual string operations, as even const methods can modify the reference count.
--Jeff
ipv6 is my vpn
Support, Availability and Librariers
In reality these features are far more important than the language features, it' syntax, the look&feel, etc.
All successfull languages have these, a strong community thats behind the language (support), at least one free as in beer compiler, and dozends of libraries written by the community backing. These things is what one should consider more important than the ohhhs and ahhhs the language itself offers.
Look there are at least a dozend "experimental" languages that are really superior to the list you give, but the compiler might not be yet that mature, only the standard library exists, etc.
C is inferior, C++ is even more. But why do people use it? Because it's always first on the availability list for new techs, libraries, targets etc.
--
Karma 50, and all I got was this lousy T-Shirt.
Reference linking does.
Here is a paper that describes a Java Virtual Machine written in Java.
Implementing a Java Virtual Machine in the Java Programming Language
Such as? (lets see, docstrings, tuples, what else?)
Non-blocking threads. Unicode. Simple syntax. Fully functional JVM port. Palm port. Plan 9 port. Strong COM and CORBA support. Sophisticated numeric library. Excellent graphics package. Several IDEs. Bundled with most versions of Linux. More robust Windows port. Clear license (finally!). Large deployed applications like Mailman, Twisted Matrix and Zope, dozens of books, etc. etc.
The same thing could be said the other way: Ruby has features which have no counterpart in Python (of course Python 2.2 added some of these features (like iterators and a more unified type/class system (but Ruby had these from day one) )- but since they've been added so late in the game Python's built-in libs do not use them, so you end up with a patchwork of Python pre 2.2 and PYthon post 2.2.
Python always had an iterator-like syntax. The only change is how the iterators are implemented. Similarly, types and classes always behaved similarly. Now they are just the same thing under the covers.
As mentioned, Ruby had a unified type/class system from day one meaning you could extend and subclass built-in types from the start. Ruby also had iterators from the start as well - the significance being that Ruby's collection classes (like Array and Hash) use iterators. Python couldn't till now.
Oh really? I wonder what the xrange function did? If you don't know Python, why not just admit it and move on. You're a poor Ruby advocate if you can't even come up with a single Ruby feature that Python does not have...only features that Python did not have until recently. Even as Python advocate I could do better than that in promoting Ruby! But even so, I think it is pretty clear that in the areas where Python was weak, it is catching up or has caught up and in the areas it is strong, Ruby has a Long Way to Go. Native Threads, Unicode and a JVM port are each person-years of effort.
Ruby simply didn't offer enough of a reason to switch off of Perl, Java or Python. Its elegant but not groundbreaking, and frankly the market for programming languages is already overpopulated.
You don't have to win to survive. There are still people around promoting Objective-C! Ruby has found an audience and will continue to strike a cord with disaffected Perl programmers who choose not to use Python (perhaps out of a sense of pride, or because they really don't like its style). Also, Ruby will probably be a very major language in Japan: perhaps the most popular high level language there.
What is up with this 'Swing is slow' crap? I know Swing is _slower_ than native widgets and even AWT, but it's not *slow*. After the initial JVM load time, I always had more than acceptable performance on my PPro200/64MB, even when using complex Swing-based GUIs, and I highly doubt that any business undertaking a supposedly massive new project is going to be sitting around on anything that gutless.
my sig's at the bottom of the page.
All serious next-gen GUI platforms are Unicode now. If you're not using C++ for other reasons, don't pick a language that isn't fundamentally Unicode-based if your goal is GUI apps.
Ruby is like Perl. It's for parsing and filtering byte streams, and like Perl it's great for that sort of app.
Such languages are not ideal for interactive GUI apps that are all about visual display and interaction. Go for Java or C# or VB.Net or C++/KDE and forget the MI or overloading nonsense. That's not how you pick a language.
"Those who have never entered upon scientific pursuits know not a tithe of the poetry by which they are surrounded."
...for a number between 3 and 10 that's divisible by 3 and prime.
Show your boss a list, with what they do and don't offer. But you're not going to get all those things in a language that is widely-used.
By the way, I happen to like the way Java and C# do things with no multiple inheritance. Instead, you use interfaces, and you end up avoiding a lot of potential headaches. GC handles memory for you, etc, you have a modern, rich library of tools included, etc.
Donate background CPU time to fight cancer.
I haven't seen any Swing apps that I would consider "peppy" by any means, even on reasonably fast hardware. LimeWire, for example, is what I would consider one of the premiere deployments of a Swing-based application. It looks great, works well. But when you click on a tab or something, you have to expect a noticable delay before the screen updates.
Usable? Yes, most of the time. Fast, no...
-me
Love many, trust a few, do harm to none.
"Oppression and harassment is a small price to pay to live in the land of the free." -- Montgomery Burns.
But at least C programmers are going to get to 2038 this century. If you start arbitrarily replacing nice, high-speed integer types with "multiple-precision" integers, the performance hit you're going to take is going to be huge. The vast majority of the time, overflow is not an issue in C or C++, and the nature of their integer types is advantageous. If overflow is an issue, you're probably already using a dedicated maths library that takes care of these issues anyway.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
intuitive and easy to use IDE;
emacs + perldb; cvs co, cvs commit
simplified GUI design and event handling;
use CGI; while() { s/INPUT NAME="(\w+)"/INPUT NAME="$1" VALUE="$$1"/gi; print; }
advanced error handling;
eval { fail; }; die "failed: $@" if $@;
advanced object oriented design
package Object; use Tie::Hash; my @ISA=qw(Tie::Hash); 1;
including multiple inheritance,
@ISA = qw(Tie::Hash IO::File);
abstract classes,
use Tie::Hash;
and garbage collection;
{ my $x; }
full support for operator and function overloading;
@ISA = qw(Tie::Hash);
sub STORE { warn "Here!\n"; shift()->SUPER::STORE(@_); }
and portable across various platforms.
unix, Win32.
I think, therefore thoughts exist. Ego is just an impression.
Only if it knows at compile-time whether or not the numbers might overflow. Otherwise, one way or another, you're going to have a big run-time hit.
No, it's not. My little for(int i = 0; i < 10; ++i) isn't going to break any time in the future due to overflow. A count of entries in a database might, but you shouldn't normally be using raw types for specialised values anyway. Your reuse argument is fallacious simply because reuse itself is largely a fallacy outside of library code, and library code should be designed with robustness in mind anyway.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
1) having to distinguish between different kinds of ownership means you have to restrict your design to fit the memory management model. This is progress? In Lisp, it is relatively common, for instance, to create circular lists to represent arbitrarily-long periodic sequences. With reference counting, your "list" abstraction either isn't abstract enough to handle this, or this usage has to be forbidden or made a special case.
2) overhead at assignment: this is exactly my point. The reason you go to GC is that assignment is common enough that you can't explicitly keep track of ownership without making a mistake or going crazy. In reference counting, you spend time incrementing and decrementing counters even if the thing never becomes garbage. An object only becomes garbage once (ignoring certain finalization or "weak pointer" issues), but you pay many times.
It basically boils down to this: GC was basically invented by and most researched by the Lisp community. Not a single Lisp implementation I know of uses reference counting because its run-time performance is dominated by true GC.
It's truly amazing to see the turnaround. The beef against Lisp used to be "perhaps powerful, but too bloated and slow." Now, 20 years later, Lisp has gained (in relative terms) in speed by aggressively pursuing compiler and GC technology, and has (in absolute terms) stayed about the same in memory consumption as RAM prices have plummeted. Now we find out it is all right to give up speed and memory consumption as long as you support ugly notation that has to use every punctuation character in *at least* one way.
Take a look at Jade. It was designed and built by Aoraki Corporation, whose previous succes was Link(?). This includes an integrated object orientated, transaction based, distributed computing alternative. Just Another Development Environment.
Well if i look at his CV I think we will end up with C++. Not to mention he names it twice in the languas he looked at.
Next question:
what runtime libraries? What IDE?
Hey, don't knock debugging by printf(). Saved my ass at times when the shiny debugging tools failed.
N4st0r, trixx0r h0bb1tz0rz! Th3y st0l3 0ur pr3c10uzz!
"Better" doesn't matter. In how many markets for any type of product does "best" win????
Lisp is dead, even if its better. Learning it now is a waste of time.
If shared ownership is not a good model (which it is not with any node based data structure), then don't use it. For a linked list, the obvious ownership strategy is for the list to own the nodes.
In reference counting, you spend time incrementing and decrementing counters even if the thing never becomes garbage. An object only becomes garbage once (ignoring certain finalization or "weak pointer" issues), but you pay many times.
Incrementing and decrementing counters is a very fast operation. It's only a performance issue if your object can be copied very quickly. The main overhead issues in reference counting are memory overhead (for very small objects), and multi-thread overhead.
It's truly amazing to see the turnaround. The beef against Lisp used to be "perhaps powerful, but too bloated and slow."
There's nothing wrong with LISP, but it's kind of silly to compare it with C++. The design goals, and hence the benefits are not even moderately similar.
As for the monkey with a keyboard thing... mmhhh... could you define what a real programmer is to you first please?
Overcaffeinated. Angry geeks.
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.
Although I am against the non-commercial restriction of GPL. Hmmm, Perl is GPL, isn't it?
Perl has the Artistic license which essentially says you can choose whether you perl modules / perlX patches are GPL'd or BSD-like (don't remember the details of the more free-varient).
So GPL advocates can promote their anti-pay mentality, and businesses can still make money.
-Michael
-Michael
If shared ownership is not a good model (which it is not with any node based data structure), then don't use it. For a linked list, the obvious ownership strategy is for the list to own the nodes.
And if an object is in more than one list? It has to be copied anew? What if it doesn't make sense to copy/clone it? Clue: there is no single definition to "copy" which makes sense for all applications. The notion of "copy" has to do with the notion of "identity" which is not a fixed concept. Again, you are forced to fit your abstraction to the need to track ownership.
I'm interested in your comment that Lisp and C++ have different design goals. Common Lisp is designed to provide the programmer with a flexible, robust, object-oriented environment, suitable for large programming tasks. How does that differ from C++'s stated goals?
1) you are exaggerating the "big run-time hit." Testing for overflow in addition of fixed-size integers is going to be easily pipelined. Sure, when you actually overflow, you will have to branch and transform your representation, but the alternative was to get the wrong answer?
2) Your for loop example is exactly the kind of case that a compiler will optimize to be kept in fixed size registers.
As usual, we see the "New Jersey" design technique. Better to be "fast" and sometimes wrong than always right.
I find it interesting that counting the number of entries in a database is somehow a "specialized" operation. So anytime I want to count anything that there might be "a lot" of, I have to use some non-built-in multiple precision arithmetic package---who knows how well it was optimized, or whether it's buggy---instead of a vendor-provided, standard-mandated ability of the language?
I still think that java is too new to use for generic enterprise operations. I've worked with Java+MsSQL-server, Java+Oracle, Java+ANY GUI, and I've regularly found production flaws that we've had to work around. I'm sure newer versions of java fix many of the older problems, but the API dramaticaly changes so often that you're CONSTANTLY on the bleeding edge. Since they haven't given enough time for a given API to settle down across multiple platforms (e.g. open-sourced initiatives can't keep up), I doubt that Java will ever achieve robustness. To further the point, a new version of JDBC just came out with boat-loads of new untested features.
Java CAN work, if you pick a robust platform, a robust version and well-aged API components. But it's very tempting to use the latest / greatest, because functionally it solves your problem more efficiently, and thus you're prone to bizzar production-time errors (as I've encountered).
In comparison, the basis of the perl language only changes in the major version levels. And we've been at perl5 for a Very long time. Most of the change is in the CPAN modules, which given enough proving-time probagate down to the standard distribution. The changes to the core are rare (only in perl5.005 did threading / agumented reg-ex's really hit and thus cause some stability issues). Thankfully many of the features were off by default, and some (raw threading) have since been revoked. It's a VERY different mentality, than MS / Sun, who seem to want to sell themselves via feature-bloatware.
I would be very interested in seeing your benchmarking results demonstrating this. Part of the problem is that you're comparing apples to oranges.. You don't solve problems the same way in Perl that you do in Java.. Java is a forced solution (e.g. OO with method-based operations). Perl uses a combination of simple function calls, HEAVY use of low-level C-based functions, and a sprinkling of OO here and there - just to pretty up the API. Granted, OO on Perl 5 can be horrendously slow (especially if you have the inheretence-tree of java; given the linked-list lookup style method dispatching). But Perl's garbage collector alone puts Java to shame. My Apache apps with mod_perl never exceed 30Meg each (with large amounts of large-temporaries), while most of my apps never reach a meg in size. My Java-apps HAVE to start at a God awful size and are both CPU and memory hogs (non ref-counted GCing is horrid for page and cache thrashing). Yes there are memory leaks in ref-counting, but it's well known and designed for in perl5 APIs (or you spank the module writer). The only potential pausing that ref-counting does in perl5 is deallocation of massively nested structures. But then again, perl5 is more determinisitic than java (at least until perl6, but I won't get into that). We're not even going to get into the *cough* jit-startup time.
Again, apples to oranges. Perl5 uses strings as a fundamental data-type. Integers, floating point, exceptions, error-messages, parameters. Just about everything (short of tcl) is at one point potentially a string. While I don't know how intentional this is, this fact allows a dramatic efficiency when making string-manipulation the number-one priority for the language. While in Java you could apply a sequence of catch (ObjType1) catch (ObjType2), etc, which essentially becomes a switch statement, in perl you are relegated to if ( $@ =~
Thus, the power of the string can in no way be cast aside (simply because c, c++, java finds 5-10% use for it).
YES!!! There is more to Perl than Tk. There is Gnome, Qt, MFC.. The only thing I'm not aware of is Swing proper, but who cares, it's not a great design and buggy as hell!! (Maybe as of 1.4 the 1.2 features work properly, but not across all platforms).
Gnome even has a perl generator within Glade.. I find glade MUCH nicer than forte' (at least the version I last looked at).
I disagree. Multi-threading is inherently non portable. Personally I believe MT allows for bad design. The programmer gets lazy and just relegates tasks to other threads (ignoring the scalability and communication overhead). While certain classes of operations are more efficiently handled in MT (especially on MP systems), the majority of algorithms can have the highest in performance with single-threading. MT is great for response time, and it does have a certain elegance, but don't talk to me about elegance when debugging MT code.
That said, there is, of course, primative MT support in perl5, and perl6 will support it natively (though I believe (and desparately hope) that MT won't be required, nor activated by default). I say primitive, not because they're limited in functionality, but instead in efficiency (global locks, etc). I BELIEVE the stability is sound, but the CPAN library support is non-existant (just try and compile an Oracle DBD with use5005threads enabled).
Lastly, I'd like to point out that my disagreement is with the phrase "modern application". A modern _language_ should most certainly provide robust thread-like facilities(even if it's just virtual threading), but most certainly threading does not apply to MANY real-world applications. Take web-services for example. There is a big push for MT web servers.. Apache 2.0 is a good example (of course IIS has always had it). While MT allows rapid concurrent static content retreival, it has several costs with respect to dynamic content. First, it is less stable; one thread might corrupt co-existing app's memory-spaces. Secondly, designs that require MT are not easily segmentable. Apache 1.3 makes little difference whether the dynamic-app is on the same machine or on independent machines. IIS-modeled ASP servers are not directly translatable to multi-machined applications (without significant clustering support). Similarly Java servlets does not [natively] provide for much inter-process communication, except when mapping sessions to workers.
The point here is that even with MT, multi-processing solutions are still sometimes necessary (e.g. using serialized access to a common database is necessary for basic communications, thereby avoiding many of the advantages of MT). To further the point, Apache 2.0 prefers a mixed-mode, where there are several independent processes which can optionally run n-threads each. This gives you the best of both worlds; services that can take advantage of threading (like static paging) can, while the benifits of the age-old IPC-based single-threading persist. This also allows legacy apps like mod_perl to work (in ST mode).
A basic turing machine is simple. Care to say any kind words about it? e.g. there's more to the equation when deciding who's "best" for a task.
I agree with you, but with reservation; you can write bad code in any language. But more relevantly, you _can_ choose a coding style which is readible in perl assuming that the reader actually KNOWS perl.. This is the biggest falicy about perl. Most people that berate it don't even know regular expressions (or sh / awk). Once you know them, you understand WHY the syntax is the way it is, and understand its benifits. After using it long enough, most of it is intuitive. I regularly read through CPAN code and always understand everything EXCEPT the algorithms. (which are sometimes obtusely done). I have the exact same problems with Java, though often it's more difficult unless you have the java-doc window open with valid documentation. Inlined hash-based parameters blow the doors off positional parameters in terms of readibility. Sadly, Java provides no such capability; applying hashes actually draws out the code such that it's even more difficult to understand.
Similarly Java is so verbose, that the syntax often gets in the way of understanding. Part of TMTOWTDI is that you write the code in terms of significance:
die "something went wrong" if complex-bad-condition;
Is more intuitive than:
if (complex-condition) throw bizzar-sounding-exception;
While at the same time the Java-style syntax is still an option.
Further, whenever I've had to write parsers, the intent of the VERY LONG code is anything but obviously; to say nothing of the debugging.. A simple regular expression (which is only recently standardized in java.. And oh, by the way, they used perl5.004's syntax) takes less than a line and is completely intuitive once you trace it out. The point is not to bash Java, but to praise the foresight of perl, awk, etc. for their designing languages that very nicely solve problems. Java started with your basic premise (the elegance and predictability of lisp / minimalized base operations), but found that this was not useful in the real world. They had to incrementally evolve, to find their real equilibrium (demonstrating that they missed their initial target). Now they're at v2.0 and have several "bolt-ons" which limit the elegance.. C# basically looked at Java and said, ok, we'll do java freshly (avoiding compatibility issues). Perl is a frankenstein of a language, but not because it missed it's initial mark, but because the world evolved (from c-based procedural, to OO. From quick-and-dirty RAD to quick-and-efficient web-apps. From no-holds-bar speedy core to user-extensible cores). That perl has lasted this long brings to mind the x86 processor (which even today has no death in sight). perl6 is going to be a complete rewrite, and it'll be sad to see the last vestigates of that genome dissapear.
In short, Perl gives you the ability to write "understandbile" code, and peer-pressure / corporate mandate should be enough to enforce this. The only thing left is the enlightenment of the developers. Let the best tool win the contract for my job.
-Michael
-Michael
Not at all. More "You can build something safe on top of something fast, but you cannot build something fast on top of something safe." We're only talking about the foundations here; you can build what you like on top of them (if they're sufficiently flexible).
Again, not at all. However, it is prudent to wrap any non-trivial type in at least a typedef (in C/C++ terms), for maintainability's sake. Using int or double everywhere is like writing code full of magic numbers.
There is nothing to say that you must use a custom type for these, rather than just an alias to a built-in one. However, the indirection provided by the alias typically costs one line of code, and in return increases readability and makes you future-proof. If your database code is written in terms of index values rather than ints, then if overflow is a danger, you can always turn index into a big number class transparently, or into an optimised class that uses int wherever possible but checks for overflow and switches if necessary, or whatever else you want to do.
This approach is far more flexible than forcing anti-overflow logic onto me whether I want it or not. I know better than the programming language what my requirements are and what kind of data I'm going to be processing; I don't want to be second-guessed, thank you.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
http://www.hpl.hp.com/personal/Hans_Boehm/gc/
rant
"You can build..."
So you are talking about roll your own. It is NOT EASY to write a high-performance multi-precision integer solution in C that smoothly integrates with fixed-precision integers and which you can use with the ease of a typedef. It needs to be built in the language from the start, not bolted on afterwards.
If you want true high-performance switching of integer sizes, you need to have the *machine code* tuned for the processor to make the common case fast, and the uncommon case still reasonably fast. You really can't do that in standard C, much less by including the overhead of C++ classes in a roll-your-own implementation. Much better if the person who wrote the compiler wrote it to emit the best code for these cases, then to have to persuade the compiler to change your C into the same code.
And in the case where you want to optimize away the overflow checks, the compiler is a lot more careful in the constraint analysis, and can check *every possibility* *every time*, not just when your gut tells you you should.
If you want to spend your hours acting like a Common Lisp compiler to get robust overflow protection, feel free. But in the 21st century, I'd rather a compiler do the work than have to do it myself.
Secondly, Perl OO is conforming with Perl's TIMTOWTDI (There Is More Than One Way To Do It) design goal. While native Perl OO is pretty casual in its encapsulation, if you want Bondage-And-Discipline OO, you can use one of Damian's Class::Classes, with Contract programming or Data hiding enforcement or ... there are at least 6 choices. At least one should have multiple inheritance grafted on, although I can't recommend actually using multiple inheritance of implementation (except maybe in CLOS); multiple inheritance of interface (like in Java or COM) seems safe enough.
Likewise, anything else Perl is missing can be added via other modules -- many of which probably already exist, but can be custom crafted on demand. This includes Operator Overloading, which can be added, for whatever cases are required, using Inline::Filter -- using the full power of Perl as a macro-language for Perl, to enhance the syntax as desired. Not for the faint of heart, but a good Perl consultant can whip it up for you.
GUI's -- Yes, it is true development of GUI's isn't built into Perl, unless you count the TCL modules as "built in". Ability to do GUIs does seem to run counter to portability (at compile time, whenever that is); this requirement may force your choice on Java. Perl has Gnome, TK/GTK, and Curses interfaces already. See CPAN
Thirdly, Perl6 will likely be mostly functional before .NET this summer, and _will_ be all things to all people, thanks to the modular bolt-on accessories. (Operator overloading will apparently be a part of the PARROT runtime for Perl 6, as well as in Perl6.)
Fourthly, Reality Context: Did The Boss specify that you had to be able to hire programmers in this language? Cheap or expensive? With lots of experience or not? Here or offshore? Eiffel's a great language, if you don't mind all your staff speaking French.
Regarding the evils of Lisp ... see the story of Yahoo!Stores Paul Graham: Beating the Averages or /. #1539239
for a real world $ucce$$ story with Lisp and why; amusingly, he turned up just last week /. #1917202.
-- Bill
"Your complaint that Ruby has no unicode support is particularly amusing since Ruby's core developer are Japanese.
Japanese programmers are not, by and large, required to make internationalized software. European and American programmers are.
"Not to provide unicode support was a simple design decision from people likely to be far more competent on multilingual matters than Python's core developers."
And this decision resulted in what replacement for Unicode? None! AFAIK, Ruby has no support for character sets outside of one popular in Japan and ASCII. That's really great if you are Chinese or Israeli.
"As for clear syntax - there are plenty of people despising Python for it's rigid indentation rules. Last but not least it is easier to write C-extensions in Ruby than in Python."
Really?
import PyInline.C, __main__
x = C.Builder(code="""
double my_add(double a, double b) {
return a + b;
}""",
targetmodule=__main__)
x.build()
print my_add(4.5, 5.5)
yup, perl's got everything. mod parent up for the excellent example!
To expand on a couple points, you can use glade for gtk, perl/tk for tk, Qt even. Of course the CGI stuff perl does for breakfast.
and operator overloading:
use overload '+' => sub{ $_[0] + $_[1] };
You can store reference counted objects in lists just fine. Or you can store non-reference counted objects. Or you can store garbage collected objects. Or you can store pointers. In fact, you can store just about anything besides objects with destructive copy semantics. All I'm saying is that the node structure of the list shouldn't be reference counted.
I'm interested in your comment that Lisp and C++ have different design goals. Common Lisp is designed to provide the programmer with a flexible, robust, object-oriented environment, suitable for large programming tasks. How does that differ from C++'s stated goals?
First, as stated, the goal is very general. It's all well to aim to provide the best of everything, but what design choices and trade-offs are involved ? Basically, the "goal" you've stated doesn't mean very much by itself.
Moreover, I don't believe that you're correct. Lisp AFAIK started out as a functional programming language, and Common Lisp added objects much later.
As for the design goals of C++, one of the major goals is compatibility with C. This was considered important for the language to be easily and widely adopted. A closely related goal is performance. Performance takes precedence over purity. Another goal is flexibility -- it is a multi-paradigm programming language, and has been from day one. This is in stark contrast with languages that claim to be pure object oriented.
Take a look at the Flyweight pattern in Design Patterns [amazon.com] book. Yep, a model of a word processor where every single character is represented by a very light-weight reusable object.
True, although that example uses the same object instances over and over. You ultimately only have 100 or so object types to represent different characters. I suppose that's what a Flyweight is (donno, have the book, never quite committed it to memory). Actually, the more I think about it, the more I think the approach is flawed. It might work for a small character set but what if you're using UCS codes like UTF-8? The only reason you would want to have an object to represent a character and not just use an integer would be if you wanted to actually control the rendering of glyphs as subviews of views. Even then it's probably not a good idea. Those examples are just examples.
The most powerful language is the one that can interface easily to another language, allowing you to "change horses midstream" if the first language doesn't do it all for you.
Put another way, the set of most powerful languages are those that can be used together. Anything with a binding for CORBA, COM, .NET CLR or anything similar will do the job.
sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
ADA is the best language there is. I regularly use JAVA and C++ and i know ADA beats the competition my miles.
Every new feature that you see in the modern languages today was in ADA years ago.
* better concurreny (protected types)
* better realtime systems( tasks)
* better exception handling(fail-safe systems)
* is a strongly typed language.
* better interrupt handling
* very early on introduced the philosophy of reusable code.
* had intefaces when java was still in its infancy
.....
and is used in: financial services, avionics, aeronautics, air traffic control, telecommunications, medical devices, power plants, railroads, astrophysics, satellites, and defense, to name a few.
If you are going to develop a realtime system forget about everything else... use ADA.
my two cents
Voltaire: God is dead.
God: Voltaire is dead!
Right. But I write applications today, not "someday." Someday, when things are 100x faster, Swing's speed indeed won't be an issue. For me, today, it is, and affects my choice of language.
-me
Love many, trust a few, do harm to none.
I can't understand parts of your post because it obviously isn't formatted properly. However...
Not at all. C is a low-level language, and forcing the use of such high-level logic would be inappropriate there. On many systems, your arguments about performance are way off-base, and you would cripple it if you imposed such a requirement. You personally may write mainstream applications for Wintel or whatever, but many who program in C don't, and your reasoning does not hold for those people.
C++ is a higher level language than C, but your argument is still broken, since it would violate the "zero overhead principle". If you think having an overflow-checked integer type in the C++ standard library would be useful (and you make a reasonable case for it in this thread) then you can suggest it to the standards committee as a possible inclusion in the next version of C++. They know the library is currently missing several key features that weren't ready in time for the first C++ standard (regular expressions, UI, proper file system support, fixed-point arithmetic, etc) and they're open to suggestions for enhancements in the next version.
So let me get this straight. You used unsigned char as a loop counter, and now you're annoyed that it's messed up? Sorry, I have no sympathy. char types are not suitable loop counters. You should be using int or some custom type, unless you have a very good reason for doing otherwise (which you clearly didn't).
If you started forcing char types to do automatic overflow checking, you'd break text handling (particularly strings), which is what they're actually for. Don't blame the language for your own inappropriate use of its features (and ignoring the warning that would have been generated by every single C or C++ compiler I know when you made this error).
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
...until you wrote:
That statement is so completely off-base that I'm afraid you don't really know what you're talking about. You can use C++ templates to write type-safe containers and algorithms, but they're also useful for many other idioms (traits, metaprogramming...). Java interfaces aren't even close to providing equivalent functionality.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
jaoswald understands. :-)
In a GC system, the concept of ownership (from a memory releasing perspective) doesn't exist; everything is effectively owned by the GC. Most of what's being said here then immediately becomes a non-argument.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
I'm not talking about C, I'm talking about C++. And in C++, it's pretty straightforward to do what you describe. And it shouldn't be built-in to the language, because it doesn't need to be. Providing the optional facility via the standard library is a much better option for several reasons (notably ease of implementation, forward- and backward-compatibility and keeping to the zero overhead principle).
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Every hammer and every nail are made up of atoms. So why not just put the atoms in place a more delicate way. I suppose we'd need colliders to break iron atoms off existing nails (one at a time of course). Maybe we could get the guys over at IBM to let us use their scanning-tunneling electron microscope so we can see exactly where we're placing the atoms. I suppose that after about 5 years of work, we could not only drive a whole nail, but also have it bonded quite nicely to the materials being assembled.
Pfft. No. The hammer is an abstraction of the solution. The nail is the abstraction of the problem. We create these abstractions because it's easier to work with larger elements than all the atoms in a system. We *could* code everything in assembly, but why would we do that? We could NOT code everything in Pure Lisp, for example. That's a programming language. Can is solve every problem? Absolutely not. Maybe with some hacking...
What it comes down to, using the wrong tool for the wrong job may still result in a solution. BUT, it will almost always take longer. If I want to add two numbers, I should probably not think about multiplying the two and then dividing by another number such that it produces the result of the addition.
Why bother.
He claimed that Common Lisp specifically (and not Lisp in general) was to provide an OO environment. From the history in the Hyperspec, object-oriented ideas in general were find their way into the Lisp world by the late 70s. While (as far as I can tell; I wasn't really old enough to be around the community at the time) the 1984 definition of Common Lisp didn't include CLOS, clearly people were thinking about it and the problems that had to be solved in getting an object system that would be as compatible as possible with the variety of object systems that had cropped up. (A little more information about this period can be found in Keene's book on CLOS, or in AMOP.) CLOS was officially adopted into Common Lisp in 1988 and appears in the second edition of Steele. It has always been part of the ANSI standard. Since the latter is what people mean when they casually say "Common Lisp" nowadays, I think it's fair to say that having OO facilities was a part of the goal of Common Lisp.
Also, in the history from the Hyperspec we find the following:
So at very least we have to conclude that by 1986 that this was one of the design goals of Common Lisp
The overhead of C++ is still going to be substantial.
Hint: how do you plan on detecting overflow on integer operations? Most processors have flags that you can branch on, but C and C++ don't offer language-level access to that functionality. The results of integer overflow are purposely left *undefined.* As in, no standard way to detect it. Every C implementation I've seen defines it as "silently truncate result and continue," with no way to detect it in the language.
Either you have to include assembly code in your C implementation (there goes portability), or you have to put a lot of tests in your common case to determine when the overflow is going to happen. That's a lot less efficient.
That's why this stuff belongs in the base language--they can do the processor dependent stuff right the first time.
Others are perhaps more qualified to comment on the history, but they've probably moved onto more productive threads ;-)
Part of the purpose of Common Lisp was to define a *common* standard for Lisp programmers. The language had branched into a lot of different dialects, each with their own quirks. Some of this was just random evolution, some of it was alternative ideas being explored.
My understanding is that OO was one of the areas where alternative ideas were being explored. There were a large number of OO extensions to Lisp that had been developed (e.g. Flavors) by various groups, and there had to be a reasonably large amount of discussion to determine which approaches were really valuable enough to standardize. CLOS was determined to be powerful enough to accomodate any important feature of the other approaches, so it could be standardized on without crippling some set of programmers.
This is very different than the C++ standardization approach, where, as far as I can tell, only a few people work on new ideas, and test them out in whatever way they feel is appropriate, then it gets thrown to a committee. Common Lisp depended on there being *existing*, *widely used* implementations that behaved in the standard way, so that the quality of the solution was already widely acknowledged.
That means that there is a lot more to many Lisp implementations than the standard discusses (e.g. GUI, network, database support, etc.). The standardization process did *not* include GUI features, for instance, because there is far too much variability between platforms, and because no one model is clearly successful enough to be forced on everyone. However, almost all Common Lisp implementations include GUI support.
So what are you proposing? Do you want to mandate that every C compiler provide this option as standard, including those for embedded processors with 8K RAM, where it's just never going to be used? That's absurd. As you point out yourself, there is nothing to stop vendors of C or C++ compilers providing such extensions on their own systems, and several do.
And you didn't notice or ignored a warning to that effect, and you got what you deserved for doing so. You should have fixed the loop counter at that point; the compiler told you that you had a problem. Either that or you're using the only C compiler on the planet that doesn't warn on such a blatantly dangerous coding practice.
int overflow testing wouldn't have helped here.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
The problem on minority platforms isn't in the cost to the developer, it's in the effort required to stick such code in a C compiler, when it's never going to be used.
As noted previously, this would be a reasonable candidate for an addition to the next standard C++ library, which would indeed make it an always-available option for programmers. Perhaps you could hope over to comp.std.c++ and suggest it?
My apologies; it's actually Lint that's objecting in my VC++ setup, not the compiler itself. It's a bit sad that two of the most popular compilers around don't object to this, though; it's an obvious and easily tested-for problem, and many other compilers do pick it up.
It's switching to arbitrary position if you detect an overflow that breaks the text handling (noting that C strings are just char arrays, and all elements in an array must have the same size). I agree you could have just the overflow test without breaking this, but then you have to work out what you do if it goes wrong.
And yes, char is broken in C and C++ for historical reasons; so is the handling of boolean values and tests. The sad thing is that newer languages in the family often haven't learned from such mistakes...
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
You're totally ignoring the points that I've made, and arguing with the points that you think I should have made. Yes, both parties took money from Enron. Enron gave money to hundreds of individuals. That, in itself, is not a crime (though I wouldn't mind seeing campaign donations get a lot more regulation).
What should be a crime is removing federal oversight so that a company can get away with fraud. You've consistently failed to address this point. Likewise, knowing Enron's financial status and continuing to help them should be a crime. It remains to be seen whether Bush will be implicated here. Enron helped determine the actual people in Bush's cabinet, re: the link I posted earlier. They didn't have that kind of influence with Clinton. If they managed to get someone into Clinton's cabinet and I'm missing somthing, post the link and let me know.
The information regarding Bush and Clinton's diplomats was from NPR. I don't have time to post a bunch of links here regarding how lobbying info consistently winds up in Republican sponsored bills, since I'm at work. If you're interested in the facts, you're probably smart enough to research it yourself. If you're only interested in asserting that 'your side is right', nothing I say here will matter much anyway.
___
It's the end of my comment as I know it and I feel fine.
Some of your "requirements" aren't language requirements, or even IDE environments.
Some of them are OS requirements, and others could be ORB requirements.
So you've got bigger fish to fry.
--Blair
"Big, boss-sized lunkers from the look of 'em."
matrix_add(MatrixA, matrix_multiply(MatrixB, MatrixC));
what makes this any more complex? Its just as easy to implement (barring namespace issues) and your latter example is very misleading. You can't simply add the address of one matrix to another and get a bigger matrix.