3 ms·

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 ma

by axod 17y ago

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?

jrockway 17y ago
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++.
- axod 17y ago
  >> "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.
  - jrockway 17y ago
    Why not use C then? Where do you draw the "it has to work" line?
    - axod 17y ago
      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" :/
      - jrockway 17y ago
        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.)
        axod 17y ago
        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.
        jrockway 17y ago
        When did you qualify what it is better for? (Better than what?)
- jacquesm 17y ago
  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.
  - jrockway 17y ago
    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.
    - axod 17y ago
      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.
      - jodrellblank 17y ago
        """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.
        jrockway 17y ago
        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...

by axod 17y ago

jrockway 17y ago

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

axod 17y ago
>> "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.
- jrockway 17y ago
  Why not use C then? Where do you draw the "it has to work" line?
  - axod 17y ago
    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" :/
    - jrockway 17y ago
      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.)
      - axod 17y ago
        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.
        jrockway 17y ago
        When did you qualify what it is better for? (Better than what?)
jacquesm 17y ago
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.
- jrockway 17y ago
  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.
  - axod 17y ago
    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.
    - jodrellblank 17y ago
      """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.
      - jrockway 17y ago
        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...