When being idiomatic wears you out | Hacker News Reader

When being idiomatic wears you out

codelord.net

27 pointsabyx28 comments

Taking the gist of what he's saying ('Other languages are a lot more concise than Java') I tend to have the same feeling even with HTML when using CSS.

For example, CSS has its own syntax for classes and IDs, and once you're used to that, you can go back to HTML and it can get a little bit frustrating having to do it more verbosely.

    // CSS
    div.example, div#example {}
    // HTML
    <div class='example' id='example'>
    // What I sometimes end up doing by accident
    <div.example> / <div#example>

And the same with PHP vs JS

    // Empty object in JS
    var obj = {}
    // Empty object in PHP
    $obj = new stdClass();

Or coffee-script, Erlang, etc. vs plenty other languages

    // defining a function in the former
    func() -> ...
   // and the latter
    function() { ... }

And the languages that rely on indentation to identify code blocks vs. those that use curly braces or parentheses. The latter is a nightmare when code is nested several blocks deep and you've a sequence of:

By the same token there's probably a blog post out there about how confusing concise syntax is and how it's hard to figure out what the hell '{}' or '[]' or '?:' means compared to their more verbose counterparts.

If you are used to CoffeScript and python and feel like you're trudging through syrup when you work on HTML, you might check out SHPAML (http://shpaml.webfactional.com/). I found SHPAML to be more closely related to those two than HAML and friends: indented syntax, minimal angle brackets, etc. And per your wish:

  div.example_class
    Content here...

  p#id_example
    More content...

From the previous discussions here on HN there were many skeptics, but I have found that it has greatly reduced mental friction when I have to wrestle with HTML: the markup is fast to write, a joy to read, and I get warm, fuzzy feelings knowing that my HTML source is not drowning in markup soup.

Caveats:

1. It doesn't appear to be actively maintained. (But it is distributed as a single, readable python script that one can easily modify to taste. It spits out plain HTML, so if you ever want to ditch SHPAML, you will never be left high and dry.)

2. Doesn't include a round-trip translator. (Not terribly important to me.)

3. Like CoffeeScript and their ilk, the output line numbers don't line up with the source.

4. There are a few bits of gymnastics one has to do to conform to the grammar. For example, a link anchor must appear isolated on a new line to use the most absolutely tersest syntax. Since SHPAML passes HTML straight through, you can avoid this by added the standard markup.

5. SHPAML may not be automatically included in your workflow if you are using something like Rails or Django, but I believe there are a set of github projects that address this.

Good old fashioned HAML is regularly maintained, and appears to have been the inspiration for SHPAML:

http://haml-lang.com/

It also comes with SASS/SCSS which similarly cleans up stylesheets, and adds things like variables and mixins.

"The latter is a nightmare when code is nested several blocks deep"

It isn't if you have a decent editor.

I feel your pain.

Recently, I jumped back into the Java world to help maintain (read: re-write) an application stack. The last time I used Java, it was done with Ant and Eclipse. This time around, it appears that Maven is the idiomatic babe, and I've been trying to pick it up, to be current.

One of the selling points of Maven, apparently, is that it relies on idiomatic convention. This means that basically it tries to read your mind and do a lot of magic behind the scenes. It dances with you, but you have to know the right dance steps.

Well, let me tell you, after 2 weeks of banging my head against Maven and its sadistic verbosity monster of repository managers, goals, plugins, IDE integrations, and layers of idioms, I'm done. I've got products to ship, and if it means going back to Ant, then that's what I've got to do. I cringe when I think of all the code I could have written in that same amount of time.

Let the Java-build experts laugh at my poor, ignorant schemes.

Take a look at Gradle too.

I also fought with Maven and discarded it. Two years later I was dreaming of a different kind of build system and started building a prototype. I quit working on it and started using Maven again after I realized that the concepts I now embraced were the philosophy behind Maven.

So either it tooks me a couple years to actually grok the Maven way, or Maven got a hold of me when my mind had gotten to a particular place. Now it seems like second nature and I've got a lot of plugins that allow me to manage my complete life-cycle. It may seem funny, but to a large degree, I even use it like Puppet or Chef.

mvn clean install

What's so difficult?

The title should really be "When Java wears you out".

He seems to be more interested in complaining about the verbosity level of Java than about idiomatic code.

It could be, "When Java idioms wear you out".

Idioms, of course, vary by language, and I think Java's tend toward the excessively architected. Architecture is a fine thing at scale, but Java doesn't seem to understand that you don't want six tanks and an aircraft carrier when you're heading to the store for milk.

I've had experience with both Java and Python, so I know how you feel. At MIT, most classes in CS are taught in Python for this very reason: the idiomatic-style and overly verbose syntax of Java detracts from learning pure CS logic.

Sure, using python abstracts away a lot of things (e.g. memory management, type settings, etc.), and some might argue you have less freedom in python, but in the end, python is much closer to "logic" than java. Each line contributes to the logical flow of the program.

That being said, python is a language to write something up quick, prototype an idea, put up a simple webserver. However, when your program must scale or if you're trying to optimise for speed, you should highly consider java. The code will be more verbose, but you will pick up a tremendous speed increase.

I'm sure those of you who are hard-core Java programmers will disagree in some sense, so please leave your thoughts.

>That being said, python is a language to write something up quick, prototype an idea, put up a simple webserver. However, when your program must scale or if you're trying to optimise for speed, you should highly consider java. The code will be more verbose, but you will pick up a tremendous speed increase.

If your Python application is slow, you can throw hardware at it. That's easy & cheap.

If your Java application development cycle is slow, good luck -- you cannot just throw programmers at the problem.

It's almost always better to have fast programmers than a fast application.

> It's almost always better to have fast programmers than a fast application.

So I guess algorithms just don't matter.

I'm not sure I understand how choice of programming language affects choice of algorithm.

Selecting a language that lets you develop quickly over a "fast language" is orthogonal to selecting algorithms.

Is there a reason you believe them to be related? Or, did you repost one line of my comment without any context and expect to make a salient point?

There are a LOT of variables in that performance equation. A lot of numerical analysis happens in Python, where speed is critical (see NumPy and SciPy). Web-based applications have so many potential bottlenecks that python rarely starts as the bottleneck and there are ways around many of them (multiple processes, etc).

The problem I have with Java (and this comes with 10 years of writing appps in Java) is that it so slow. By slow, I mean slow to get anything implemented. Everything takes a long time to build. Depending on your company, that can be the biggest performance problem of them all!

I'd argue that doing numerical analysis with NumPy or SciPy isn't really "numerical analysis in Python." It's numerical analysis routines in C being called from Python.

Since the crux of the argument seems be that Java is too verbose, I wonder why he doesn't look at other JVM languages? For example, in Scala you'd write List(foo) for a singleton list. In Clojure the equivalent is '(,foo). Both languages have a decent size community and ongoing development.

I also reacted that the author mixed in Python in his Java-project when Scala is a really fine alternative.

Using Scala and Java he can write very short and readable code and use Java only when there's a performance concern or a similar reason.

People say Scala is complex and academic, but if you don't try to write your first Scala programs using every feature of the language you'll see it's a useful and likable language.

Use it a bit like you'd use C++, pick a feature-set you understand and like and be consequent with your use of parens/lack of parens.

Close, but in Clojure you'd actually write: `(~foo) or: (list foo)

This isn't 'being worn out by being idiomatic', its just that the language (Java) is too verbose, so most code in Java tends to have too many words compared to its counterpart in Ruby or Python, whether idiomatic or not.

I would recommend reviewing the other JVM languages - Clojure, Groovy, and Scala are the ones I can think of - before doing interop.

I think you'd be pleasantly surprised.

Yep, Java is wordy.

FWIW, I put together a little utility class to somewhat more shortly initialize a hash/map/dictionary in Java a while back. It's not much, but Java and .NET rule the enterprise, and you play the hand you're dealt sometimes. Hope this helps.

http://roboprogs.com/devel/2009.03.html

Share and enjoy, I guess.

I didn't know you could do this in ruby:

    Hash.new {|h,k| h[k] = []}

That makes counters easier, as in:

    x = Hash.new {|k,v| k[v] = 0}
    x['foo'] += 1

Or simply:

    x = Hash.new 0

I'm actually still confused as to the right way to do defaultdict in Ruby.

StackOverflow has three ways...

http://stackoverflow.com/questions/190740/setting-ruby-hash-...

(i) The most idiomatic way seems to be:

  (myhash[key] ||= []) << value

(ii) You can use .default

  myhash.default = []

(iii) You can use a default proc, as you note:

  myhash = Hash.new {|h,k| h[k] = []}

The problem with (i) is that it has weird results if myhash[key] has an actual value, but that value is falsy (e.g., nil or false).

The problem with (ii) is that all default values share the same empty array, so when that gets changed, they all get changed.

The one weird behavior with (iii), at least to me, is that if you access (but don't modify) myhash[k], then it creates a new key with the default value.

I actually had the converse experience yesterday.

I digged into python File nonsense trying to find a size() method, and the best explanation I got is that File doesn't have a size() method because it's not meant to designate a file but a strange mix of input/output stream/reader/writer. And since you can't really navigate into python code, I had to google quite a lot to get this explanation.

Best part of the story ? Actually I use django and it has a sane File class with a size() on it, just that it's not appearing in google when you don't send the right request (and IO is pyhton base stuff, not web stuff in my head, so I didn't put the django keyword).

The file protocol is for generic streams, but you could seek to the end and then call tell().

If you just want to know the size of a file and don't want to write to it, os.stat() will do what you want.

Perhaps I'm misunderstanding what you wanted to do, but is there a reason you can't use os.path.getsize?

http://docs.python.org/library/os.path.html#os.path.getsize

Reply on news.ycombinator.com