Variable Declarations
Jef Atwood has discovered the implicit variable type declaration in C#:
BufferedReader br = new BufferedReader (new FileReader(name));Who came up with this stuff?
Is there really any doubt what type of the variable br is? Does it help anyone, ever, to have another BufferedReader on the front of that line? This has bothered me for years, but it was an itch I just couldn't scratch. Until now.
Actually, there is a question about the type of br - it could be a BufferedReader or it could be any superclass of BufferedReader and sometimes that distinction is important. The most common example of this is in the collections API:
Map data = new HashMap();
Why not just call it a Map? Well let’s say you later want the map to be sorted, then it simply becomes:
Map data = new TreeMap();
And none of your other code needs to change. You’re guaranteed to not be using any HashMap specific methods because the compiler won’t let you and it’s quite clear that the intent is to work with a Map instead of specifically a HashMap. Saving a few extra characters really doesn’t give any benefit for either reading or writing.
What I find most fascinating about this, is that the example touches on the most verbose, confusing and frustrating (yet powerful) part of writing in Java - the IO library, and then complains about the type system. Here’s the real problem in that line of code:
new BufferedReader(new FileReader(name));
Do you have any idea how many people forget to wrap the FileReader in a BufferedReader and destroy the performance of IO (and then blame Java)? Why isn’t that something simple like:
Reader reader = new File(name).read();
Call the method name wantever you want and there’s a bunch of variants on this, but just provide a single method that does what the programmer almost always wants to do. If unbuffered, serial access to a file is ever desirable (when???) then provide an additional method that takes a boolean to let you turn off buffering but just make it simple.
Why people are obsessed with type systems as the harbinger of productivity is just beyond me - it’s the design of the libraries stupid! That’s why PHP feels so messy to write. That’s why Java feels so verbose to write. That’s why ruby feels so easy to write - it provides so many of these really handy shortcuts. No amount of syntactic sugar or changes to the type system is going to change that, because most of your code is dealing with the libraries, not the syntax of the language.
June 23rd, 2008 at 9:22 am
It comes down to:
“programming to an interface, not an implementation”
I’ll agree that the Java IO library is a bit cumbersome - basic file IO shouldn’t have so many ways to do it wrong. For such simple operations, the syntax (language and library) should be elegant. I mean - cumbersome file IO code is one reason why people prefer databases to filesystems.
The flipside is that Java IO gives you lots of flexibility and extensibility.
To many it doesn’t make sense to instantiate and wrap and wrap. However, once you learn the Decorator pattern, it makes a bit more sense. Serial access to a file may be used if I want to write a replacement for BufferedReader.
Without the declared type, programming to an interface, or Decorator become less elegant.
> Why not just call it a Map? Well let’s say you later want the map to be sorted, then it simply becomes….
Yep. A key benefit of programming to an interface, in a strongly-typed language. Let’s look at how this works in other language types:
In a typeless or dynamically-typed language, you can still change the implementation without changing the declared type, so long as the code still meets the new interface - this is more dangerous, though, as the errors aren’t found compile-time.
In a statically-typed language which supports implicit types in variable declaration (eg F#), you can change the implementation type without changing the declared type… however, issues will be picked up by the compiler, as types are still static. This might be a candidate for a “best of both worlds”.
My preference is definitely with statically-typed language, for this type of issue.
I’ll agree that the libraries have a bigger impact on the ease of use of a language… but the impact of the language itself shouldn’t be underestimated. Same goes for ide/tool support. To me, they would have to be the 3 big factors in a language’s ease-of-use.
Another thing to consider is that the distinction between language and library is blurred. For a given feature, one language may implement it in library and another may make it native syntax. Also, for a given task, you use a mix of language and library. The syntax of the language impacts how elegant the library usage is. The language’s syntactic strengths drive library development, and, as such, the combination of both impacts the usability, as does each separately.
June 24th, 2008 at 6:02 am
If you’re going to program to an interface to an implementation you effectively need static typing and a declared type - otherwise you’re just getting lucky. You can keep it in mind and do your best etc, but it’s easy to slip up and get it wrong and then you can have a fair bit of work to back out that slip up depending on exactly what it lead to. For example if you think you have an ArrayList instead of Collection and thus use algorithms that require random access instead of iterating you’ve got large chunks of code to rewrite. You can only guarantee that won’t happen if you have strict, explicitly declared type checking.
That’s not to say strictly typed languages are better, just that if you’re dealing with strict typing you may as well get the benefits, saving a few characters and giving up that kind of guarantee is kind of silly.
As for language vs library, certainly the language has an impact on the library, but not to the extend necessarily expect. You can generally find ways to make an API highly productive in any language, Java’s big problem is that it typically doesn’t try to make things concise. It’s simple to have all the power of the Java IO APIs but still provide a simple method that reads from standard in or a file. Similarly even though Java doesn’t have regex built into the language, it’s trivial to provide simple utility methods like String.replaceAll() which is just as good as the // syntax used by many languages that have native support.