"Although the .NET vs. Java war is basically over for control of the Windows desktop, where .NET is sure to become the managed language of choice for new Windows desktop applications, there is a new battle brewing. That battle is for the Linux desktop. Now that Java has been open sourced under the GPL, even the most strict of the 'free software only' distributions can start bundling it and integrating it into their Linux distributions out of the box."
To view parent comment, click here.
To read all comments associated with this story, please click here.
Member since:2005-06-29
>>>Why do you need to "decode" them, and what does
>>>"decoding" even mean in this context?
--- Map<User, Set<Permission>> perms = getPerms()
It took me a few minutes to understand why the perms object needed to be placed in a map object with user as keys and a set object as permission. The next thing my brain wanted to do was draw and imagine how the data structure looked like. Next my brain started debating why a set object was used for the values of the key in the map object instead of an array of numbers. Then I had to spend some time interpreting that syntax. After about four or five minutes, I figured perms is a dictionary-like object with User object as keys and a Set of permission object as values. My mode of thinking always shifts to that whenever I read java source code.
Reading Python source code is much different, because we generally don't care about type information. It just doesn't matter. That's why if you put Java and Python source code side by side, people will almost always tell you Python is a lot more readable. And part of the reason for that is no type information and more spartan syntax.
Even in English, sentences that are overqualified with adjectives, adverbs and needless phrases are more difficult to interpret than sentences that are brief and succinct.
>>>OK, so why not make them the same color as the
>>>background? Certainly you wouldn't be "decoding"
>>>something you can't see, right? You'd have gaps, but
>>>they would hardly require "significant amount of
>>>cerebral energy" to jump over, right?
Because it's neither prudent nor practical. Java will always be the bureaucratic, bondage and discipline language and I have come to terms with that. When I'm reading Java source code, I just readjust my mode of thinking.
Member since:2005-07-06
> > Why do you need to "decode" them, and what does
> > "decoding" even mean in this context?
>
> --- Map<User, Set<Permission>> perms = getPerms()
>
> It took me a few minutes to understand why the perms object
> needed to be placed in a map object with user as keys and a
> set object as permission.
You don't need to understand the reason why it was designed the way it was, unless you plan on modifying the data structure.
[slight re-ordering]
> Then I had to spend some time interpreting that syntax.
You don't have to spend time interpreting that syntax. Once you get familiar with it (which was a very short time for me) you automatically jump over the type unless you're interested in it.
> The next thing my brain wanted to do was draw and imagine
> how the data structure looked like. Next my brain started
> debating why a set object was used for the values of the key
> in the map object instead of an array of numbers.
Now this is very enlightening. I completely understand that you can't stand any extra information if your brain automatically starts to perform complex reasoning about commonly ignorable details. Is it like that with everything? E.g., do you call your variables "a", "b", "c", etc. so that you won't be spending "cerebral energy" on needlessly reasoning why variables are named as they are?
Member since:
2005-07-06
> > Exactly when do you need to "decode" type information
> > when reading java code?
>
> Every time it appears in source code.
Why do you need to "decode" them, and what does "decoding" even mean in this context?
> > Why then do you "decode" it instead of ignoring it?
> > If you find it hard to ignore it when it's there "in
> > your face" then why not just adjust the syntax
> > highlighting to make it very faint?
>
> The answer is human nature. Distractions will always be
> distracting regardless of how hard you try to tune them out
> or ignore them.
OK, so why not make them the same color as the background? Certainly you wouldn't be "decoding" something you can't see, right? You'd have gaps, but they would hardly require "significant amount of cerebral energy" to jump over, right?