At some point we have to stop making new programming languages.

Only pedantically true: At some point, the universe will end.

Creating new programming languages is one of the most powerful ways to move up the level of abstraction. There is no foreseeable end to the need to do so.

D'A
... who wrote this for those Jyters who thought he was asleep in 164

No we can't. Now fuck off.

Hey, I was asleep in 164.

But even so, think of programming languages as evolution. Certainly, at some point, they will reach some ultimate form that expresses everything in the most compact and easily comprehensible fashion possible.

Of course, the universe will end first.

Excellent points. @nic, especially well stated.

But aren't the abstractions being introduced in the framework and environment around the language? Rather than innovations in language syntax itself?

Assuming the syntax provided for classes and inheritance, but didn't imply they were required to be used or that they were immutable at run time, what's the harm in having a standard syntax?

It'd make porting things a lot easier. Even if the code doesn't copy it could even streamline the adoption of the next innovation cuz you wouldn't have to start with the basics.

Again, fuck off.

This is ridiculous tosh. Some language features that have "arrived" in general purpose languages recently:

- generators
- yielding; piss poor continuation support; it would be nice to see proper continuation support in more GPLs
- generics
- monads; more languages should support monads

And there's a long way to go before we get to a point where we've got GPLs that are both popular AND capable of expressing things sufficiently richly to last another 50 years.

*Think* about what you're claiming. We should not do any language research because porting can take time? That's just madness.

Okay now,

Generators aren't a language feature, they're a utility of the ide or command line. Some ide's have visual designers. None of this is a language innovation - it's tooling.

Generics are part of a syntax but they aren't very recent. C++ introduced templates and the idea has continued with csharp, java, and with the implicit generics you have in loosely typed object languages. A lot of prototypejs functionality are generics patterns. I took them as read.

Every place I've seen yielding, concurrency, asynchronous execution, etc. lately has has boiled down to holding references to things that can be called when appropriate. Modern languages support that. Improving that (monads also?) would be in improving patterns used in framework, not necessarily in the language itself.

I didn't say stop language research. I said we have to stop making new programming languages. As in start from scratch and reinvent conventions from the ground up.

I know Ruby's hot for example. But why "friends.each do |friend| xxx end" instead of foreach(friend in friends) {xxx}"? Or "friends.each(function(friend){xxx})"?

And what's up with this?
Net::HTTP.start( 'www.ruby-lang.org', 80 ) do |http|
print( http.get( '/en/LICENSE.txt' ).body )
end

Why not "function(http) { blah }" instead of "do |http| blah end"? And what's up with this end-of-line continuation backslash action?

I think it's great innovation of course, I just haven't seen anything where the syntax-mulligan was needed for the innovation.

Especially while working in rails you have one foot standing on ruby and the other standing on jscript. The languages could have been far more similar.

How is generators not a language feature? WTF?

You can do this with a toolkit?

lst = [x for x in fn_makes_lst()]

Errrr.... no.

Generics aren't C++ templates at all. They're from Haskell.

Yielding: there's a specific example where people have used syntax to build bigger abstrations which have caught on rapidly and made people lives better but you say "ah... but that would be better in a framework"

Continuations (and yielding) aren't necessarily about concurrency anyway. Continuations are generic control structures. You can't do them outside of the the parse tree. It's a good thing that we're seeing languages play with those ideas.

"I didn't say stop language research"... yes you did, in the claim right here:

"But can't we come up with a common languages syntax/operators/keywords?"

language *is* syntax. APIs are just things you do with the syntax.

And for goodness sake, man, if you have a problem with ruby just don't use it.

If you want to be a mono-linguist that's fine. But why on earth would you want to make the rest of us do that as well?

By language I mean, for example, just Ruby. Not rails etc. Eclipse is not part of Java, Visual Studio is not part of Dotnet, those tools can spit out code too but that's all a generator does. It's a little machine to spit out code - it's not part of the language.

You example contains exactly the point I'm making though.

lst = [x for x in fn_makes_lst()]

means nothing to me because the syntax is unlike anything I've seen before. I do know what the keywords 'for' and 'in' mean in more than a handful of languages and none of them seem to apply here.

By yielding what I believe you're saying is there is syntax in the parse tree to populate a larger structure which then coordinates the execution. That control structure could be populated with normal conventions though couldn't it? Isn't that along the lines of what you find in scriptaculous etc? Sorry for being obtuse here but isn't syntax in this case more about terse notation than anything?

There yes. Terse notation for new complex situations is all good. But declaring a class is not a new situation. Common syntax doesn't mean nothing new ever again. I just think that at some point we'll be able to say the things languages have in common, like "class Foo : Bar { etc. }", have a form of expression that's good enough and you're not tying your hands in some way by using it.

You don't know what a generator is so go look it up. Python has them, a couple of other languages (Haskell) have them (where Python got them from basically).

Yielding. No. Yielding is a kind of continuation. This is a popular way of doing stream or lazy programming. It can't be done functionally in most languages because they are strict.

So I think there a bunch of things that you don't know about programming languages that maybe you should find out about before you start saying "hey! let's not make loads of different programming languages! It's so confusing for me" which seems to be what you're saying.

I'm sorry if I'm being harsh but I don't like being told what to do.

Please note also that this has been claimed, and soundly rejected before on jyte. Not that that's necessarily a block to anyone else claiming it... but it adds to my negativity.

By the way... no syntax is not necessarily syntactic sugar.

Go look at Scheme. Scheme has the base control operator call/cc but it's not fair to say:

hey! now we have call/cc we don't need exceptions, loops or any other control structure anymore because they're all syntactic sugar.

Many syntax elements are not sugar but are fundamental abstractions of more common concepts. The common concepts are necessary because very high abstractions can be a lot of effort to work with.

I had looked this up before I posted.

http://wiki.rubyonrails.org/rails/pages/UnderstandingGenerators

"What are they?

"Generators are little machines that spit out Ruby code. Usually they do only one thing, and manage that well.

"Generators help reduce the tedium of dealing with boilerplate code by generating it for you. Generators can produce simple code (such as for a new model) or more complex (such as a login system)."

Interesting conversation though. The yielding/continuation is an interesting concept. I think you can find it in csharp also.

http://www.codeproject.com/csharp/listprocessing.asp

Which I didn't pay much attention to when I saw it for the first time. Too much magic. But again - to beat a dead horse - it didn't take a new programming language to accomplish.

That's generators in the context of Ruby. Generators in the context of Haskell and Python don't spit out code, they are just iteration systems for generating lists from lists.

Generators are interesting because they are an attempt to make something as nice as LISP's map function for an infix syntax. That's a very sensible and laudable thing to do I would have thought.

Of course, if we all started coding in LISP I'd probably agree with "we don't need another language". But I doubt you would be happy if that was the final language which you long for.

yield is in C#. And in a few other languages,

My point about yield is that it is a form of call/cc that is only now being adopted by mainstream languages. Since call/cc is so generally useful (see it's use with smalltalk to make continuation based webservers for example) I would expect language designers to continue experimenting with different forms of it for their languages and for new languages.

I honestly don't have a preference. The claim was inspired by the fact that I'm learning Ruby as we speak to follow the strongest industry trends.

Maybe I'm getting too old for this, but I swear I've gone through this exercise every two or three years since around '90. I wish for nothing more than if syntax isn't going to become predictable at least these things would have a longer half-life.

Yep. If you don't like change you're definitely in the wrong industry.