4 ms·

Nope, Had to look at the javadoc for those two classes too. I guess you don't memorize this stuff when Ctrl+Space in eclipse constantly tells you what you need.

by lawl 13y ago

Nope, Had to look at the javadoc for those two classes too. I guess you don't memorize this stuff when Ctrl+Space in eclipse constantly tells you what you need. And it probably doesn't help that the java.io package is also really horrible. read() returns byte[] but print() accepts only char[], so you'd need to cast or use write() which accepts byte[], but you need to pass it an offset and the length too: write(byte[] buf, int off, int len). Eh, that's just stupid. I'm happy eclipse tells me that stuff... If I had to do this at an interview in Java, from the top of my head I'd probably ask if it's okay if I use Apache Commons IOUtils and try to IOUtils.copy(). But again, the article talks about language of your choice. I was just a bit shocked when I was able to write this in C and perl without autocomplete even if I practically never use C or perl. Makes me wonder if it's really the IDE's that make you not memorize the standard library. Or if Java's standard library is really that horrible. I think it's a combination of both. Or maybe because I usually don't deal with this stuff in Java while implementing boring business logic. Also, C: #include <stdio.h> int main(){ char strbuf[1024]; while(fgets(strbuf,1024,stdin)){ puts(strbuf); } } Perl: perl -e 'while($a=<>){print $a}'

raiph 13y ago
Fwiw, as pointed out elsewhere you can simplify the Perl 5 to: while (<>){ print }; Fwiw, in Perl 6, the canonical incantation is: .say for lines where: * thing.method calls method 'method' on thing (where thing is an object, or something that can behave as an object, which, in Perl 6, is any value). In the code above the 'say' method prints its arg, followed by a \n, to stdout. * If thing isn't specified, the current topic (aka "it" aka $_) is assumed, so .say is being called on "it". * 'for' sequentially sets the current topic ("it") to each of the items in the following list of things. * 'lines' lazily reads lines (next chunk of text up to the next \n) from somewhere. The default somewhere is stdin. A simpler incantation is: slurp.say which slurps all of stdin as a list of lines and then says them all, but slurp isn't lazy, so it'll wait till it's read all of your stdin before writing any of it to stdout.
cbsmith 13y ago
> Had to look at the javadoc for those two classes too. Well, I'm a little surprised, but I wouldn't begrudge an interviewee a peek at the javadocs. You should be pretty familiar with the API's and how to use them correctly though. > read() returns byte[] Actually, it returns an int. You're thinking of read(byte[]) I think... but it also returns an int. > print() accepts only char[], so you'd need to cast or use write() which accepts byte[], but you need to pass it an offset and the length too: write(byte[] buf, int off, int len). Eh, that's just stupid. I'm happy eclipse tells me that stuff... Eclipse won't tell you that a) you shouldn't use print(char) because you aren't trying to format a character. The offset & length is a pretty common Java idiom, and actually important for getting this right. > If I had to do this at an interview in Java, from the top of my head I'd probably ask if it's okay if I use Apache Commons IOUtils and try to IOUtils.copy(). That's perfectly legit.. if you remember to flush the output stream. > But again, the article talks about language of your choice. I was just a bit shocked when I was able to write this in C and perl without autocomplete even if I practically never use C or perl. The C code is fine enough, though doesn't correctly detect when an error occurs. The perl code is going to potentially chew up a lot of RAM with that input. I agree though that Perl & C make this pretty easy to do right, and Java (along with a surprising number of higher level languages) doesn't.

by lawl 13y ago

raiph 13y ago

Fwiw, as pointed out elsewhere you can simplify the Perl 5 to: while (<>){ print }; Fwiw, in Perl 6, the canonical incantation is: .say for lines where: * thing.method calls method 'method' on thing (where thing is an object, or something that can behave as an object, which, in Perl 6, is any value). In the code above the 'say' method prints its arg, followed by a \n, to stdout. * If thing isn't specified, the current topic (aka "it" aka $_) is assumed, so .say is being called on "it". * 'for' sequentially sets the current topic ("it") to each of the items in the following list of things. * 'lines' lazily reads lines (next chunk of text up to the next \n) from somewhere. The default somewhere is stdin. A simpler incantation is: slurp.say which slurps all of stdin as a list of lines and then says them all, but slurp isn't lazy, so it'll wait till it's read all of your stdin before writing any of it to stdout.

cbsmith 13y ago

> Had to look at the javadoc for those two classes too. Well, I'm a little surprised, but I wouldn't begrudge an interviewee a peek at the javadocs. You should be pretty familiar with the API's and how to use them correctly though. > read() returns byte[] Actually, it returns an int. You're thinking of read(byte[]) I think... but it also returns an int. > print() accepts only char[], so you'd need to cast or use write() which accepts byte[], but you need to pass it an offset and the length too: write(byte[] buf, int off, int len). Eh, that's just stupid. I'm happy eclipse tells me that stuff... Eclipse won't tell you that a) you shouldn't use print(char) because you aren't trying to format a character. The offset & length is a pretty common Java idiom, and actually important for getting this right. > If I had to do this at an interview in Java, from the top of my head I'd probably ask if it's okay if I use Apache Commons IOUtils and try to IOUtils.copy(). That's perfectly legit.. if you remember to flush the output stream. > But again, the article talks about language of your choice. I was just a bit shocked when I was able to write this in C and perl without autocomplete even if I practically never use C or perl. The C code is fine enough, though doesn't correctly detect when an error occurs. The perl code is going to potentially chew up a lot of RAM with that input. I agree though that Perl & C make this pretty easy to do right, and Java (along with a surprising number of higher level languages) doesn't.