Beta

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Why We Need More Programming Languages

Soulskill posted more than 2 years ago | from the use-once-then-discard dept.

Programming 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.'"

cancel ×

421 comments

Sorry! There are no comments related to the filter you selected.

Pffft. (5, Funny)

epiphani (254981) | more than 2 years ago | (#38318954)

Only language we ever needed was C. You putzes just aren't using it right.
 
/flamebait friday!

Re:Pffft. (4, Funny)

2.7182 (819680) | more than 2 years ago | (#38318990)

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:Pffft. (3, Interesting)

phil_aychio (2438214) | more than 2 years ago | (#38319044)

Programming peaked with COBOL and has been in a downward spiral since. (obligatory "hey you kids get off my lawn" geezer-speak) Hey you kids get off my lawn!

Re:Pffft. (3, Funny)

david.emery (127135) | more than 2 years ago | (#38319284)

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. (5, Interesting)

Xanny (2500844) | more than 2 years ago | (#38319132)

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. (1)

Anonymous Coward | more than 2 years ago | (#38319230)

Common Lisp is not functional, Scheme is. Common Lisp supports mainly metaprogramming, imperative and OO programming(you could use functional but you'd be restricting what you can do).

Re:Pffft. (3, Insightful)

2.7182 (819680) | more than 2 years ago | (#38319326)

Do you think OO programming is closer to how the hardware works?

Re:Pffft. (0)

Anonymous Coward | more than 2 years ago | (#38319396)

Do you think OO has anything do with with anything other than saving developer time? Do you really think functional programming is relevant to transistor networks?

Clue: compilers are there to do the work of converting code into machine instructions, regardless of the underlying architecture.

Re:Pffft. (0)

Anonymous Coward | more than 2 years ago | (#38319434)

My computer has objects (registers) and you do stuff with them.

Re:Pffft. (0)

Anonymous Coward | more than 2 years ago | (#38319342)

I can't agree more!

Re:Pffft. (2)

Grishnakh (216268) | more than 2 years ago | (#38319482)

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 hardware into things at all. That's fine if you're writing OS device drivers or whatever, but for a high-level user application you really shouldn't be worrying about how the hardware works internally. The programming language is supposed to be a way of telling the computer in a completely logical way, that can't be misinterpreted (like natural languages), exactly what you want it to do, to get certain output out of it. How to translate that into commands the hardware understands is supposed to be the job of the compiler, and the people that write the compiler. Instead of expecting every high-level programmer to understand various details about the hardware, let the compiler people be the experts in that domain, and translate the desires of the app developer into the most efficient machine commands. Furthermore, with modern hardware as fast as it is, a 5% improvement in performance shouldn't be something you sacrifice easy code-ability and easy maintainability for.

2) Hardware changes, and software is run on different hardware all the time. Writing something to run well on one kind of hardware or system may not work so well on another kind of system. Just look at what happened with the multi-core mini-revolution. All these applications written for single-core processors didn't run any better than on older systems because they weren't written for that hardware, and only ran on a single core. If they were written in a language that fully isolated the programmer from the details of the hardware, then a simple recompile should allow them to take advantage of multiple processing cores, as the compiler would handle those details by creating separate threads for different parts of the program, rather than expecting the high-level programmer to do this himself.

Of course, this is all in theory. I haven't actually used any functional languages myself, so I can't really speak to how well real-world functional languages would fit the theory described above.

Re:Pffft. (3, Interesting)

jd (1658) | more than 2 years ago | (#38319296)

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:Pffft. (3, Interesting)

gbooch (323588) | more than 2 years ago | (#38319494)

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.

Oh, my! Hehe! (-1)

Anonymous Coward | more than 2 years ago | (#38318994)

To my surprise, I just expelled flatulence directly out of my own asshole. What a day! How was your day, fellow Slashdotters?

Re:Oh, my! Hehe! (0)

phil_aychio (2438214) | more than 2 years ago | (#38319090)

Mine is going better than yours...I expelled flatulence out of someone else's asshole, and then played the 'he who smelt it, dealt it' card.

Re:Oh, my! Hehe! (-1)

Anonymous Coward | more than 2 years ago | (#38319102)

You need tipi for your bunghole! - The Great Cornholio

Re:Oh, my! Hehe! (0)

Anonymous Coward | more than 2 years ago | (#38319142)

Jesus. One amusing comment followed up by your retarded reply which went out of fashion roughly two minutes before Beevis and Butthead was ever dumped on an unfortunate humanity, and "phil_aychio"'s reply, which if anything is even dumber.

Re:Oh, my! Hehe! (0)

phil_aychio (2438214) | more than 2 years ago | (#38319360)

you need to move out of your mom's basement and get laid. big time.

Re:Pffft. (3, Funny)

Anonymous Coward | more than 2 years ago | (#38319048)

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. (4, Insightful)

wed128 (722152) | more than 2 years ago | (#38319122)

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:Pffft. (1)

ericloewe (2129490) | more than 2 years ago | (#38319234)

If C++ is so bad, why is it so popular? Not trolling, by the way.

Re:Pffft. (0)

Anonymous Coward | more than 2 years ago | (#38319392)

Object-oriented programming is popular, so languages that implement it are popular. If you prefer C, there's a good chance you don't like OO. I fall into that category somewhat. I think there's a small set of problems for which OO is the killer approach. In particular, anything that fits into a taxonomy is obviously a candidate for OO. The trouble is when people try to shoehorn everything into a class hierarchy.

OK, base class customer. Then you have customers from Iowa and New Hampshire. New class or member variable called state? You think you know the answer when you first code it, but you often don't. Re-factor. What really gets me though is when you want to sort a customer or transact with a customer. Then something that's not a customer comes along and it wants to sort or transact. You either have to MI, creating the bastard class from hell, or instantiate a customer just to get a sort or a transact. So then sooner or later OO is a mass of code where you have to send OldCustomerObject to Iowa, and he later gets recreated as NewCustomerFromIowa object but the only reason you instantiated him is so you could get access to the sort functionality for your PartnerFromOhio.

Re:Pffft. (1)

Timbo (75953) | more than 2 years ago | (#38319394)

In the domain in which it's dominant, the only viable alternative (IMHO) is D and that hasn't achieved critical mass.

Re:Pffft. (1)

Guy Harris (3803) | more than 2 years ago | (#38319290)

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. (5, Insightful)

pclminion (145572) | more than 2 years ago | (#38319430)

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. (0)

Anonymous Coward | more than 2 years ago | (#38319088)

python makes the same and is far simpler to show people to convert them to programming #hatersgonnahate
no, but really, C is a good, but old language. And if you consider PHP as a language ( which is what i do), then you need it at least for web usage. you'll tell me we could make downloadable executables, but, look, is anyone really gonna download a whole executable to post on a forum? Also, what about smartphones and tablets? Do you think programming could have been getting that mainstream with only the cluttered C to program in? I do not believe so.
Thanks for reading.

Re:Pffft. (5, Insightful)

wed128 (722152) | more than 2 years ago | (#38319146)

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. (4, Interesting)

tqk (413719) | more than 2 years ago | (#38319372)

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.

Re:Pffft. (0)

elrous0 (869638) | more than 2 years ago | (#38319178)

Programming, you're doing it all wrong!

Re:Pffft. (0)

Anonymous Coward | more than 2 years ago | (#38319190)

Only language we ever needed was C. You putzes just aren't using it right. /flamebait friday!

How would you fire all your skilled workers and hire unskilled workers in country X, if all your code is in C? That actually requires thinking!

Re:Pffft. (1)

NonUniqueNickname (1459477) | more than 2 years ago | (#38319220)

Ohhhhhh, flamebait Friday!
So that's why /. publishes Neil McAllister stories on Fridays.
Another mystery solved.
Thank you, sir.

Re:Pffft. (2)

Ukab the Great (87152) | more than 2 years ago | (#38319254)

Only language we ever needed was assembly. You putzes just aren't using it right.

Re:Pffft. (3, Funny)

Ukab the Great (87152) | more than 2 years ago | (#38319270)

Only language we ever needed was punchcards. You putzes just aren't using it right.

Re:Pffft. (2)

Ukab the Great (87152) | more than 2 years ago | (#38319280)

Only language we ever needed was vacuum tubes. You putzes just aren't using it right.

Re:Pffft. (2, Funny)

Anonymous Coward | more than 2 years ago | (#38319370)

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.

No, we don't (5, Funny)

Anonymous Coward | more than 2 years ago | (#38318962)

Obligatory XKCD. http://xkcd.com/927/

Re:No, we don't (0)

Anonymous Coward | more than 2 years ago | (#38318996)

...finally an XKDC link that kind of makes sense...

Re:No, we don't (1)

Neurotrace (2382180) | more than 2 years ago | (#38319084)

Exactly. Not to mention, if we just phase out these languages in place of new languages then what happens after you've learned your nth new language and now you have to maintain some code written in an "old" language?

Re:No, we don't (1)

the linux geek (799780) | more than 2 years ago | (#38319202)

Then you display adaptability. I know that's difficult for some people.

Re:No, we don't (1)

DragonWriter (970822) | more than 2 years ago | (#38319456)

Not to mention, if we just phase out these languages in place of new languages then what happens after you've learned your nth new language and now you have to maintain some code written in an "old" language?

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't think this is really a problem.

Re:No, we don't (0, Flamebait)

the linux geek (799780) | more than 2 years ago | (#38319218)

Fuck xkcd. That's stupid and totally irrelevant. Nobody is trying to make a "standard" programming language for all things and situations, and nobody has ever tried since Java and ALGOL 68.

Just Let the Dinosaurs Die (1)

eldavojohn (898314) | more than 2 years ago | (#38318966)

'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 (1)

Anonymous Coward | more than 2 years ago | (#38319014)

" 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."

Also known as "having a job".

Re:Just Let the Dinosaurs Die (0)

Anonymous Coward | more than 2 years ago | (#38319076)

I always enjoy watching each language body and its users realize "oh... they had (thing which we thought was unnecessary) to solve this problem..."

Re:Just Let the Dinosaurs Die (4, Interesting)

bonch (38532) | more than 2 years ago | (#38319140)

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.

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! (1)

Colin Smith (2679) | more than 2 years ago | (#38319450)

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.

Re:New wheels, new wheels! (0)

Anonymous Coward | more than 2 years ago | (#38319474)

Get your newfangled wheels here! This time it's in BLUE!

So what language are you using on your DEC PDP-10?

Runs anywhere (1)

Allicorn (175921) | more than 2 years ago | (#38318972)

Easier != Better

Re:Runs anywhere (1)

seandhi (1949778) | more than 2 years ago | (#38319020)

Except when it does.

Re:Runs anywhere (3, Funny)

Chrisq (894406) | more than 2 years ago | (#38319436)

Easier != Better

Except when it does.

That's the case with women and emergency exits.

All you need is PERL (1)

cod3r_ (2031620) | more than 2 years ago | (#38318998)

and C#

Re:All you need is PERL (2)

ackthpt (218170) | more than 2 years ago | (#38319074)

and C#

And something client side. Something better than Javascript.

Google's Go (0)

Anonymous Coward | more than 2 years ago | (#38319002)

Don't really agree. Just look at the popularity of "Go".. if you don't know what it is try googling it, oh yeah....

mossad, nsa, fbi, cia, clandestine, secrets, mind (-1)

Anonymous Coward | more than 2 years ago | (#38319008)

nude garbage truck driver discovers a tasty treat: salty and moist but delicious.

how did you complete the puzzle, lamented poor gregory the squirrel.

the speed racer put a penny in his pocket for another day and unfolded the banana umbrella inside his pants for patriotism which was demanded by the seven dwarves inside a weather balloon shortly after crashing in new mexico.

Forth Post! (-1)

Anonymous Coward | more than 2 years ago | (#38319010)

Forth post

The reason (4, Interesting)

bonch (38532) | more than 2 years ago | (#38319050)

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:The reason (1)

DragonWriter (970822) | more than 2 years ago | (#38319162)

The reason popular languages move more slowly is because established codebases use them. Backwards compatibility is a good thing.

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 to innovate than slow-changing established languages, but I'd go further and note that most of the changes that do make it into established languages are generally the results of those elements being proven in less conservative languages and then bubbling up to the slower-moving languages. Without newer languages as a source of innovation, there wouldn't even be the progress there is in established languages.

Re:The reason (1, Insightful)

bonch (38532) | more than 2 years ago | (#38319244)

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:The reason (1)

DragonWriter (970822) | more than 2 years ago | (#38319402)

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.

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 quantitatively shown to be superior to others in specified circumstances -- will certainly be adopted when discovered if they are are analytically shown to be good, the quality of programming constructs isn't usually something that can be analytically quantified (at least, in an unambiguous way), but instead must be demonstrated through practical application.

Re:The reason (0)

Anonymous Coward | more than 2 years ago | (#38319238)

This, and there is another factor: code cost. If you are a company, you need to hire programmers (and if you run a free software project you need to find people with the skills and spare time). When the language is niche, or hard to grasp, or tedious, code cost goes up. This is why code in languages like VB, C# and Java is cheap, code in C++ is somewhat expensive and code in a new language potentially prohibitively expensive. If you're lucky it could gain traction, but there are a lot of niche languages out there that didn't.

Re:The reason (1)

Alex Belits (437) | more than 2 years ago | (#38319364)

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.

Re:The reason (3, Interesting)

mevets (322601) | more than 2 years ago | (#38319388)

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.

Just recycle the old ones .. (4, Funny)

ackthpt (218170) | more than 2 years ago | (#38319052)

Algol for Web, COBOL beans, Object Oriented PL/1 ...

Re:Just recycle the old ones .. (1)

nirgle (554262) | more than 2 years ago | (#38319318)

Don't forget assembler on rails

Re:Just recycle the old ones .. (0)

Anonymous Coward | more than 2 years ago | (#38319368)

When I was in college, I've seen websites scripted using Ada...

lets reconstitute the ADA committee (1)

peter303 (12292) | more than 2 years ago | (#38319054)

Lets just say that languages designed by committees look that way.

Re:lets reconstitute the ADA committee (5, Insightful)

mbkennel (97636) | more than 2 years ago | (#38319082)

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:lets reconstitute the ADA committee (2, Interesting)

Anonymous Coward | more than 2 years ago | (#38319328)

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.

Use the right tool for the job (3, Insightful)

hoffmanjon (845536) | more than 2 years ago | (#38319058)

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.

Re:Use the right tool for the job (0)

Anonymous Coward | more than 2 years ago | (#38319136)

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.......

Lots of tools is great, but remember there's going to be that guy coming after you and he's going to have to work on your project too. If I have to go out and buy a new set of tools just because the guy before me decided torx screws were the way of the future, that gets to be a royal pain real quick. Philips screws may not be perfect, but I know the guy after me is going to have the right bit in his toolkit.

Re:Use the right tool for the job (2)

k3vlar (979024) | more than 2 years ago | (#38319384)

I'd take having to buy a new set of Torx drivers over having to pry open something that's been glued together. At least the guy before you was kind enough to use screws in the first place.

Re:Use the right tool for the job (1)

mlts (1038732) | more than 2 years ago | (#38319462)

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.

Backward Compatibility (1)

ElmoGonzo (627753) | more than 2 years ago | (#38319060)

As long as a new version of a language maintains existing capabilities, there is no barrier to adding new features. Or like Groovy, just extend to add the features you think are needed but keep the output compatible with the "parent".

Tiobe Index reflects conservatism (2)

ewg (158266) | more than 2 years ago | (#38319066)

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:Tiobe Index reflects conservatism (1)

Mashiki (184564) | more than 2 years ago | (#38319134)

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.

Hardly true, other modern languages on list (0)

SuperKendall (25149) | more than 2 years ago | (#38319158)

It's notable that the Tiobe Index has just one 21st century language among the top ten (C#, 2001)

Java is on there as well, which C# was of course taken wholesale from. Yes C# has moved beyond where Java was, but if you are going to claim C# is a "21st century language" then you have to acknowledge also the other languages that have moved substantially - like Java for one (though it's slowing down for sure), and also Objective-C (which now has GCD/Blocks(closures)/ARC.

Re:Hardly true, other modern languages on list (1)

DeathFromSomewhere (940915) | more than 2 years ago | (#38319488)

First appearance of java: 1995. [wikipedia.org]
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.

Bah. C and COBOL aren't going anywhere. (1)

stevegee58 (1179505) | more than 2 years ago | (#38319070)

As long as there are working applications implemented in these languages they'll never go away.
Not to mention old dinosaurs like me will be employed until we're 80 working with these stone-age tools. Plblblblblblbl (*sound of raspberries*)

More is not better (or worse) than less, ... (1)

foobsr (693224) | more than 2 years ago | (#38319096)

... , 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 (1)

Timbo (75953) | more than 2 years ago | (#38319104)

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 -- no compromise and at any cost. I'm not singling out C++ either; pretty much every language is upgraded in the same way. The difference with C++ is that it's that old and the changes are that great that the syntax additions become plain ridiculous in some cases. It would be better to start with a relatively clean slate and just-do-it-fucking-right.

I like the look of D as a succesor to C++, but unfortunately it doesn't seem to be getting any traction.

I program in Goat-C (1)

Anonymous Coward | more than 2 years ago | (#38319130)

Function stretchass() {
return .cx, ru;
}

You have my sympathy (1)

DigiShaman (671371) | more than 2 years ago | (#38319148)

And this ladies and gentlemen, this why I'll never dive into the world of coding aside from minor batch editing with PS commandlets . As an infrastructure system administrator (server, network, workstation, phones act), you have my deepest sympathies. I don't know how you do it. All of those long hours in the night, new programming languages every time someone farts, fear of being outsourced, moving targets and scope creep. Hats off to you all. As far as I'm concerned, screw that!

Just for that (1)

DarthVain (724186) | more than 2 years ago | (#38319152)

I'll be programming the navigation system on your space shuttle using VB6. Have a nice trip! :)

Obligatory XKCD (-1, Redundant)

Anonymous Coward | more than 2 years ago | (#38319174)

The idea of "Language 2.0" is evil (0)

Anonymous Coward | more than 2 years ago | (#38319184)

The root cause of the problem is that versioned languages strive to be "backwards compatible" at all.

I've maintained for years that the proper solution is to create a new language standard that does not attempt to be compatible with the old language. Instead, the developers of the new language should provides a reference utility that converts from the v1 standard to v2 standard. This should apply to all incremental language revisions, so that users can upgrade the source and diff to see what changed before assuming that their applications will run correctly with the new language. Also note that creating the reference cross-compiler will help document the differences between v1 and v2.

p.s. Yes, I know this would cause a minor headache for standard library versioning, but it only has to be done once per language revision.

Re:The idea of "Language 2.0" is evil (3, Insightful)

RyuuzakiTetsuya (195424) | more than 2 years ago | (#38319376)

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.

We need more interface description languages (1)

Anonymous Coward | more than 2 years ago | (#38319194)

Today, most everything library based is C (*NIX weenie here, dunno about other architectures). And many problems have already been solved in one language or another over time, but its mainly C that has the ability to be called by other languages (Perl, python, C++, java, most everything). What we need is a better idl (http://en.wikipedia.org/wiki/Interface_description_language) or more of them. Ones that are performant, and able to do procedure calls, serialization/deserialization, etc.

PHP = perfection (0)

Anonymous Coward | more than 2 years ago | (#38319204)

Wrong with PHP example.
PHP was perfect from the start.. at being bad.

Forth All The Way Baby (0)

Wingsy (761354) | more than 2 years ago | (#38319206)

We don't need more, we need less. Just one. Forth!

Shouldn't that be in RPN (1)

colinrichardday (768814) | more than 2 years ago | (#38319432)

Forth more we need NOT less we need just one

Easy, break compatability (0)

Anonymous Coward | more than 2 years ago | (#38319208)

Take C or Java. It is held back by a bad design choice from early in its life? Drop support for that particular syntax. If 15 year old source code won't compile, oh well, you were going to have to rewrite it anyway if you want to port it to a new language.

No, we need one *better* language, not "more" (4, Insightful)

gestalt_n_pepper (991155) | more than 2 years ago | (#38319282)

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).

Slash-CAllister (4, Funny)

MikeTheGreat (34142) | more than 2 years ago | (#38319312)

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

Re:Slash-CAllister (0)

Anonymous Coward | more than 2 years ago | (#38319382)

You are right and I hate that fuckin idiot!

Query Languages (5, Interesting)

Tablizer (95088) | more than 2 years ago | (#38319334)

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.

Python is a bad example (4, Interesting)

Hentes (2461350) | more than 2 years ago | (#38319346)

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).

We need better programmers (1)

Anonymous Coward | more than 2 years ago | (#38319352)

A language is just a tool. In the hands of a bad programmer you get bad code no matter what the language. A good programmer can do good in most languages. Unfortunately most of the so-called improvements in new languages are merely the equivalent of library content.

There's only one real problem. (1)

RyuuzakiTetsuya (195424) | more than 2 years ago | (#38319412)

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' (2)

scamper_22 (1073470) | more than 2 years ago | (#38319484)

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.

Wheel, meet paint (0)

nurb432 (527695) | more than 2 years ago | (#38319500)

And hold still while i paint you a new color.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?
or Connect with...

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>