Why We Need More Programming Languages 421
snydeq writes "Fatal Exception's Neil McAllister writes in favor of new programming languages, given the difficulty of upgrading existing, popular languages. 'Whenever a new programming language is announced, a certain segment of the developer population always rolls its eyes and groans that we have quite enough to choose from already,' McAllister writes. 'But once a language reaches a certain tipping point of popularity, overhauling it to include support for new features, paradigms, and patterns is easier said than done.' PHP 6, Perl 6, Python 3, ECMAScript 4 — 'the lesson from all of these examples is clear: Programming languages move slowly, and the more popular a language is, the slower it moves. It is far, far easier to create a new language from whole cloth than it is to convince the existing user base of a popular language to accept radical changes.'"
Pffft. (Score:5, Funny)
Only language we ever needed was C. You putzes just aren't using it right.
/flamebait friday!
Re:Pffft. (Score:5, Funny)
I'll chime in with the correct answer. If we all programmed in Haskell or OCaml the world would be a better place. Lisp even.
But I won't go on with a full rant. Functional programming is silently winning the war.
Re: (Score:2, Interesting)
Re:Pffft. (Score:4, Funny)
Programming peaked with COBOL and has been in a downward spiral since.
Exactly! See http://developers.slashdot.org/story/11/12/09/1533252/java-apps-have-the-most-flaws-cobol-the-least [slashdot.org]
One of the problems with this business is the continuing preference for the "new and shiny" at the expense of proven quality. COBOL is -very good- at a significant class of problems, and there are a lot of geezers who are very good at it.
One of the problems with new languages is that everyone starts out stupid. Think about C. How much experience do you need, beyond an understanding of K&R syntax, to be an effective C programmer?
@begin(flamebait)
Frankly, I think the base topic here, the argument for new languages over improvements to existing languages, is to make everyone equally -incompetent-. Many studies show the "10x difference" between good programmers and bad programmers. Some (significant) part of that difference comes with expertise with tools including programming languages.
@end(flamebait)
p.s. if you recognize above as Scribe mark-up, good for you! Do you really think Microsoft Word is an improvement over Scribe?
Re:Pffft. (Score:4, Insightful)
If you read the story, you'll note that the COBOL programs in question have been around for three decades or so. Most programs which have been continuously used for 30 years tend to be pretty solid regardless of the language.
Re:Pffft. (Score:4, Insightful)
This is not exactly true. Many programs acquire bugs as they age. The original developers are gone, and the new maintainers less knowledgeable, less proficient and less enthusiastic.
Re:Pffft. (Score:4, Informative)
Joel disagrees, bug fixes tend to accmulate. Things you should never do [joelonsoftware.com]
The bugs happen when new features are added, same as with the original developers.
Re:Pffft. (Score:4, Insightful)
One of the problems with new languages is that everyone starts out stupid.
You clearly don't have a CS background, but rather are a programmer. If you understand the fundamentals you're not going to be "stupid" in any language. Programmers are simply trained to use one or more tools. I have a cousin, for example, who has a Master's degree in Music. Even with an instrument he's wholly unfamiliar with, like an obscure tribal instrument, he can generally figure it out and play it. That's the difference between him and some guy who taught himself to play guitar.
Re:Pffft. (Score:4, Insightful)
That's the difference between him and some guy who taught himself to play guitar.
That's the difference between him and some guy who doesn't know anything. His self-taught status is irrelevant as long as he learned the right things (information comes from somewhere, after all).
Re: (Score:3)
COBOL is very good at something any language is good at: that is, once its been used for a long-enough time in an environment with reasonably stable requirements, and the bugs in the code worked out, its very good at plugging away and doing the same thing reliably.
Since COB
Re:Pffft. (Score:5, Interesting)
There are a few problems with functional programming languages that have prevented their true adoption anywhere.
1. Limited paradigms - I always prefer languages that let me write my code the way I want, a la C++, than a language that requires a strict paradigm from academia like Lisp. If I want to use the inherent hardware property based side effects of certain code structures, let me. Programming languages =/= mothers.
2. Difficulty. 90% of programmers (not on the internet, in general) write code like Fortran when its 2010. The most popular languages now, C# and Java, are popular because they are extremely easy to understand, if not easy to get things done in. You dont need to know lambda calculus or templates or prototyping to understand 99% of C# / java code (yes, I know C# has all of those and java has 2/3 of those). The problem with functional languages is that they always use these paradigms.
3. Most functional languages except Ocaml are like Ruby and Python in that they have tremendous performance overhead. For a consumer application, that overhead usually doesnt impede adoption (its more like the software is poorly written than the applications environment is too inefficient). But when talking about server programming the costs of running something under Ruby vs C are astronomical, and the same problem arises with functional programming. It might not hurt the consumer that the Python implementation of their music player consuming 30% more clock cycles than the exact same program written in C, but it does cause huge scaling issues with popular resources like Twitter.
4. In extension of 3, functional programming is getting away from how the hardware actually works. It is good for a novice that doesnt want to get into the details of pointers and caching and disk IO, but professionals should enter the game knowing how the underlying system runs and that making tradeoffs for readability by someone who doesnt know the language anyway vs performance benefits falls to the wayside. Developer time is important, but when you factor in the massive overhead trying to get 20+ year professional developers in C to try to think functionally you are never justifying the upfront cost of using the languages.
I mean, I dont use them. Thats personal preference. I like the way C and OO work more than I like dynamic typing and having no data and all the other out of this world paradigms. I really hope that D can achieve what I hope it will evolve into, a language that is hopefully as easy to understand as Python without the boilerplate of Java but with the performance of C. Thats kind of where the end goal of programming languages needs to be.
Re:Pffft. (Score:4, Insightful)
Re:Pffft. (Score:4, Insightful)
Do you think OO programming is closer to how the hardware works?
Yes. In most languages, objects are implemented like C (or even assembly language) structures. The language just adds a hidden pointer parameter to the object's methods. Sometimes method calls are made through indirect pointers. All of this is perfectly compatible with the way real-world CPUs work, including their built-in hardware stacks.
Functional languages, OTOH, are big on closures and the like. These don't map onto hardware stacks, and there are huge numbers of elaborate hacks in functional language implementations to try to cram the high-level concepts onto the procedural machine without taking the massive performance hit of allocating every value on the heap.
Re: (Score:3)
Re: (Score:3, Interesting)
All of those things work at the tiny level of shuffling around a few dozen opcodes. Moreover, all of that stuff is *completely* hidden from the programmer, and by design it's almost impossible to distinguish the resulting behavior from a strictly serial stream of CPU instructions on one or more independent CPUs. Functional languages can not and do not take advantage of the changes, nor do they map any closer to them than procedural languages.
(Some argue that functional languages will magically run N times f
Re: (Score:3)
Wait a minute, your other post claimed that the paradigm didn't matter. Now you're claiming that some paradigms prohibit side-effects and thus compile cleaner to modern hardware. You may have a superior UID, but you need to work on your consistency.
You also need to consider that Fortran compilers have been around a very very long time. I don't know if you can find a Fortran IV compiler and a Fortran 2008 compiler that will compile to the same architecture (that age difference is a bit extreme) but I'm willi
Re: (Score:3)
4. In extension of 3, functional programming is getting away from how the hardware actually works. It is good for a novice that doesnt want to get into the details of pointers and caching and disk IO, but professionals should enter the game knowing how the underlying system runs and that making tradeoffs for readability by someone who doesnt know the language anyway vs performance benefits falls to the wayside.
There's a couple of problems with this. 1) In theory, high-level programming shouldn't factor the
Re: (Score:3)
I don't know where you got the 90% figure from. Nowhere, I suspect. The performance hit depends crucially on what you're doing. Most programs that you will write in your career are not CPU-bound.
You also have to weigh that against the fact that a program written in a higher-level language will often have subtly different behaviour. For example, the type system of a Haskell-like language may not let you avoid checking the error condition of some I/O operation where C would. So the C program might be faster t
Talk about missing the point. (Score:2)
Performance doesn't matter any more. Correctness and quick development does. FP provides that in abundance. (Of course, correctness is just another way to say "quick development" nowadays, but whatever...)
To adress some of your points:
1) Two words: undefined behavior. You'll find it around every corner in C or C++ (two very different languages, of course) -- this leads to unreasonably hard-to-find bugs. In C++ it's also extremely hard to avoid such behavior consistently -- compilers are happy exploit it for
Re:Talk about missing the point. (Score:5, Insightful)
Performance doesn't matter any more.
Of course it does. Every programming task has to care about performance. What's changed is that the most important type of "performance" is different for every task. Most of us aren't doing large-scale numeric simulations.
If you're programming desktop GUI applications, responsiveness is usually more important than throughput. If you're programming mobile devices, battery efficiency is more important than any other consideration.
I think it was P.J. Plauger who pointed out that if the program to process the monthly payroll takes three months to run, it's useless.
What I think you meant to say is that for most programs, whether or not they meet their performance criteria is not limited by CPU cycles. That's certainly true. Most programming tasks can afford to spend some cycles if in return for correctness, programmer productivity or ease of maintenance.
Re:Talk about missing the point. (Score:5, Insightful)
Performance doesn't matter any more. Correctness and quick development does. FP provides that in abundance. (Of course, correctness is just another way to say "quick development" nowadays, but whatever...)
Really, performance doesn't count, that must be nice. The two worlds that I have lived in (control systems and financial transaction processing) have performance as king because in both cases, meeting specific performance numbers means large explosions or large fines from networks. Those are naming just two areas, there are quite a few other areas, but I can only speak of the two stated above.
1) Two words: undefined behavior. You'll find it around every corner in C or C++ (two very different languages, of course) -- this leads to unreasonably hard-to-find bugs. In C++ it's also extremely hard to avoid such behavior consistently -- compilers are happy exploit it for optimizations, but somehow can't provide warnings for all cases where you are (unwittingly) relying on UB.
I have found that ~90% of the "undefined behavior" is caused by people not properly checking argument values. That is the nature of imperative languages, if you don't know or understand that, I question whether you should be writing code then, sorry.
2) Really? Haskell or Ocaml do not rely on any of those things you mentioned. Difficult? Perhaps, but see my point #1. Besides, who would you like making your software... someone who's just "learned java" or someone who knows what the fuck they're doing?
See the above point of my argument...and nice language.
3) So all FP languages which don't perform as well as C (or order-of-magnitude at least) don't perform as well as C. What an insight. Btw, Haskell is also within OoM of C. Also, see the top of this post
Sarcasm really doesn't help make your point here.
4) How hardware works is fucking irrelevant. If compiler for language X can optimize "fib N" to a constant expression it doesn't matter if your C compiler can generate code which executes a million iterations of a fib-computing loop per second. Certainly, we're not quite there yet, but in the C world there's no hope of doing this beyond *really* simple examples (aka not fib), but FP could conceivably get further. (TC is a barrier, but you can still do useful computation even without TC.
Actually, I have found that understanding just how hardware works makes finding solutions to problems a whole lot easier. Computers function in a particular manor, and I have found that they mirror life more closely than functional languages. Now granted, that is my perception, but the fact that functional languages are still used only in a few disciple sure enforced my opinion.
After rereading the parent comment, I think your perceived attitude of the author is way out of line. He stated his case clearly AND WITHOUT PROFANITY. I have been developing software for 17+ years, and after all that time, paradigms come and paradigms go, languages come and languages go just like management styles. What matters the most is the person at the keyboard designing and developing the solutions. I can't even count the number of languages that have come and gone through the years, but C and C++ have always been there. I have stopped fighting the fight of "..this language is better because..." and just learned to use both of those languages better. I produce products faster with far fewer defects so I am happy.
Guess at this point I just need to yell "GET OFF MY LAWN" to complete my old grumpy statements.
Re: (Score:3, Funny)
There isn't a thing Emacs can't do, still there isn't a thing I can do with Emacs.
Re: (Score:3)
Performance matters when so many apps clearly have paid zero attention to it. Students were trained "don't optimize prematurely" but they only remember "don't optimize", without even stopping to think if the rule of thumb is even valid. Word is damn slow. Excel is damn slow. Browsers are damn slow. Web sites that browsers go to are damn slow. Operating systems are damn slow.
Why is it that with these incredibly fast computers we have today that so many things feel like they run more sluggishly than the
Re: (Score:3)
There are a few problems with functional programming languages that have prevented their true adoption anywhere.
1. Limited paradigms - I always prefer languages that let me write my code the way I want, a la C++, than a language that requires a strict paradigm from academia like Lisp. If I want to use the inherent hardware property based side effects of certain code structures, let me. Programming languages =/= mothers.
Common Lisp (and Scheme, even more so, although the community is more oriented toward impure functional style) enforces no fixed paradigm. It can be used functionally (conses [lispworks.com] happen to be a pretty good data structure for functional algorithms), but is more often used in an object-oriented manner [dreamsongs.com]. It was even one of the first OO languages, and AFAIK the first to implement multiple dispatch [c2.com]. It even has a powerful imperative operators [cmu.edu].
Thanks to macros [gigamonkeys.com] and the metaobject [alu.org]
Re: (Score:3, Interesting)
As an hobbyist Haskeller, I tend to embrace the unofficial Haskell motto of "Avoid success at all costs!" Responding to your 4 points, though,
1. Limiting yourself to a functional paradigm has benefits. You can use equational reasoning about code, and the compiler can perform more vigorous optimizations. Plus, for those of us who program for fun, it's...well...fun!
2. In Haskell it seems there is always something more to learn. Feature or bug, you decide.
3. Lisp (+ descendants), Haskell, and OCaml have compil
Re: (Score:3)
There are a few problems with functional programming languages that have prevented their true adoption anywhere.
That's true (mostly; if you've bought a plane ticket in the last 5 years, there's a good chance that functional code priced your fare.)
1. Limited paradigms - I always prefer languages that let me write my code the way I want, a la C++, than a language that requires a strict paradigm from academia like Lisp. If I want to use the inherent hardware property based side effects of certain code structures, let me. Programming languages =/= mothers.
Are you from bizarro world? You can say a lot of bad things about Lisp, but "limited paradigms" is not one of them (unless you've got extremely specific criteria or don't like parenthesis.)
2. Difficulty. 90% of programmers ...
I'll give you that one, functional programming is hard to grok.
3. Most functional languages except Ocaml are like Ruby and Python in that they have tremendous performance overhead...
C's going to win on I/O and other low level stuff, but modern Lisp compilers can produce some pretty efficient code.
Re:Pffft. (Score:4, Interesting)
I'd argue that we need multiple computer languages and paradigms, but that we probably don't need as many as we have. I'm fluent in about 20 computer languages but that simply should not be necessary.
I'd be quite happy if the world reduced itself to Digital Mars' D, Occam-Pi, Erlang and Haskell. That would give us the necessary mix of procedural, functional and object-oriented languages to cover everything, and these languages are much better at developing correct software than many of the other languages out there. There are many languages which are "good" at something - Fortran is still the language of choice for mathematicians, Forth is brilliant for hardware control and C is good for developing fast general-purpose software - but these are problematic in that they make it very easy to write buggy, unreliable software.
If you want to narrow the range, then the languages chosen MUST be capable of producing code as powerful and fast as the "best of breed" without having the genetic defects which are the product of the inbreeding that have produced these languages. Haskell and OCaml are great at what they do, and compilers for them could certainly be improved upon to generate much better code, and could easily replace those languages which show definite deformities (Java, Visual Basic, C#, etc) but those alone won't replace the full range.
Occam-Pi and Erlang are more than capable of replacing C and Fortran for most purposes, including client/server and HPC, but aren't ideal for really low-level stuff and don't have the power of C++ to simplify horribly complex projects. D does, but you can't simply use D because there's a lot in Occam and Erlang for parallel programming that C-based languages just don't have. (Prior "debates"/wars on here over parallel programming and whether or not it's complicated ultimately boil down to the fact that most people insist on using languages that make it far harder than necessary to get results. Always, always, always use methodologies that are suitable for the problem-space rather than try to cram the problem-space to a specific methodology.)
Re: (Score:3, Interesting)
I had the pleasure of conducting an oral history with the late John Backus. He reported that functional programming was a failure for the general case, for it was easy to do hard things but hard to do easy things.
I don't know what war you think functional programming is winning, but it only shows up on the minor sideline of the wars i'm engaged in.
Re:Pffft. (Score:5, Insightful)
Pure FP is not winning, but elements of FP have sneaked into all major imperative languages of the day. C# has lambdas for 6 years now, VB for 3 years. C++ has just got them, and Java is getting them in the next release. All these also have (in case of Java, will have) their equivalents of map/filter/reduce.
Re: (Score:3)
How is map/filter/reduce functional programming?
They are higher-order functions. Heavy use of HOF is one of the hallmarks of functional programming.
If you wish to dispute that claim, can you give your definition of FP first? Because there isn't a definite one that is universally accepted, and the pedantic one like "whenever functions are first-class values" is so general that it is essentially useless.
Map, for instance, is just syntactic sugar around 'foreach' and a sequence generator.
Well, duh. Or, alternatively, foreach is just syntactic sugar for map. And, generally speaking, any functional program can be written as imperative one, an
Re: (Score:3, Funny)
You forgot the "++" after the "C".
That is an important distinction, since C++ is the perfect programming language for all tasks, always has, and always will be.
Re:Pffft. (Score:5, Insightful)
GP has got it right. Parent is demonstrably wrong.
For object oriented tasks, Java, C# or Smalltalk are better. For system-level native tasks, C is better.
C++ reminds me of the wretched alien-human hybrid that got the Flamethrower in the Alien movie.
Re: (Score:2)
GP has got it right. Parent is demonstrably wrong.
Parent was most likely trolling ("always has", for a language that started being developed in 1979 or so?), and you appear to have bitten the hook.
Re:Pffft. (Score:5, Insightful)
For system-level native tasks, C is better.
Just because you're using C++ doesn't mean you need to write some glorious object-oriented dynamically-dispatched exception-throwing operator-overloading dynamically-dispatching self-reflecting monstrosity. C++ provides several very fundamental features which make it hugely superior to C: inline functions, better const semantics, reference types, and templates. If you don't want to write enterprisey crap, don't. But don't chuck out the baby with the bath water.
Re:Pffft. (Score:4, Insightful)
For system-level native tasks, C is better.
As C is a subset of C++, it can't possibly be better. Every C program can be written in C++.
Yes it can (Score:3)
Re: (Score:2)
In the domain in which it's dominant, the only viable alternative (IMHO) is D and that hasn't achieved critical mass.
Re: (Score:3)
Same reason as perl: because people are vile, sick bastards.
Re: (Score:2)
So that's why
Another mystery solved.
Thank you, sir.
Re: (Score:3)
Only language we ever needed was assembly. You putzes just aren't using it right.
Re:Pffft. (Score:4, Funny)
Only language we ever needed was punchcards. You putzes just aren't using it right.
Re: (Score:3)
Only language we ever needed was vacuum tubes. You putzes just aren't using it right.
Re: (Score:2, Funny)
Since someone here called me so old and out of touch that I'm probably still programming an Analytical Engine...
The only language we ever needed was a gear cutting lathe. You putzes just aren't using it right.
Re: (Score:3)
I knap my flint analytical engine gears with a sabertooth fang, and only a putz would need anything more.
Re: (Score:3)
Re:Pffft. (Score:5, Insightful)
C is like Oil Paints. Python is like water-soluble markers.
You can make artwork with both. you can also make a complete mess with both. This argument is silly.
Re:Pffft. (Score:5, Interesting)
no, but really, C is a good, but old language.
Cobol's even older. And Fortran's long been known to perform math calculations better than most other languages (though that may not still be true). Yada yada.
What I wonder about is, whatever happened to Black Box programming? Why do we need to care what language is used, as long as we understand its interface? Systems programming in C regularly calls assembly for the grottier hardware specific bits. Pretty much any modern language can call a function's object code written in another language.
Yeah, let's just keep on reinventing wheels. That's always worked so far.
No, we don't (Score:5, Funny)
Obligatory XKCD. http://xkcd.com/927/
Re: (Score:2)
Re: (Score:2)
McAllister doesn't argue for phasing out languages, and, IME, once you've learned a couple languages using a particular broad paradigm, its pretty easy to pick up other languages using a similar paradigm, and it improves your ability with programming even with the languages you learned earlier.
So I don'
Just Let the Dinosaurs Die (Score:2)
'But once a language reaches a certain tipping point of popularity, overhauling it to include support for new features, paradigms, and patterns is easier said than done.' PHP 6, Perl 6, Python 3, ECMAScript 4 — 'the lesson from all of these examples is clear: Programming languages move slowly, and the more popular a language is, the slower it moves.
What's wrong, Slashdot? Where's the editorializing [slashdot.org]?
It's interesting that Google took part in abandoning ECMAScript 4, which would have been almost fully backward compatible with current implementations while solving most of the "fundamental problems" Google claims require a brand new language to fix.
Seriously I'm sick and tired of defending new languages like Clojure, Go, Dart, Ruby, etc. I'm just going to shut up and let the dinosaurs stagnate and get stuck maintaining all the old code for the rest of their unenjoyable never changing ruts.
Re:Just Let the Dinosaurs Die (Score:5, Interesting)
Your criticisms seems to be based solely on whether or not code is old. If the code works, why is that even a consideration for you? Does it have to be new code to be any good? I hope you're aware of how silly that sounds.
As for languages like Clojure, Go, Dart, and Ruby, those languages have deficiencies that warrant legitimate criticism. If you're sick and tired of defending them, don't read anything on the internet, because you'll never completely avoid criticism of things you like.
New wheels, new wheels! (Score:2)
Get your newfangled wheels here! This time it's in BLUE!
To be honest I find Python the scariest language. I write some pseudo code and it runs. Worse, it usually runs first time.
Runs anywhere (Score:2)
Easier != Better
Re:Runs anywhere (Score:4, Funny)
Easier != Better
Except when it does.
That's the case with women and emergency exits.
The reason (Score:5, Interesting)
The reason popular languages move more slowly is because established codebases use them. Backwards compatibility is a good thing. If C++ was radically changing all the time, code that compiled a year ago wouldn't run anymore. Stability and predictability are just as important, if not more so, than radical change when it comes to real-world development.
Re: (Score:2)
I don't think anyone is arguing against that. I think the point McAllister is making is that without new languages, progress would stall. I don't think McAllister is saying that the conservatism of well-established languages is a bad thing in and of itself, just that it means that progress requires new languages. McAllister explains that this is because newer languages are freer t
Re: (Score:2, Insightful)
I have to respectfully disagree that progress would stall if there weren't new languages all the time. One can't help but wonder what progress would be made if the effort spent in trendy languages was invested in established languages. If a concept is good, it will appear in whatever the languages the industry is actually using, regardless of whether or not a trendy new language implemented it first. That said, testbeds are certainly a good thing to have.
Re: (Score:2)
No, it won't. Because if it hasn't been proven good someplace that has the freedom to implement new things without the legacy concerns that -- for very good reasons -- established languages carry, maintainers of established languages won't take the risk associated with implementing it.
While algorithms -- which can be analytically and quantitat
Re: (Score:3)
But choice is GOOD! The more choice the better! Look at the reason linux was able to step in the gap when Microsoft introduced Vista, going on to win the desktop wars! Linux won because of all the effort that was expended into making 619 different linux distros with 487 different desktops - there's GOT to be one for every type of user. Can't you see its the same with programming languages?
Can you imaging what would have happened if all that effort had been concentrated in just one or two distros, and
Re:The reason (Score:4, Interesting)
You really have me there. I can't figure out if you are poking fun at c++'s inability to keep "hello, world" compatible between versions, or really think that c++ has some sort of track record in consistency.
C++ is abhorrant; its author should have shot it long ago.
Re: (Score:2)
The cost of development mostly depends on quality expected. "Easier" languages merely enable incompetent people to write software, so worse software can be developed with them, and incompetent people usually work for peanuts.
Just recycle the old ones .. (Score:5, Funny)
Algol for Web, COBOL beans, Object Oriented PL/1 ...
Re: (Score:3)
I like my aspect oriented punch cards.
lets reconstitute the ADA committee (Score:2)
Re:lets reconstitute the ADA committee (Score:5, Insightful)
The Saturn V was designed by many committees.
And for the time Ada is not a bad language at all, especially if you're mature enough to know that the quality of the result is more important than you.
Re: (Score:2, Interesting)
We're about to let out an RFP and SOW for about 3-4 million lines of code in ADA. Not huge, but completely auditable to our certification standards. It might come back in some other language, but we're not interested in paying the added cost of auditing whatever language the winner picks. Yes, aerospace, safety of life critical failure sort of stuff. I'm not interested in the efficiencies of out of order execution or dereferencing; I want completely deterministic results.
Re: (Score:3, Interesting)
I fully agree. While ADA is a joke for many people, I happen to know ADA quite well since I use it every day for my job in a Big Company. I know quite a few other languages ( from assembly to C++/C#, python and a few functional languages ), and no other language I've used can let me produce such stable & robust software.
It manages to be easy to read, high-level while close to the metal when you need it to, has concurrency built-in and prevents you from shooting yourself in the head at least twice a da
Use the right tool for the job (Score:3, Insightful)
Re: (Score:2)
Re: (Score:2)
There is a balance though. If I had something that required repeated insertion and extraction of fasteners, I'd go with a Torx bit because eventually Phillips screw heads will cam out, and if the next guy can't cough up that type of screwdriver, there is someone else out there who can/will. On the other hand, I'd be leery of using a XZN or a tri-wing screw head, even though they allow for far more torque without camming out.
Tiobe Index reflects conservatism (Score:3)
It's notable that the Tiobe Index has just one 21st century language among the top ten (C#, 2001). http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html [tiobe.com]
Re: (Score:2)
Shouldn't be a surprise, especially with the amount of hardware still running the world on 30-40 year old tech. As the saying goes: if it ain't broke, don't fix it.
Re: (Score:2)
First appearance of objective-c: 1983. [wikipedia.org]
First appearance of c#: 2001. [wikipedia.org]
I would have to say that the GP is correct.
More is not better (or worse) than less, ... (Score:2)
... , just different.
– The paradigm paradox.
from www.info.ucl.ac.be/~pvr/VanRoyChapter.pdf (Programming Paradigms for Dummies: What Every Programmer Should Know)
Probably worth considering before starting to discuss the issue. The conclusion then could be that a more general paradigm shift is needed.
CC.
C++0x is proof of this (Score:2)
With C++0x we have the mutually exclusive aims of nice syntax and new features. The comes a point where maintaining legacy support impinges on the cleanliness of the language to such an extent that it becomes counter-productive. The whole point of a programming language is to express problems in a legible way. The new "enum class" syntax is a good example of how things can go wrong.
It's not C++ itself I have a problem with; it's that improvements to the language are made without breaking legacy support -- n
Re: (Score:2)
Just for that (Score:2)
I'll be programming the navigation system on your space shuttle using VB6. Have a nice trip! :)
No, we need one *better* language, not "more" (Score:5, Insightful)
No language is perfect. The idiocy of language designs stem from the fact that few, if any programming languages were designed by anyone who had ever read a book on psychology, ergonomics or human factors.
There's a saying floating around the internet that "Languages should be easy to read and understand and incidentally be compilable by computers." That about sums it up.
THE COMPUTER DOES NOT MATTER. It is a means to an end. It's only purpose is to serve humans. The languages designed to provide a system level interface to that machine need to be designed around what a human understands, the way a human understands it. Slavish devotion to a hardware design, or even an object model is plain stupid if it makes your product nearly unusable (e.g. the WPF datagrid).
Re:No, we need one *better* language, not "more" (Score:5, Informative)
It's all well and good to say "make it understand English", but there are two primary problems with this. First, natural language programming is hard. Really hard. Just getting a computer to understand English with any reasonable reliability is pretty far in the future, and we can't wait for that. Second, we as humans don't really have much success expressing exactly what we want. It's why the most insidious bugs are not in code, but in specification. We so often don't know quite what we want that restrictive languages are actually beneficial, in that they force us to reason consistently.
And it's not some "saying floating around the internet", it's a very famous quote from Structure and Interpretation of Computer Programs, a seminal text in basic programming language theory and compiler/interpreter design. Most importantly, it's probably the first book you should read if you want to intelligently discuss this topic.
Another quote you might find interesting:
When someone says "I want a programming language in which I need only say what I wish done," give him a lollipop.
- Alan Perlis
In short, from someone who likes to design programming languages - stop assuming that just because the problem is easy to understand that it is easy to solve. We're not all basement-dwelling geeks who think UNIX is the pinnacle of end-user usability and newbs should just get over it. We aren't pretending that there is no problem, and we're not refusing to educate ourselves on how to solve it.
Re: (Score:3)
Oh, god, yes.
One of the more important development skills to have is to be able to extract consistent requirements from stakeholders, and then to be able to write them down in such a way that the requirements will be
Slash-CAllister (Score:5, Funny)
Is it just me, or has almost every article by Neil McAllister made it to the Slashdot front page?
I propose
1) a "slashcallister" because it rolls off the tongue, and can be used to tag these articles (as part of the greater "slashonomy"), so that
2) McAllister's articles be picked up by Slashdot's server-side RSS reader and auto-posted & auto-tagged, thus creating the Official Slashdot Neil McAllister Channel
Query Languages (Score:5, Interesting)
We have only ONE relational query language in common use: SQL. We need more options. SQL is hard to extend by DBA's, emphasizes nesting over named-references, has a messy COBOL-like syntax structure, and other annoyances.
We have bajillion app languages, but very few query language choices. There is the Tutorial-D language family which spawned REL, but it's more of a tight-typing/compiled style.
We also need something more dynamic. I've proposed a draft query language called "Smeql" (Structured Meta-Enabled Query Language, pronounced "smeegol") for such. You can "calculate" column lists using dynamic queries, for example.
It's a far far needier field than app languages.
Re: (Score:3, Interesting)
Re:Query Languages (Score:4, Insightful)
Only in fantasy-land has SQL implemented "write once, run anywhere". You hint at this problem yourself where you say "with a few mods, it works on nearly any relational database".
Whilst there is an SQL standard, implementations of SQL vary massively. Professionally I've used SQL-Server, Oracle, MySQL, PostgreSQL and SQLite - all have profound differences, and moving anything beyond absolutely trivial SQL code from one to another requires rewriting the query. We're talking about a language here where major implementations don't even agree on string concatenation syntax...
Every SQL implementation has it's customisations and variations from the standard. It's almost impossible to write any kind of decent SQL code without making use of these custom variations, and thus ruining the portability of the SQL code.
Python is a bad example (Score:5, Interesting)
Python is actually an example of how can a language continue to develop even after becoming popular. In a brave move, they didn't let backwards compatibility tie them down. By breaking compatibility, the language could continue to evolve: there are many new features in Python3. For this to work without breaking existing stuff, the __future__ module was invented, which allows creating 'forward compatible' code.
I think we don't necessarily need to constantly switch languages to evolve, getting rid of backwards compatibility is another way to go (or make the language very general like LISP).
There's only one real problem. (Score:2)
Names!
As long as the binary format's correct and/or you're not filling /usr/bin or /usr/sbin, or wherever your OS stores binaries with interpreters... What's the problem? I mean, there's the problem of understanding the intricacies of a given language, but...
The real problem is that when all the clever names are taken.
Only if it brings in something 'new' (Score:3)
Is there a need for new programming languages? Perhaps. But I don't think this is eternal. Programming is just the ability to express algorithms and logic. It's not an infinite space.
I think people moan about new languages when they don't appear to bring anything really new.
Broadly speaking... following one train of evolution.
assembler - abstract out op codes
C/C++ - direct hardware access... provides human word abstraction for programming (for loop, switch, variables, classes...)
java/c# - virtual machine based, easy library integration (just include the lib)
Those are big significant changes. It is preferable to add new things in these languages via frameworks, new libraries, code generators... for example QT is a huge framework and code generator, but at its core is still C++. You can easily link in any old c/c++ library or source code.
Creating a new language for syntax changes or anything is where I think people begin to moan.
radical change (Score:2)
"far easier to create a new language from whole cloth than it is to convince the existing user base of a popular language to accept radical changes."
I think we should apply that concept to human languages.
And if you dont agree with me then, sof ertes fidods as'd fguw !
It's Not The Programming Language, Stupid (Score:2)
Just be clear, I'm not calling anyone stupid (remember what Clinton said? no no no, not "I did not have sexual relations with that woman." the other thing he said. about the economy.)
Two thoughts:
First, in a way, this is a silly discussion. Of course we need new languages. All interesting software-intensive systems are full of little languages (we just write them ourselves in other standard languages).
Second, it really isn't about the programming language. Yes, different languages make you think/act/work/ab
keep building them I will keep using them (Score:4, Funny)
Keep building new languages, I will surely find a way to bill hours for it.
Java - billable hours and ass loads of hardware .NET - perfect for lock in and selling licenses, rewrite in java once it is determined that hey we need to support other platforms.
PHP - quick and dirty web development cleanup billable hours
Python - one off get it done quick billable hours
Perl - systems stuff they will have to call me back in to maintain
Java Script - client hack more billable hours
C - debugging more billable hours
Ruby - billable hours for rewrite to address performance issues including a ass load of hardware
Don't think languages, think paradigms (Score:4, Insightful)
Having said that, the best way to learn different paradigms is to use languages that are different from each other. Learning only languages that share paradigms will not stretch your abilities that much. For example, in the big picture, C++ and Java are not that far apart.
My personal experience is that Lisp/Scheme is different enough from any of the C derived languages that it forces you to learn to think a new way. Learning Scheme will make you a better C++ coder. I still haven't spent the time to learn Haskell, but I plan to do so. I think it will improve my abilities no matter what I am working on. Lazy, strict functional programming is far enough removed from what I normally do that I expect to learn a lot of new ways to think about coding.
I Miss Turbo Pascal (Score:3)
Now there was a language!
Turbo Pascal 4.0 was the best. Not because of efficiency, or programming paradigm, or any of that.
It had an integrated development environment that was a dream to use. The online documentation was helpful. The manual was a masterpiece. It was easy to begin with not very much and to be producing fairly complex results in not much time.
I am not a programmer by trade. Studied it in school, way back in the 20th century. Since then, every now and then I've done some programming for my own utility or for work projects in all sorts of languages, including programming, macro, and scripting languages.
Perl 5.2 was the closest I've come to a language I really like since Turbo Pascal. Yeah, the initial syntax learning curve was ferocious, but in the end it wasn't that steep. Sure, no integrated development environment, but a decent text editor was almost as good. The Perl manual pages were masterful. Again, easy to begin with not very much and produce useful results in not much time.
I'd really like to find my own personal 21st century Turbo Pascal. I don't care about the syntax, although I actually sort of liked the Pascal syntax. I want a tool that is easy to install, that includes a reasonable IDE with conveniences like syntax highlighting and code-completion, useful documentation, and a fairly rapid path from the start line to something useful. I'm willing to give up the IDE if I can get consise and precise syntax documentation and error messages.
I took a look at Perl 6. I haven't given up on it yet, but it doesn't seem cooked yet. And the documentation left me swimming in a sea of information that never seemed relevant to what i was trying to do.
I took a look at Clojure. I had a lot of hope for it. I ended up lost in a sea of irrelevancy trying to figure out how to do very basic things.
Ruby. Couldn't download it. Don't know why. Some website error over a couple of days. Fail. Maybe I'll try again some time.
Python. There is something that just seems wrong to me about indenting being syntactically significant. But what the heck, I'm willing to set that aside. The documentation isn't bad. My biggest issue with Python is "SyntaxError: bad syntax". That's it? Nearly a hundred years of computer science and the most the computer can tell me about my mistake is "SyntaxError: bad syntax"? I can't even get a "operator expected" message? Okay, so occasionally some sort of indentation error, but mostly just "bad syntax". I haven't completely given up on it, but I got tired of fighting that error message.
Actually, C# is the best I've found so far. I am really hoping for something better. But I've been able to start from not much and produce small but useful (console) programs in not much time at all. The combination of command-line compiler and my own text editor was enough to get me going. Basic language documentation is woefully deficient, but somehow that wasn't much of a problem. I've developed a love-hate relationship with Visual Studio, though. Can't seem to make it edit just one file, with full syntax and code-completion. It wants "projects" and "solutions". Screw that. I understand the usefulness of that, but if I'm writing a 30 line script that does something useful to some text data, I don't want to go through all the overhead of "projects" and "solutions", I want to create a file, edit, compile, and done. And the on-line help in VS is . . . stupid.
So, go ahead and jump on me. If any of these are your pet language, and I'm just not getting it, please enlighten me. If you have a different pet language, and I'm just not getting it, please enlighten me.
But whatever it is it needs to be pretty simple to install the basic environment. Basic documentation needs to be pretty useful. An IDE with syntax-highlighting and code-completion is a big bonus, but I can live without it if there's decent error messages and documentation. And it needs to be useful pretty
Incomplete subject line (Score:3)
Somebody truncated the "like we need holes in our heads" part.
Re: (Score:3)
and C#
And something client side. Something better than Javascript.
Re:The idea of "Language 2.0" is evil (Score:4, Insightful)
The only language where this is a real problem is javascript.
For web server side scripting, you can replace say. PHP with Python or Ruby with relatively little pain. Sure, you're rewriting all of your logic, but, in the end, moving languages is only as massive as the size of your projects.
For stuff that's more bare metal, replacing anything with anything else this is true too; assuming the linker gives you a binary in the required binary format. Not a big deal right?
The problem with Javascript is that it's the only language we have for web frontend development, and it's horrible too. It's deceptive. It looks simple, but making dynamic changes to HTML entities requires having some idea how classes work so you can do operations on the DOM. Sure, there are frameworks that might simplify this stuff, but, for artistic and creative people(read: largely bad at math), this is problematic. It's very CS202 and having to think rather linearly.
Re: (Score:2)
That's pretty true of programming generally, not JavaScript or DOM manipulation particularly. That's why you have designers do design, content people develop content, and programmers doing programming.
Re: (Score:3)
For stuff that's more bare metal, replacing anything with anything else this is true too; assuming the linker gives you a binary in the required binary format. Not a big deal right?
This is a joke right? You think writing tooling for a build process onto the metal is no big deal? Besides a good compiler and linker, you need build tools, debuggers, simulators. Oh, and you'll need to port all your external interfaces and drivers to the new language (or write a shim layer in the old language). While you are do
Shouldn't that be in RPN (Score:2)
Forth more we need NOT less we need just one
Re: (Score:3)
Compiler architecture should be piped, with optimization as the absolute final stage. Compilers really aren't that modular, as demonstrated by the fragility of the API linking the frontend to the backend of GCC. Frontends have to be modified frequently to work with GCC, which would obviously not be the case if they were loosely coupled. This "steady refinement" (the word you want is "reification") is a bloody stupid description and if you don't understand the problem with early optimization you should go ba