Slashdot Mirror
Why We Need More Programming Languages
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.'"
Only language we ever needed was C. You putzes just aren't using it right.
/flamebait friday!
.
Obligatory XKCD. http://xkcd.com/927/
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.
Algol for Web, COBOL beans, Object Oriented PL/1 ...
A feeling of having made the same mistake before: Deja Foobar
Seriously, choices are always better. My tool (normal tools not software tools) contains two different types of hammers, two different wooden mallets, several different screwdrivers....... If you learn to use the right tool for the job, the different choices make since. If you are stuck on the mentality of "All I need is a bigger hammer" and "All I need is XXXX programming language" then you probably are not using the right tool for the job.
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.
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.
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).
Please do not read this sig. Thank you.
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
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.
Table-ized A.I.
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).
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.
Non impediti ratione cogitationus.
Easier != Better
Except when it does.
That's the case with women and emergency exits.
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.
There isn't a thing Emacs can't do, still there isn't a thing I can do with Emacs.
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.
sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
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
Got Code?
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.
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 day.
If you're curious, try GNAT, the GNU Ada Compiler, which happens to be part of GCC. The concurrency model ( something akin to message passing ) alone is worth taking a look, especially if you've been bitten by pthreads, semaphores, mutexes and shared memory.
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.
Why is Snark Required?