3 ms·

> "I think that some languages (like Java and C#) really require an IDE to be effective" I've never understood that statement (I've programmed Java for 10 year

by points 16y ago

> "I think that some languages (like Java and C#) really require an IDE to be effective" I've never understood that statement (I've programmed Java for 10 years, using a text editor). I think I'm effective.

Someone 16y ago
Java and C# are easy to parse. That makes them tooling-friendly. That, in turn enables the development of reliable, fast tools for refactorings. For better or for worse, most of that tooling is implemented as an IDE command/plugin. Command-line refactoring tools are way rarer. For example, <http://stackoverflow.com/questions/704062/are-there-any-open-source-command-line-tools-to-refactor-java-code&#62 http://stackoverflow.com/questions/704062/are-there-any-open...; was asked a year ago, but the top answer lists software that, according to it's website, was Last released seven years ago. So, IMO, that 'require' may not be absolute, but it certainly is pragmatic. What makes you think you are effective in Java? Do you know what you are missing?
- points 16y ago
  Most languages are easy to parse. The argument I've heard many times before is that you must use an IDE with Java because Java is overly verbose. I'm effective in Java in that I achieve what I want to achieve. The bottleneck has never been speed of typing/refactoring etc.
  - Someone 16y ago
    That depends on your definition of 'easy to parse'. For C and C++, you have the #include problem, macros whose definition isn't known until one calls the compiler. perl cannot be parses at all; there are cases where you must run a program to find out whether x is an identifier or a fiction name. For Java, you can take a function in isolation, search its source file for import statements, and tell me what the variables, statements and expressions are. C# was in the same boat, but with LinQ, I think it gave up that idea. Now,
    - chromatic 16y ago
      perl cannot be parses at all; there are cases where you must run a program to find out whether x is an identifier or a [function] name. Nonsense. A very small category of behavior exists where static parsing of Perl 5 cannot determine whether a given program is valid. That's all. It's possible to write a pathological program which has two valid and working parses, but I've never seen it and it's an intellectual game, not a trap waiting to snare an unwary programmer. (I have no idea what "an identifier or a function name" means, as Perl uses sigils to distinguish between variables and function names.) See http://www.modernperlbooks.com/mt/2009/08/on-parsing-perl-5.html http://www.modernperlbooks.com/mt/2009/08/on-parsing-perl-5.... for details.

by points 16y ago

Someone 16y ago

Java and C# are easy to parse. That makes them tooling-friendly. That, in turn enables the development of reliable, fast tools for refactorings. For better or for worse, most of that tooling is implemented as an IDE command/plugin. Command-line refactoring tools are way rarer. For example, <http://stackoverflow.com/questions/704062/are-there-any-open-source-command-line-tools-to-refactor-java-code&#62 http://stackoverflow.com/questions/704062/are-there-any-open...; was asked a year ago, but the top answer lists software that, according to it's website, was Last released seven years ago. So, IMO, that 'require' may not be absolute, but it certainly is pragmatic. What makes you think you are effective in Java? Do you know what you are missing?

points 16y ago
Most languages are easy to parse. The argument I've heard many times before is that you must use an IDE with Java because Java is overly verbose. I'm effective in Java in that I achieve what I want to achieve. The bottleneck has never been speed of typing/refactoring etc.
- Someone 16y ago
  That depends on your definition of 'easy to parse'. For C and C++, you have the #include problem, macros whose definition isn't known until one calls the compiler. perl cannot be parses at all; there are cases where you must run a program to find out whether x is an identifier or a fiction name. For Java, you can take a function in isolation, search its source file for import statements, and tell me what the variables, statements and expressions are. C# was in the same boat, but with LinQ, I think it gave up that idea. Now,
  - chromatic 16y ago
    perl cannot be parses at all; there are cases where you must run a program to find out whether x is an identifier or a [function] name. Nonsense. A very small category of behavior exists where static parsing of Perl 5 cannot determine whether a given program is valid. That's all. It's possible to write a pathological program which has two valid and working parses, but I've never seen it and it's an intellectual game, not a trap waiting to snare an unwary programmer. (I have no idea what "an identifier or a function name" means, as Perl uses sigils to distinguish between variables and function names.) See http://www.modernperlbooks.com/mt/2009/08/on-parsing-perl-5.html http://www.modernperlbooks.com/mt/2009/08/on-parsing-perl-5.... for details.