You're looking at Less Wrong's discussion board. This includes all posts, including those that haven't been promoted to the front page yet. For more information, see About Less Wrong.

Daniel_Burfoot comments on Open thread, Jan. 12 - Jan. 18, 2015 - Less Wrong Discussion

6 Post author: Gondolinian 12 January 2015 12:39AM

You are viewing a comment permalink. View the original post to see all comments and the full post content.

Article Navigation

Comments (155)
Tags: open_thread

Comments (155)

You are viewing a single comment's thread. Show more comments above.

Comment author: Daniel_Burfoot 15 January 2015 03:15:35PM *  0 points [-]

(e.g. be precise and concise, carefully encapsulate state, make small reusable modular parts which are usually pure functions, REPL-driven development, etc. etc.)

I am a Java programmer, and I believe in those principles, with some caveats:

  • Java is verbose. But within the constraints of the language, you should still be as concise as possible.
  • Encapsulation and reusable modular design is a central goal of the language and OO design in general. I think Java achieves the goal to a significant degree.
  • Instead of using a REPL, you do edit/compile/run loops. So you get two layers of feedback, one from the compiler and the other from the program itself.
  • Even though Java doesn't emphasize functional concepts, you can still use those concepts in Java. For example, you can easily make objects immutable just by supplying only a constructor and no mutator methods (I use this trick regularly).
  • Java 8 is really a big step forward: we can now use default interface methods (i.e. mixins) and lambda syntax with collection operations.

I don't understand how to like it yet

My feeling towards Java is just that it's a very reliable old workhorse. It does what I want it to do, consistently, without many major screwups. In this sense it compares very strongly to other technology tools like MySQL (what, an ALTER TABLE is a full table copy? What if the table is very large?) and even Unix (why can't I do some variant of ls piped through cut to get just the file sizes of all the files in a directory?)

Comment author: jkaufman 18 January 2015 12:18:25AM 1 point [-]

why can't I do some variant of ls piped through cut to get just the file sizes of all the files in a directory?

Nerd sniped. After some fiddling, the problem with ls | cut is that cut in delimiter mode treats multiple spaces in a row as multiple delimiters. You could put cut in bytes or character mode instead, but then you have the problem that ls uses "as much as necessary" spacing, which means that if the largest file in your directory needs one more digit to represent then ls will push everything to the right one more digit.

If you want to handle ls output then awk would be easier, because it collapses multiple successive delimiters [1] but normally I'd just use du [2]. Though I have a vague memory that du and ls -l define file size differently.

(This doesn't counter your point at all -- unix tools are kind of a mess -- but I was curious.)

[1] ls -l | awk '{print $5}' [2] du -hs *

Comment author: Douglas_Knight 28 January 2015 08:46:46PM 0 points [-]

Your vague memory is probably that ls -l gives file size, while du give "disk usage" - the number of blocks used. On my computer the blocksize is 4k, so du only reports multiples of this size. (In particular, the default behavior is to report units of historical blocksize, so it only reports multiples of 8.)

A huge difference that I doubt you forget is how they define the size of directories - just metadata vs recursively. But that means that du is expensive. I use it all the time, but not everywhere.

Powered by Reddit Powered by Reddit