Hacker News Reader

Nothing in this article says anything about "dynamic languages". If anything, the author is in favor of Java. He simply suggests that it takes some of the features from C#, which is a very Java-like language, but hasn't been encumbered by the "Java ecosystem" (which is basically large IT companies that want to outsource everything to India, which is already trained to crank out Java 1.4.)

Static typing? who needs it. Lets write our own type checking all over the code.

You have to write your own type checking in Java, since any value can be either of the declared type or null. You know NullPointerException? That, my friend, is a runtime type error. (C# and Haskell both avoid that.)

Anyway, I could go on and on about language features that Java needs. But Scala implements them, so just look there.

"I know it's ridiculous that at some point programmers may figure out that languages are largely irrelevant, but I hope it happens one day."

One can't "figure out" that which isn't true ;P

As a proponent of language-oriented programming I can only disagree strongly with your statement. Languages are supremely relevant. However it is true that with respect to a specific problem, the expressive difference between almost any two general-purpose languages pales in comparison to the difference between a general-purpose language and a domain-specific language specifically tailored to the task at hand.

In my as-of-yet-unreleased Common Lisp web framework, I have DSLs for:

- HTML ("building", rewriting and outputting) - CSS (building and outputting) - Form validation - Error message specification and customization - Declarative configuration management (loading and dumping, eventually modifying too) - and probably others I'm forgetting at the moment, plus a bunch of others I'm planning to do

I'm sure Java has equivalent stuff, the problem is that their solution has to fit in a rigid mold (object-oriented, java syntax) so there's a lot of cognitive resources wasted in translating back and forth between your mental model of what you want to do and how you must express it in Java.

Would shakespeare have been terrible if he had written everything in french?

Personally, I don't think so.

Would he have done as well in a language that didn't have adjectives or adverbs?

That's not a good comparison. You can do anything in any turing complete language. They're all equally expressive. If the language isn't expressive enough, make it so.

Isn't that contradictory?

If all turing-complete languages are equally expressive, how does adding another feature to a language that's already turing-complete can possibly make it more expressive than it already is? It was turing-complete before the addition and it's just as much turing-complete after the addition.

I'm not really impressed by turing-tarpit-style arguments. There's at least one thing I can do in Common Lisp that I can't in Java: Implementing new syntaxic constructs look exactly like they're part of the language. I won't bore you with a long laundry-list of other similar things.

In fact, you know what? If by the turing-completeness criterion all languages are equally expressive, then the important points of comparison between languages in terms of expressiveness are necessarily matters other than turing-completeness.

Or would you argue that, say, x86 machine-language is just as expressive as say, Java? According to your turing-completeness argument that would seem like a yes. By the way, I do include a certain measure of "productivity" in my use of the word "expressiveness". Do you?

You are exactly right. Turing completeness is irrelevant when comparing languages, because it is a property of both. Turing complete or not, good luck programming your graphics card with Tcl or having boilerplate-free Java. It just isn't possible.

But the way I see it is, "it's not my problem if people want to write boilerplate all day" or that they like Java. Using Java does not take anything away from me, except possibly contributions to the community. (But then, the fanbois are rarely contributors to the community. This is true even for me!)

You will never convince axod that Java would benefit from new features. He is happy to be in a minority here (a "smug Java weenie"), and that happiness is worth more than potential increased productivity.

HN is a weird place for programming discussions. People here seem to think that making a website that people will visit and look at ads on is somehow correlated to code quality. It's not. It's just that you will enjoy making that website more when you aren't manually writing your own delegation functions, or writing "Foo foo = new Foo()".

>> "Or would you argue that, say, x86 machine-language is just as expressive as say, Java? According to your turing-completeness argument that would seem like a yes."

Yes. I absolutely would, and I've written about the same amount of x86 code as I have Java. They are each suited better to different tasks, but they're both just as expressive for me.

Uh?... English and French are two general-purpose human languages and I was talking about computer languages, and then mostly about domain-specific ones.

So I guess you completely missed my point.

It is not just a fashion war, it is about investment of resources. If I would like to program in LISP, but all the big shops insist on Java, I lose.

Static vs Dynamic: I guess both have pros and cons. But even for static types java seems to lose out now.

I'll leave the roid rage against dynamic languages alone for now.

A good programmer beats a good <language> programmer IMHO.

I heartily disagree with this statement. I seriously doubt a good programmer can step into, say, C++ and work as effectively as they might in Java. They don't know how to manage memory well. They won't understand a lot of the nuances with pointers. They won't use a lot of the more subtle syntaxes a "good" C++ programmer will know. The same is true with Java or Python or (and I know this one from a good bit of experience) Ruby.

Knowing your tools well is essential. Being a generalist is great until you actually have to do something.

By "good programmer" I meant one that has experience of a wide variety of programming - memory management, pointers included.

Did you really take the post that personally?

I'm just bored of the endless fashion strutting that goes on recently in programming. I think it's irrelevant and tiring.

If a language solved a problem 5 years ago, it'll solve the same problem today. It won't die unless something else is found that solves the problem in a better way.

Yeah, why bother keeping up with advances in the field? Back in my day, sonny, we used our Java 1.4, and that's the way we likes it. Any new ideas should be immediately rejected as "fashion strutting", especially new ideas that have been successfully implemented in other languages for decades.

Go on then... as I asked in another thread and you didn't reply, list out a few advances in the field of programming in the last 5 years.

Should we make CPU makers update their machine code as well every year or so to integrate all these programming discoveries?

Let's start with Java's object system, and add state and implementation to interfaces. This way you can write something like:

   role Eq {
       requires 'equal_to';

       method not_equal_to($a: $b) { return !$a->equal_to($b) }
   }

The technique of composing classes from parts has recently been popularized by Smalltalk, Perl 6, Perl 5 (Moose), and Scala. (Scala's implementation is intentionally limited for some reason; look to Moose for the most reliable implementation that people actually use for Real Work.)

If you want to do this in Java, you would have to create a class like:

   class NotEq {
      private Eq a;

      method not_equal_to(b) { !a.equals(b)  }
   }

   class Foo implements Eq {
      private NotEq neq;

      Foo() { neq = new NotEq(this) }

      method equal_to(b) { ... }

      method not_equal_to(b) {
          neq.not_equal_to(b)
      }
   }

This is a lot of code to write, which is why people just cut-n-paste instead.

Also, Java is not merely 5 years behind, so it is worthwhile to look back farther to find ideas that Java could embrace. Java would do well to steal a sane object system like CLOS or Moose; it could really eliminate a lot of boilerplate. (One thing I think is annoying about Java is how much work the constructor has to do. In Lisp and Perl, I never write my own constructors, the object system does it for me. This means that things can be composed without the programmer having to know every detail, including which position each attribute initializer should be in.)

Anyway, if you really think Java is the state of the art, you should look around a bit more. Yes, it's silly that people want to do their own type checking in "dynamic languages", but that's not why they use them -- it's all the other features that they want. The lack of static type checking is an unfortunate overreaction to C and C++.

>> "Anyway, if you really think Java is the state of the art, you should look around a bit more."

Thanks for proving my point. My point is, It doesn't have to be "State of the art" (fashionable). It has to work.

Why not use C then? Where do you draw the "it has to work" line?

You don't make sense again.

I do use C. For classes of problems that are appropriate - kernel/low level stuff.

For several things though, the lack of gc'd memory management, buffer overflows etc is a good reason not to use C.

It sounds like you truly identify yourself as a "<language> programmer" rather than a "programmer" :/

I am more interested in writing good programs than "just getting something done". That means using tools with the appropriate level of expressiveness, of which Java and C are neither.

Ask me which of Common Lisp, Haskell, and Perl I prefer, then call me a "<language> programmer". Remember, in the other threads, I am advocating combinations of features that do not currently exist in any programming language. I may be a "<language> programmer", I guess, but that <language> does not actually exist. Meta...

(You are the one who thinks that every feature that Java has is essential for programming, and every feature it's missing is <some cynical weasel-words here>. That is indicative of seeing the world through Java-colored glasses.)

FWIW, I've written far more non Java code than I've written Java code, so I wouldn't say I have "Java-colored glasses") ;)

I've also never said that Java is better than <insert other language here> without qualifying what it is better for.

When did you qualify what it is better for? (Better than what?)

Soviet tanks were not exactly 'state of the art' either, but they worked pretty good. What's 'hot' doesn't automatically qualify to solve things for the longer term, in fact being 'hot' is a fantastic reason to stay clear of a technology, because if it is in fashion this year it could very well be out of fashion next year.

Yeah, except many of these ideas have been production-tested for 25+ years.

Remember that Java is the language that introduced garbage collection to the world. Before Java, it was basically an untested academic thing that Lisp machines did. Why be liberal with such a radical new idea and conservative with things that let you implement programs the same way you do now but with less typing? It makes very little sense.

Garbage collection is a massive gain. Far less code, and less bugs. No brainer decision there.

Typing a few less characters on boiler plate doesn't buy you anything, unless you're a slow/lazy programmer.

Typing "public static class" is boring, yes. But it's irrelevant. It can't contain bugs, so getting rid of that doesn't buy you anything at all.

Less typing != less bugs (When the code is compiled, statically typed, etc).

There is absolutely no reason to duplicate code in Java, and if you're copy/paste coding, it's not the languages fault, it's yours.

"""Typing a few less characters on boiler plate doesn't buy you anything, unless you're a slow/lazy programmer"""

Must be nice to have an infinitely large short term memory.

Not to mention that I have never said a thing about things like "public static void". I specifically mentioned the object system above and how much manual easy-to-get-wrong code is required simply to make things that have an equals method also have a "not equals" method.

Sometimes I wonder why I bother arguing with axod. Wait, I always wonder that...

Come on. How often do you really need an equals method in your classes? It's not a big deal. (No, I'm not one of those people who insist on writing equals/hashcode/toString on everything even when it's not being used).

I wonder why I try to bring sanity to these sorts of discussions also :/

The example is an example. For "not equals" you might as well just write not, then equals.

But amazingly, sometimes code more complicated than that needs to be reused

I wonder why I try to bring sanity to these sorts of discussions also :/

When did you do that? You seem to bring a lot of emotion, very few technical arguments, and a lot of words like "fashion".

Since Java lacks generics, there are many kinds of code which require duplicate code in Java. Specifically, every place where you would use generics in another language (Templates in C++, or TypeClasses in Haskell, for instance).

Java definitely supports generics as of 1.5 - did you mean that it doesn't support generics to the extent of C++? Most basic uses (containers) are identical between the languages, and while Java doesn't allow compile-time "duck typing" that C++ does, you can fake it by using the "? extends SomeInterface" syntax.

Java supports type erasure, which it idiosyncratically calls "generics", even though it does not allow generic programming. A generic function in a language with actual generics can work generically, on more than one type. A "generic" function in Java can work on exactly one type, namely the type which the "generic" type becomes after type erasure.

You can use "? extends SomeInterface" only if you write SomeInterface wrappers for every type which you want to use "generically." This is boilerplate relative to most other languages.

Personally, I find this boilerplate equivalent to the comments one has to write documenting the requirements of the type, with the added benefit of readable error messages when you pass the wrong type. In other words, I find:

  // T here is a type that must support these two operations:
  //   bool froznit();
  //   void frobnob(Foo* foo);
  template <class T> class Frozner { ... }

And

  public interface SomeStupidName {
    public bool froznit();
    public void frobnob(Foo foo);
  }
  public class Frozner<? extends SomeStupidName> { ... }

To be just as much work to type.

I think that has to do a lot with Java's heritage.

What they were shooting for seems to have been something that combines the syntax of C and some of C++ for easy access to a large pool of existing programmers but without those 'scary pointers', and the memory leak issues associated with bad programming habits in C and C++.

Although I will agree with you in general about Java, I have to say that problems/challenges change, therefore you need new specific languages or automation tools for the job.

In my point of view Java is just the tool to create new domain specific languages that solve these new problems.

But, general languages that just make just a bit shorter or less verbose (as everyone who likes to dismiss Java uses quite often), to create a class won't do it for me to change language/platform.

What tools does Java have for creating domain specific languages?

domain specific languages == libraries.

You make some libraries, functions that do shit. Then call them. That way other people can still read the code, and help.

It's like GOSUB but better!

I'll pretend you're asking in earnest: Depending on the need, you have a bevy of parser-generators to choose from. My favorite is SableCC.

Or, if you want something lightweight where you effectively have a DSL without creating an actual language, look towards static imports + fluent interfaces + builder pattern:

http://blog.centuryminds.com/2007/10/java-static-imports-flu...

I don't disagree with anything you've said, but the author of the post made the same point - languages don't die unless they are completely replaced. The author thinks that Java may live on for decades.

He has taken the unfortunate, but popular, definition of a dead programming language: one which has stopped evolving. Of course, such a language is no more dead than sharks.