Eric questions the meaning of "Loosely Typed"

I think that there are two separate issues here.

Required Declarations

This corresponds to the "Option Explicit" feature added to VB3, and which still exists in VB.NET. You can choose for a particular file whether to require variable declarations or not. This feature helps catch bugs at compile time where you accidentally misspell the name of some symbol. Consider the following code.

Class Person

    Private name

Private age As Double

Private money As Decimal = 100.0

End Class

The name field is declared, but no type is specified, whereas the age field is both declared and given a type, and money is declared, given a type, and an initial value.

Required Type

This somewhat corresponds to the "Option Strict" feature in VB, except that the feature enables quite a few other behaviors that are somewhat related, such as the ability to implicitly convert between Strings and Numbers. If I have "Option Strict Off" and "Option Explicit Off" at the top of a VB file, then the following will compile.

to = "Hello"

to = to.Length

to = to + too

This shows one problem with making variable declarations optional, because I was able to misspell "to" as "too" in the last line, and the compiler couldn't check it. This is why I like to be able to specify "Option Explicit On" in VB even when I set "Option Strict Off". I prefer to get a little red squiggly underline of "too" rather than waiting to catch this in a unit test.

Inferred Type

VB9 and C#3 add another twist to this issue, because they now support type inference. With this feature, you can still get strong type safety, but without the hassle of explicitly stating the type. Take the following C# example:

var name = "Justin";

var len = name.Length;

name = 42.0;

In this example the first line is exactly equivalent to "string name = "Justin";", and the third line will be a compile time error, because the inferred type of name is String, which doesn't support implicit conversion from Double.

The only thing I don't like about the current implementation of the type inference feature, is that it's done by the compiler. What I'd really like is for the IDE to display the name of the inferred type, and perhaps let me modify its choice without making the type "sticky". Maybe the IDE could automatically display the above as "var string name = "Justin";", where "string" is non-editable and mutates itself automatically to match changes to the inferred type when refactoring.

Strong vs. Loose

These terms are currently pretty ambiguous. I think the term Strong should only mean that at runtime, the code will result in an error if you attempt an operation that is not known to be safe. Examples might include:

• Calling a derived-type method on a base reference
• Implicit numeric conversions
• Calling a method that is unknown on the current reference

The VB "Option Strict Off" setting basically throws "Loose Typing" in with "No Type Declaration Required", and makes the following code legal.

Class A

Public Sub Foo()

End Sub

End Class

Dim v as Object

v = new A()

v.Foo()

v = "42"

v += 1

Assert(v.Equals(43))

This is true Loose Type behavior, and can be useful in certain limited contexts. However, I wish you could have finer-grained control over the VB options so that I could retain some type safety while still disabling the need for explicit type specifications. I guess some of the need for this is obviated by the type-inference feature.

Dynamic vs. Static

This seems to clearly refer to whether type information is known at compile time. Static Typing means that all type errors short of invalid explicit casts will be caught at compile time.

Conclusion

So I guess I'm a little unclear about what kind of type system is found in Ruby. If it claims to be "Strongly Typed" then that's pretty ambiguous. Is there a summary of exactly which operations result in an error vs which are implicitly allowed? What value does "Strongly Typed" provide at runtime? If you're going to wait until runtime to detect errors, then why not just use "Loosely Typed"?

A recent Coding Horror post got me thinking again about C# vs. Visual Basic. As you know, I myself think that VB is probably the best general purpose managed language available right now, so I thought I'd add my $.02 to the discussion.

VB vs. C# is like Coke vs. Pepsi

I don't think this analogy holds up, because it doesn't take into account the complexities of the situation. I believe that there are real substantive differences that make VB a better tool for writing programs than C#. While it's true that tools like CodeRush and Resharper can greatly improve the C# experience, they still fall short of what's theoretically possible from a VB-based toolset, because, no matter what you do to C# (or Java or any other C-style language) you will always be missing the three key features that make VB better. Namely the Readable Keywords, Line-Orientation, and Case-Insensitivity I detailed in a previous post.

I'm not claiming VB/Visual Studio is better in every way than Eclipse/Java, IntelliJ/Java, Resharper+VS2005/C#, etc. I'm just saying that if all these tools were refined to their highest potential, I would like VB best because it has a better foundation. VB is currently missing some major features such as the ability to automatically handle Imports, that make it difficult to compare it favorably to these other tools.

Case Insensitivity is Right and Case Sensitivity is Wrong

I hope that most VB users would agree that it's not the Case Insensitivity of VB that we actually like. In fact, at the language level I believe it's a mistake for VB to be Case Insensitive. What people really like about VB is that most of the time it's not the author's responsibility to worry about case. The feature that we really like is that the IDE will fix the case to match the declaration or keyword. I think a better way to implement this feature would be to require Case Hyper-Sensitivity at the language level which would disallow multiple symbols in scope that differ only by case.

No competent VB programmer would ever want something like "sySTeM.cONsolE.WRitELINE(foo)" to compile. We just think it's ridiculous that C# and Java IDE editors make us constantly contort our hands with two-key combinations. This only slows down our typing, causes hand cramps, and makes us 2% (est.) less happy. For those of you who've grown accustomed to Resharper, IntelliJ or Eclipse, this is exactly equivalent to many of the features you would miss if switching to Notepad/Java. In fact, my first impression using IntelliJ was that somebody copied 20% of the good features from VB, and then thought of a bunch of new must-have features that I didn't even consider. The problem is that none of the IDE vendors are really doing a good job of incorporating the best features of their competition. What would be ideal is a JetBrains/VB based on Mono, or better yet a completely new language that takes the important ideas of VB while stripping away the too-long keywords, and other features that I dislike in VB. (Overall I like the readable keywords in VB, but some are just too much. )

Strongly Typed

The Ruby and Python movements have convinced many people that they really want a loosely typed language. Of course, one of the great things about VB is that you can choose within a given file whether you want strong or loose typing, but I'm not convinced that most people even truly want loose typing in most cases. What people really seem to like is not having to waste time keying in all the type information. They like the flexibility that the tool can just figure it out.

You can get most of this benefit without having to give up the performance and other benefits of a strongly typed language. Upcoming versions of C# and VB will have a feature called Type Inference, wherein the language will simply figure out the type from the context in which it is used. For instance, in C# 3.0 I can write "var x = foo.ToString();" and C# will infer that the type of x is String. One thing that I don't like about the new VB/C# type-inference feature is that it seems to be implemented at the language level.

Language vs. IDE

I believe that the single most important key to the future of programming is the realization that Programming Languages as classically defined are an idea whose time has passed. Tools like VB, IntelliJ, and Eclipse have blurred the line between IDE and language, but the real key is realizing that the language side of the line is no longer needed at all. In fact, it's a huge detriment. This is the primary reason why I can't really get excited about any new language such as Ruby. I see these all as vestiges of a legacy mode of thinking.

Multi-Language

One of the benefits of .NET was supposed to be that you could use any language that you like. However, as Jeff has noticed this dream has not been realized. The problem is that we're not really free to choose any language we like, because the fact is that most code is going to have to be maintained and written by multiple people each with different preferences. Jeff's experience is that most people have settled on C# as the de-facto .NET standard language despite the superiority of VB. Over time he seems to have been worn down by the C#-zealots, and their fanatical devotion to a language attuned to those with masochistic tendencies, but I have to believe that he still realizes deep-down that he knows a better way.

The fundamental problem with a multi-language platform like .NET is that what we really want is the ability to maintain the same code in multiple languages. If I write a class in VB, then someone else needs to be able to maintain that class in C#, Python, or Ruby without having to translate the language. The key is that the code itself can't know what language it's written in, and that can only happen when we get rid of this silly old-fashioned notion of parsing languages written as text files.