Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

>You'd never see a language like Perl, PHP, or even Javascript come from the academic community because they don't break any new ground.

No, you'd never see these languages from the academic community because they're horribly designed. They design betrays someone who has learned nearly nothing from existing languages as they all make mistakes that were encountered and solved decades ago.



>>They design betrays someone who has learned nearly nothing from existing languages as they all make mistakes that were encountered and solved decades ago.

But... the whole point with the popular scripting languages is that they are easy to pick up -- just because they are heavily influenced by old languages!

(Besides, it is one thing to copy features from existing languages -- doesn't imply there is nothing interesting in the new languages. [Edit: Not all, at least. :-)] )

Edit: Here is an example of the last case:

A few years ago, I heard a talk about Moose, a replacement for OO in Perl (by Yuval Kogman/"nothingmuch"). There were two main points (1) Moose is stable, (2) it is modern. "And with modern, I mean the latest research papers".


>just because they are heavily influenced by old languages!

They show signs of knowing about older languages but not understanding them. For example perl has dynamic variables (this is a huge win and for me the only good thing I have to say about the whole language)... but they're default. We had already fought this out in Lisp and found out that while they're an incredible concept and should be in any language that favors mutating variables, dynamic variables should not be the default.

Python using crappy one line lambdas instead of real closures. Why? Because Guido seems to not get functional programming. Ruby copies Smalltalk but Katz says Smalltalk "goes to far". What? A lot of the problems that trip people up in Ruby aren't a problem in Smalltalk. The biggest difference between the two is that Ruby isn't image based, but Smalltalk doesn't have to be either.

For me the biggest problem with the scripting languages is that they don't have any need to exist. They usually copy features from existing languages that already did a better job. If the manpower they got had been focused on the source languages the communities could have gotten a lot farther.

>There were two main points (1) Moose is stable, (2) it is modern. "And with modern, I mean the latest research papers".

The papers he was talking about were likely the Traits papers. Traits were done first in Smalltalk and aren't needed in Lisp because CLOS has proper multiple inheritance. Moose does look ok though.


>>problem with the scripting languages is that they don't have any need to exist. They usually copy features from existing languages that already did a better job.

All I've read (and own experience), says that scripting languages are much faster to develop with?

Do you have anything contradicting that?

Edit: Grammar


>All I've read (and own experience), says that scripting languages are much faster to develop with?

Well, your throwing me an anecdote and asking me to contradict it so I guess I can do so with an anecdote as well?

"Faster to develop with" isn't a sign of a properly designed language and it certainly doesn't justify the language existing. It only speaks to the packaging of said language.

I think we can find a great example in PHP. I think we'd be hard pressed to find someone that would suggest PHP is a well designed language [1], yet it uprooted perl and took over the web. Why? Because it was less effort to go from zero to working web application than anything else. If the creator of PHP had, instead, created his platform on Lisp (and excluded the poisonous Lisp IRC community), who knows, he might have had even more success because Lisp is better designed, actually existed, etc. [2].

[1] But this is the Internet after all, so I'm sure you could find some one who would say that.

[2] Of course you might say "yea, but it's hard to get Lisp running on new servers" and there is truth to that, but PHP didn't exist at all. Surely it would have been at least comparable effort to fork some Lisp project and create "PHP" from that.


>>your throwing me an anecdote

Sorry for assuming you were aware of this.

Consider code size, which is easy to measure -- and examples are over the net. Compare e.g. C/Java with the usual suspects (Ruby, Perl, Python, PHP, etc). For many applications, the scripting code is half the size.

A given programmer tend to produce a certain number of lines per day. Ergo, shorter coding time.

Coding time with an edit/compile/test cycle might be offset by modern IDEs (I have no data on this).

>>"Faster to develop with" isn't a sign of a properly designed language and it certainly doesn't justify the language existing.

Coding size costs money; both to write and to support. Money is one of the big motivators today...

>>[2] Of course you might say "yea, but it's hard to get Lisp running on new servers" and there is truth to that, but PHP didn't exist at all

I don't know much about PHP, but it is well known that the first version was written as Perl scripts.

(I don't know, does Lisp really have such problems with its community? Write anything bad about Python and you'll get flamed to a crisp, Ruby has a lots of childish rah-rah etc.)


I agree with your overall argument that less code = better. What I don't agree with is that that conclusively demonstrates good design. I think all of the scripting languages have design problems that were solved before the languages were ever written. For what it's worth, I don't consider Java well designed either. All of it's insights already existed elsewhere [1].

Lines of code is also a bad metric. You have to also count characters, etc. There was a study that did just this for C++, Java and Smalltalk. Java was 3 times more concise than C++ and Smalltalk 3 times more concise than Java.

[1] Interfaces would be the closest Java was to inventing something but Smalltalk had these informally (and some environments would let you work with them directly).


>>I think all of the scripting languages have design problems that were solved before the languages were ever written.

I don't disagree. But many/most of those design decisions were made to ease learning path, etc.

I should know by now that it is hard to argue "worse is better" to a CL guy. :-)

(C++ is quite a bit more flexible than Java; what feature took so much more characters? afaik -- with modern libraries, you can be very productive in C++. It isn't used so much because of the pain, I guess...)


> All I've read (and own experience), says that scripting languages are much faster to develop with?

Much faster to develop with than what is the question. Much faster to develop with than C++? Or Java? Sure, but that's not a very impressive benchmark is it?


The scripting languages are, in much, a reaction to the system level programming languages used at the time of their creation.

A pity Lisp or some other existing neat envirnoments didn't fill that niche. It might have something to do with their community, I guess.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: