4 ms·

I think the author takes it a bit too far: It's possible that the Java programmers have valuable skills that we could use, despite their inability to produce ev

I think the author takes it a bit too far: It's possible that the Java programmers have valuable skills that we could use, despite their inability to produce even a trivial working program in a short amount of time. The fact that I/O management is cumbersome in Java doesn't relate to the ability of Java programmers to provide value.

cbsmith 13y ago
But doing a simply copy of stdin to stdout is actually quite easy in Java.
- PeterisP 13y ago
  Yes, but it requires knowing library functions that many Java programmers wouldn't have used for years and would need to look up; you just don't interact with console in Java-world not nearly as much as, say, in Perl-world. Doing it through, say, docs.oracle.com to check what's the stdin interface - that is quite easy, but writing it on a whiteboard from scratch would fail many Java developers.
  - cbsmith 13y ago
    > Yes, but it requires knowing library functions that many Java programmers wouldn't have used for years and would need to look up; you just don't interact with console in Java-world not nearly as much as, say, in Perl-world. People keep thinking that there are special functions involved in this solution for interacting with the console (which by itself is telling). Let's pretend it was just copying from an InputStream to a PrintStream. Those are both interfaces that most Java developers should be quite familiar with.
    - lmm 13y ago
      Why? What on earth would I ever do with an InputStream or a PrintStream, other than passing them from (say) a http library to a json-parsing library?
      - cbsmith 13y ago
        I dunnoh... reading data, writing data. Even if you only ever talk to a database JDBC has API's for accessing data through a stream. It's kind of the default way to handle networking and file data...
        lmm 13y ago
        Sure, but what am I going to do with that data? It's very rare that I'd want to twiddle the individual bits; 99% of the time a stream is an opaque handle that I pass through to an ObjectInputStream or an XML parser or write to an http response.
    - PeterisP 13y ago
      Where would your code see an InputStream? "Interacting with console" is overly specific, yes. However - the other two usecases are handling files and network sockets, and in the java world, you generally don't touch streams of bytes or lines even in those cases. The unix approach of treating most things as streams of bytes or lines tends to be abstracted - if I'm writing socket-based communications, then an InputStream exists there; but if I'm making web requests, then it's through a library where no streams are exposed. If I'm writing a logging library, then a PrintStream exists there; but if I'm doing proper logging, then again, it uses a library that doesn't expose any streams to a public interface, just the appropriate methods. Custom file formats would involve handling streams directly, but general practice in line-of-business apps nowadays is to never do that - you just [de]serialize to json/xml/something else standartized; and again that's done by a library that uses streams but doesn't expose them. These things are trivial to do in java, but what I'm saying is that java is very often used in large codebases that don't touch raw streams at all. Students in java lessons use InputStream&PrintStream, but after starting work, promptly forget what the methods are called as they're used rarely.
      - cbsmith 13y ago
        > However - the other two usecases are handling files and network sockets, and in the java world, you generally don't touch streams of bytes or lines even in those cases. I think you live in a pretty rarified Java world. > The unix approach of treating most things as streams of bytes or lines tends to be abstracted - if I'm writing socket-based communications, then an InputStream exists there; but if I'm making web requests, then it's through a library where no streams are exposed. Except if you want to handle large amounts of data efficiently, you end up using streams to read and or write those web requests. > Custom file formats would involve handling streams directly, but general practice in line-of-business apps nowadays is to never do that - you just [de]serialize to json/xml/something else standartized; and again that's done by a library that uses streams but doesn't expose them. ...and I guess you never have to debug anything or understand what is happening underneath? > Students in java lessons use InputStream&PrintStream, but after starting work, promptly forget what the methods are called as they're used rarely. Then why do you think they teach 'em? Aren't all subsequent concepts built on top of them?

cbsmith 13y ago

But doing a simply copy of stdin to stdout is actually quite easy in Java.

PeterisP 13y ago
Yes, but it requires knowing library functions that many Java programmers wouldn't have used for years and would need to look up; you just don't interact with console in Java-world not nearly as much as, say, in Perl-world. Doing it through, say, docs.oracle.com to check what's the stdin interface - that is quite easy, but writing it on a whiteboard from scratch would fail many Java developers.
- cbsmith 13y ago
  > Yes, but it requires knowing library functions that many Java programmers wouldn't have used for years and would need to look up; you just don't interact with console in Java-world not nearly as much as, say, in Perl-world. People keep thinking that there are special functions involved in this solution for interacting with the console (which by itself is telling). Let's pretend it was just copying from an InputStream to a PrintStream. Those are both interfaces that most Java developers should be quite familiar with.
  - lmm 13y ago
    Why? What on earth would I ever do with an InputStream or a PrintStream, other than passing them from (say) a http library to a json-parsing library?
    - cbsmith 13y ago
      I dunnoh... reading data, writing data. Even if you only ever talk to a database JDBC has API's for accessing data through a stream. It's kind of the default way to handle networking and file data...
      - lmm 13y ago
        Sure, but what am I going to do with that data? It's very rare that I'd want to twiddle the individual bits; 99% of the time a stream is an opaque handle that I pass through to an ObjectInputStream or an XML parser or write to an http response.
  - PeterisP 13y ago
    Where would your code see an InputStream? "Interacting with console" is overly specific, yes. However - the other two usecases are handling files and network sockets, and in the java world, you generally don't touch streams of bytes or lines even in those cases. The unix approach of treating most things as streams of bytes or lines tends to be abstracted - if I'm writing socket-based communications, then an InputStream exists there; but if I'm making web requests, then it's through a library where no streams are exposed. If I'm writing a logging library, then a PrintStream exists there; but if I'm doing proper logging, then again, it uses a library that doesn't expose any streams to a public interface, just the appropriate methods. Custom file formats would involve handling streams directly, but general practice in line-of-business apps nowadays is to never do that - you just [de]serialize to json/xml/something else standartized; and again that's done by a library that uses streams but doesn't expose them. These things are trivial to do in java, but what I'm saying is that java is very often used in large codebases that don't touch raw streams at all. Students in java lessons use InputStream&PrintStream, but after starting work, promptly forget what the methods are called as they're used rarely.
    - cbsmith 13y ago
      > However - the other two usecases are handling files and network sockets, and in the java world, you generally don't touch streams of bytes or lines even in those cases. I think you live in a pretty rarified Java world. > The unix approach of treating most things as streams of bytes or lines tends to be abstracted - if I'm writing socket-based communications, then an InputStream exists there; but if I'm making web requests, then it's through a library where no streams are exposed. Except if you want to handle large amounts of data efficiently, you end up using streams to read and or write those web requests. > Custom file formats would involve handling streams directly, but general practice in line-of-business apps nowadays is to never do that - you just [de]serialize to json/xml/something else standartized; and again that's done by a library that uses streams but doesn't expose them. ...and I guess you never have to debug anything or understand what is happening underneath? > Students in java lessons use InputStream&PrintStream, but after starting work, promptly forget what the methods are called as they're used rarely. Then why do you think they teach 'em? Aren't all subsequent concepts built on top of them?