Hacker News new | ask | show | jobs
by shiranaihito 6072 days ago
Did you really take the post that personally?
1 comments

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

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.

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

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

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!