5 ms·

I hate auto-generated code by IDEs. It always produces stuff like... that.

by runn1ng 14y ago

eropple 14y ago
And then hides it. Which I'll agree is a little stupid, but you never really see it in practice.
arcdrag 14y ago
You realize that any modern language is nothing more than an abstraction layer to automatically generate code in a lower level language right? The only difference here is that if you view the .java file in a plain text editor, you'll actually see that block. You won't see it in modern IDE's though. It gets automatically collapsed, as it is an aid to the compiler more than the developer.
- hermanhermitage 14y ago
  One viewpoint is such noise doesn't scale - both for tooling or human consumption. Java and C# are both heading into a territory where it is getting less reasonable for a human to write them without tooling support - is this what people really want? If we have such sophisticated tooling why bother dropping to low level text? Wouldn't it make more sense to manipulate and compose more expressive objects than text? The end game is you obsolete the languages and they become targets of more expressive languages. It highlights a potential design flaw in the composition model of the language and/or the libraries. Should for example C/C++ include the generated assembler in pragmas to guide compilation? Always? Visible to the programmer?
  - jrockway 14y ago
    I disagree. It's the concise model that can't scale without tool support. Imagine you import foo.∗, bar.∗, and baz.∗. How does someone reading the code know where the Quux class comes from? They can't, without checking all of the namespaces that were imported. But if you just "import foo.bar.baz.Quux", then you know exactly where Quux comes from. This whole thread sounds like a lot of non-java-programmers complaining about Java. (Note: incorrect * used above because HN's parser sucks.)
    - hermanhermitage 14y ago
      I'm not too fussed with the namespaces - I dont think you will find anyone arguing against that. What is at issue is the over specialization of class or framework components because of language limitations. A language that leads to degenerate boilerplate or mounds of endless repetition (but in user land code and libraries/frameworks) can be viewed as having a serious abstraction problem. Do you really think java will be looked at in 100 years as the pinacle of language evolution or some horrible dead end? Like cobol or basic?
      - jrockway 14y ago
        This library looks bad because it is bad. (I just wrote a long rant about this, but on my internal blog, so I'll summarize here. They have 12 classes implementing immutable lists. A class for an empty list. A class for a list with one element. A class for a list with two elements. That continues to 10 (!!!!) elements. Then there's a class for lists greater than size 10. This pattern is repeated for all the other types. That's going to be messy in any language. Google seems to survive with 0-, 1-, and n-element classes.)
      - arcdrag 14y ago
        Do you think that 100 years from now, anyone other than programming language researchers will have heard of any programming language used today?
        DanBC 14y ago
        Do you think 40 years ago people would have thought that people would still be using C (and derivatives)?
        hermanhermitage 14y ago
        Yes a very interesting point. You could even replace C in that sentence with Algol and it rings fairly true. In C it always feels like the pillars were speed of implementation and speed of execution on low cost hardware and without sophisticated compilation technology. Ignoring syntactic issues there are only a few things I wish it had as part of the specification (when viewing it as a (if used in a certain manner) portable minimum viable language where assembly language meets high level languages): 1. A better implementation of Landin's J operator than setjmp 2. Compile, Link, and Load time reflection 3. Portable dynamic code generation (at runtime) operators (to allow late binding and JIT style optimization). Java can be also viewed as a reworking of Algol but this time with design pillars centred on working in a VM, modularity for large code bases and simplification principles. It always feels to me like the simplification was intended to reduce complexity (originally: signed ints, no function pointers, no lambda, no manually managed memory objects) but unfortunately this has just pushed huge complexity into code bases. Whilst I can accept this in C (minimum viable human readable and writable portable code), for some reason because Java sits on a huge stack of runtime code and tooling I dont like it. What Java did really bring to the mainstream is the whole VM thing (although some of us will remember BCPL or UCSD p-code), but I think the VM brings too much Java-ism into it and a smaller and better VM lies within.
  - bradleyjg 14y ago
    The very best chess teams consist of a computers and a humans cooperating with each. The computer insures perfect tactically play while the human concentrates on overall strategy. Why should programming be any different? The very best IDEs in the hands of a skilled programmer should produce code better than a similarly skilled programmer who insists on using a dumb text editor. If the resulting code can only effectively be modified by a similar computer/human team - well that's a small price to pay.
    - kiba 14y ago
      The very best chess teams consist of a computers and a humans cooperating with each. The computer insures perfect tactically play while the human concentrates on overall strategy. Except, we're using computers to help assist us with a terrible codebase that is unnecessary complex and verbose. Why should programming be any different? The very best IDEs in the hands of a skilled programmer should produce code better than a similarly skilled programmer who insists on using a dumb text editor. If the resulting code can only effectively be modified by a similar computer/human team - well that's a small price to pay. Vim and emacs not "dumb text editors". They are very powerful tools in the hand of a skilled programmer.
    - jrockway 14y ago
      I made a vow to myself to never reply to a comment that used both "tactics" and "strategy" in the same sentence, but here goes... Why should programming be any different? The very best IDEs in the hands of a skilled programmer should produce code better than a similarly skilled programmer who insists on using a dumb text editor. If the resulting code can only effectively be modified by a similar computer/human team - well that's a small price to pay. That's true, but show me an IDE that lets someone write better code than someone without the IDE. The reality is that IDEs provide very superficial features that help beginners be more productive, but don't help experienced programmers much. (The most cited feature, symbol completion with docstrings, is available in pretty much every text editor. It's nice confirmation that your mental model matches the tags table, but hardly essential.) All I can say is: Java got a lot easier for me when I stopped trying to make Eclipse useful. It turns out that Eclipse doesn't really do anything except sleep(5) after every keystroke.
jrockway 14y ago
I never use an IDE to edit Java, and that's pretty much what it looks like. To use a class in Java, you must import it first. To import it, you type "import " and then the fully qualified name of the class. From there, you can use the unqualified name. It's basically like that in every other programming language, though others are less opaque. In Perl, you get a variable called %:: that holds the symbol table, and you can directly manipulate it. That lets you write something like "use all" and use every CPAN module at once. In C, you can include arbitrary source files at arbitrary places, making it possible to import every library with one statement. But in both languages this is considered terrible practice, with most style guides wanting one use or include statement for each library. Exactly the same as Java. If you were going to complain about the API, you might complain about the "impl" in every import. That's a silly convention that wastes typing. (Also, Google puts their collection classes in the "collect" namespace, saving a few letters over calling it "collections" like Goldman.)
- jordyhoyt 14y ago
  But, if you're using a modern IDE, removing impl or going from "collections" to "collect" isn't saving anyone any time. Or, at least, it shouldn't be.
  - jrockway 14y ago
    Sure, but it's always nice when imports fit on a single line without wrapping. Essential, no, but nice.
- irahul 14y ago
  > I never use an IDE to edit Java, What do you use? I find it extremely painful to write Java in Vim, even though I have been using Vim for quite some time and am very comfortable using it. Text based completions and re-factoring doesn't cut it for Java/C#, so I use eclim to use what eclipse is good at which comprises of smart auto-complete, auto-imports, generating getters and setters, implementing interface, auto-correct code for trivial cases etc. > To use a class in Java, you must import it first. To import it, you type "import " and then the fully qualified name of the class. From there, you can use the unqualified name. That's similar in Python. I think the parent post wasn't complaining about namespacing but the way project is structured and named(impl, factory).
sevenstar 14y ago
Does Eclipse do that?

I hate auto-generated code by IDEs. It always produces stuff like... that.

by runn1ng 14y ago

I hate auto-generated code by IDEs. It always produces stuff like... that.

eropple 14y ago

And then hides it. Which I'll agree is a little stupid, but you never really see it in practice.

arcdrag 14y ago

You realize that any modern language is nothing more than an abstraction layer to automatically generate code in a lower level language right? The only difference here is that if you view the .java file in a plain text editor, you'll actually see that block. You won't see it in modern IDE's though. It gets automatically collapsed, as it is an aid to the compiler more than the developer.

hermanhermitage 14y ago
One viewpoint is such noise doesn't scale - both for tooling or human consumption. Java and C# are both heading into a territory where it is getting less reasonable for a human to write them without tooling support - is this what people really want? If we have such sophisticated tooling why bother dropping to low level text? Wouldn't it make more sense to manipulate and compose more expressive objects than text? The end game is you obsolete the languages and they become targets of more expressive languages. It highlights a potential design flaw in the composition model of the language and/or the libraries. Should for example C/C++ include the generated assembler in pragmas to guide compilation? Always? Visible to the programmer?
- jrockway 14y ago
  I disagree. It's the concise model that can't scale without tool support. Imagine you import foo.∗, bar.∗, and baz.∗. How does someone reading the code know where the Quux class comes from? They can't, without checking all of the namespaces that were imported. But if you just "import foo.bar.baz.Quux", then you know exactly where Quux comes from. This whole thread sounds like a lot of non-java-programmers complaining about Java. (Note: incorrect * used above because HN's parser sucks.)
  - hermanhermitage 14y ago
    I'm not too fussed with the namespaces - I dont think you will find anyone arguing against that. What is at issue is the over specialization of class or framework components because of language limitations. A language that leads to degenerate boilerplate or mounds of endless repetition (but in user land code and libraries/frameworks) can be viewed as having a serious abstraction problem. Do you really think java will be looked at in 100 years as the pinacle of language evolution or some horrible dead end? Like cobol or basic?
    - jrockway 14y ago
      This library looks bad because it is bad. (I just wrote a long rant about this, but on my internal blog, so I'll summarize here. They have 12 classes implementing immutable lists. A class for an empty list. A class for a list with one element. A class for a list with two elements. That continues to 10 (!!!!) elements. Then there's a class for lists greater than size 10. This pattern is repeated for all the other types. That's going to be messy in any language. Google seems to survive with 0-, 1-, and n-element classes.)
    - arcdrag 14y ago
      Do you think that 100 years from now, anyone other than programming language researchers will have heard of any programming language used today?
      - DanBC 14y ago
        Do you think 40 years ago people would have thought that people would still be using C (and derivatives)?
        hermanhermitage 14y ago
        Yes a very interesting point. You could even replace C in that sentence with Algol and it rings fairly true. In C it always feels like the pillars were speed of implementation and speed of execution on low cost hardware and without sophisticated compilation technology. Ignoring syntactic issues there are only a few things I wish it had as part of the specification (when viewing it as a (if used in a certain manner) portable minimum viable language where assembly language meets high level languages): 1. A better implementation of Landin's J operator than setjmp 2. Compile, Link, and Load time reflection 3. Portable dynamic code generation (at runtime) operators (to allow late binding and JIT style optimization). Java can be also viewed as a reworking of Algol but this time with design pillars centred on working in a VM, modularity for large code bases and simplification principles. It always feels to me like the simplification was intended to reduce complexity (originally: signed ints, no function pointers, no lambda, no manually managed memory objects) but unfortunately this has just pushed huge complexity into code bases. Whilst I can accept this in C (minimum viable human readable and writable portable code), for some reason because Java sits on a huge stack of runtime code and tooling I dont like it. What Java did really bring to the mainstream is the whole VM thing (although some of us will remember BCPL or UCSD p-code), but I think the VM brings too much Java-ism into it and a smaller and better VM lies within.
- bradleyjg 14y ago
  The very best chess teams consist of a computers and a humans cooperating with each. The computer insures perfect tactically play while the human concentrates on overall strategy. Why should programming be any different? The very best IDEs in the hands of a skilled programmer should produce code better than a similarly skilled programmer who insists on using a dumb text editor. If the resulting code can only effectively be modified by a similar computer/human team - well that's a small price to pay.
  - kiba 14y ago
    The very best chess teams consist of a computers and a humans cooperating with each. The computer insures perfect tactically play while the human concentrates on overall strategy. Except, we're using computers to help assist us with a terrible codebase that is unnecessary complex and verbose. Why should programming be any different? The very best IDEs in the hands of a skilled programmer should produce code better than a similarly skilled programmer who insists on using a dumb text editor. If the resulting code can only effectively be modified by a similar computer/human team - well that's a small price to pay. Vim and emacs not "dumb text editors". They are very powerful tools in the hand of a skilled programmer.
  - jrockway 14y ago
    I made a vow to myself to never reply to a comment that used both "tactics" and "strategy" in the same sentence, but here goes... Why should programming be any different? The very best IDEs in the hands of a skilled programmer should produce code better than a similarly skilled programmer who insists on using a dumb text editor. If the resulting code can only effectively be modified by a similar computer/human team - well that's a small price to pay. That's true, but show me an IDE that lets someone write better code than someone without the IDE. The reality is that IDEs provide very superficial features that help beginners be more productive, but don't help experienced programmers much. (The most cited feature, symbol completion with docstrings, is available in pretty much every text editor. It's nice confirmation that your mental model matches the tags table, but hardly essential.) All I can say is: Java got a lot easier for me when I stopped trying to make Eclipse useful. It turns out that Eclipse doesn't really do anything except sleep(5) after every keystroke.

jrockway 14y ago

I never use an IDE to edit Java, and that's pretty much what it looks like. To use a class in Java, you must import it first. To import it, you type "import " and then the fully qualified name of the class. From there, you can use the unqualified name. It's basically like that in every other programming language, though others are less opaque. In Perl, you get a variable called %:: that holds the symbol table, and you can directly manipulate it. That lets you write something like "use all" and use every CPAN module at once. In C, you can include arbitrary source files at arbitrary places, making it possible to import every library with one statement. But in both languages this is considered terrible practice, with most style guides wanting one use or include statement for each library. Exactly the same as Java. If you were going to complain about the API, you might complain about the "impl" in every import. That's a silly convention that wastes typing. (Also, Google puts their collection classes in the "collect" namespace, saving a few letters over calling it "collections" like Goldman.)

jordyhoyt 14y ago
But, if you're using a modern IDE, removing impl or going from "collections" to "collect" isn't saving anyone any time. Or, at least, it shouldn't be.
- jrockway 14y ago
  Sure, but it's always nice when imports fit on a single line without wrapping. Essential, no, but nice.
irahul 14y ago
> I never use an IDE to edit Java, What do you use? I find it extremely painful to write Java in Vim, even though I have been using Vim for quite some time and am very comfortable using it. Text based completions and re-factoring doesn't cut it for Java/C#, so I use eclim to use what eclipse is good at which comprises of smart auto-complete, auto-imports, generating getters and setters, implementing interface, auto-correct code for trivial cases etc. > To use a class in Java, you must import it first. To import it, you type "import " and then the fully qualified name of the class. From there, you can use the unqualified name. That's similar in Python. I think the parent post wasn't complaining about namespacing but the way project is structured and named(impl, factory).

sevenstar 14y ago

Does Eclipse do that?