Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

A lot of people criticize Fog Creek for writing their own compiler, but I think it's a good example of working smarter rather than harder to solve a problem they had at the time. I think that companies which apply sheer brute force to rewrite the same app in Objective-C and Java to target the popular mobile platforms could learn from this.

I wonder to what extent the generated C# code depends on C#'s dynamic typing option. I ask because the original VBScript was certainly dynamically typed. So by the end, to what extent was Wasabi statically typed, through explicit type declarations or type inference? And how much did the compiler have to rely on naming conventions such as Hungarian notation?



Wasabi is statically typed — `dynamic` wasn't added to C# until C# 4, in 2010, so the implementation choice was between static types and a LOT of reflection.

The type inferencer was an attempt to make it as easy to declare variables and functions as it was in VBScript. Of course, you could explicitly declare types as well.

The one place Wasabi depends on Hungarian notation as a type heuristic is when reading from an ADO RecordSet (which happens quite frequently in FogBugz). The column name determines which type the returned object will be cast into.


How much of the FogBugz code had to be modified to accommodate static typing, even with global type inference? In other words, was there much code that truly depended on dynamic typing? My guess is that Joel and his team were more disciplined about this than I've been. (Yes, I'm entertaining the idea of writing a custom compiler from a dynamically typed language, in my case Lua, to a statically typed one, probably C++ with heavy use of reference counting.)


Very little, if I remember correctly. The FogBugz coding conventions meticulously follow Apps Hungarian (http://www.joelonsoftware.com/articles/Wrong.html), which means that the type of a variable should not change.


> I think that companies which apply sheer brute force to rewrite the same app in Objective-C and Java to target the popular mobile platforms could learn from this.

I've been on that end and it really sucks, especially if you don't have the manpower to keep all platforms and versions in sync feature-wise. And there even was a C++ core that was identical across three platforms and yet there still was feature disparity and neglect.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: