Hacker News Reader

Comment by ardell | Hacker News Reader

The problem with standardization is that you iron out all of the innovations. Certain language constructs are simply better for certain tasks. Lisp is built for recursion so it's great with lists. Object-oriented languages in theory are great for modularity and maintainability. Granted all these aspects have a lot to do with the coder in addition to the language.

If all languages required you to manage memory as in C I'd wager we'd have many fewer entry-level script hackers. Sure, every program would be lickety-split fast, but the App Store certainly wouldn't have 10,000+ apps.

And if every app were written in Java everything would be very portable but also quite slow. It's all about trade-offs and picking the right tool for the right job.

View on HN

I don't mean to be pedantic, but the 'Java is slow' thing simply isn't true anymore. It certainly used to be slow back in the day, but it's actually pretty good these days.

From what I've heard, programmers at Google put it in the same ballpark as C++.

This brings me to another point.. the choice of programming language often has more to do with image and branding as opposed to actual technical merit.

That's why we keep hearing the same old mantras:

Java -> uncool and slow

C/C++ -> fast

PHP -> hack

Ruby -> cool but slow

Cobol -> for dinosaurs

.. even after the problems are fixed, the image remains. It's pretty hard to change people's perceptions.

A lot of java software implementations are still very very slow. Try restarting a tomcat servlet container (web server) for some java web project and then try the same with some apache or django dev server. One takes 10 seconds, the other is done in a blink in of an eye. Look at eclipse/netbeans vs. xcode, swing applications vs. wxwidgets applications and so on. Java very bad start up times still makes it effectively slow.

Give me a break. What are you running the tomcat on? an 386? let's go back to Assembly yeii! eat some stones baby

JIT compiled languages are slow to load, because they have to compile each bit of code the first time they run it. That is why Java is known as a slow language, even though it does fine in benchmarks: because loading is the one operation that's slow enough for the user to notice.

The thing is, even compiled C++ apps are no better when loading a bunch of shared libraries etc.

OpenOffice.. I'm looking at you! ;-)

Counter-example: LuaJIT (http://luajit.org/luajit_performance.html), largely because the compiler / optimizer themselves are extraordinarily small.

He asked why we need different syntaxes, not languages. Most of what you said doesn't relate to syntax at all.

How could you have two different languages with the same syntax? The only thing I can think of is one is a subset of the other.

scheme and common lisp?

Isn't scheme a subset of common lisp (at least loosely speaking)?

No, not even close.

For one thing, scheme has continuations, a powerful construct that Common Lisp lacks. But it's true that Common Lisp is generally more "featureful".

That's a feature that scheme has that common lisp doesn't, but is this supported by a new syntax? I think that it is not clear cut what is a syntactical difference versus a difference in the feature set.

edit: I guess what I'm really asking is there someway in lisp to make a construct that would look just like call/cc? If you could then that's just a feature difference, but if you can't I would agree that's a syntactical difference.

Since you can write down all abstract syntax trees using the same syntax, and you can convert most languages into an abstract syntax tree (all the popular ones), it would be easy enough to write down most languages using the same syntax.

The real question would be whether that AST syntax would be better than the language's own syntax. I'm guessing it would be harder to read, since a good syntax for an AST would describe only the semantics of the tree, making it harder to pick out the structure of the language itself.

Reply on news.ycombinator.com