I do respect that you had a huge (and effective) code base in ASP that you (for very valid business reasons) didn't want to rewrite from scratch. I understand that each of the decisions you have made have probably made you successful and profitable - and in your shoes I probably would have done something similar. From your point of view, I completely understand that your choices were to do a complete rewrite (which was obviously unacceptable), or to come up with these sort of hackish workarounds.
However, I think you have to understand that as a hypothetical programmer thinking about working at Fog Creek, my choice is to work on your large legacy code base in (what appears to me to be) a not very pleasant language - or work on fun little 3 month AI projects in whatever language I choose (which is roughly what I do now). The fact that your compiler infers type information from a variable's name is an ugly hack - and frankly scares me (not only itself, but also more than a little about other design decisions you made). The hoops you guys had to jump through with Wasabi to do metaprogramming would annoy me - I'd rather focus on the fun stuff.
I recognize that, as a business, you made good decisions. But do you understand why I, as a programmer, would not want to work with those sort of technologies?
Oh, and for what it's worth, my language has all the features you've mentioned. For example, we used Parenscript (http://common-lisp.net/project/parenscript/) at my last job - it's a subset of common lisp that can be compiled to Javascript and runs on either the client or server.
Also - sorry about the 'Gouge my eyes out' bit. I meant it to be a bit of funny hyperbole, but guess I failed to convey that properly (humor is hard on the internet). Fogcreek, in my mind, would definitely be above the average Java or .Net shop, but probably below a few fun research labs, prototyping contractors, or small startups.
It doesn't infer type information from variable names. (An old version had to do that in one particular case to work around a VBScript ambiguity). It does type inference like Haskell, from the actual types that are assigned to things, so DIM a=9 means a must be an integer.
Again, you're assuming a lot about Fog Creek without a lot of information. The dev team here is extremely happy to be working at Fog Creek. In 8 years only one developer ever left, because he had to move away. Your theory that Fog Creek is "not a very fun environment" seems utterly at odds with what everybody else tells us, which is that they would give their left ear to work here.
By "not a very fun environment" I was referring to the Wasabi programming environment, not the people/social/office environment. Sorry for the ambiguity. I've read most of your essays, and the FogCreek environment seems amazing - you've clearly done a wonderful job with that.
And you're right - I am inferring a lot from not very much information. But, imagine that I'm a hypothetical programmer that was considering working at Fog Creek (I'm probably not up to your standards, but bear with me ;-)). You publicly stated that your compiler infers type information from variable names. That, in conjunction with some other worrisome things I've read about Wasabi, might be enough to push me some other way.
Most of the other places I'd consider working have decent enough benefits (salary, offices, food, etc) that they really aren't a deciding factor. When I look for a job, my primary concern is how interesting/fun the problems/technologies are. As long as all the other stuff is decent, I kind of disregard it.
var in C# is only allowed for local variables, which means you can easily infer the type by analysing the assigment expression, which will always depend on known types. For example method parameters are always explicitly typed.
Haskell style type inference is more tricky, since it also tries to infer the type of function signatures from the different contexts where the function is called. This can lead to circular type dependencies.
"Easily"? I suspect that since C#3 offers lambda expressions that you'd need to use something close to (although probably different from) full H-M inference... in fact, it seems like it may need to be nearly as complicated as Scala's type inference, which is saying something. =)
I do respect that you had a huge (and effective) code base in ASP that you (for very valid business reasons) didn't want to rewrite from scratch. I understand that each of the decisions you have made have probably made you successful and profitable - and in your shoes I probably would have done something similar. From your point of view, I completely understand that your choices were to do a complete rewrite (which was obviously unacceptable), or to come up with these sort of hackish workarounds.
However, I think you have to understand that as a hypothetical programmer thinking about working at Fog Creek, my choice is to work on your large legacy code base in (what appears to me to be) a not very pleasant language - or work on fun little 3 month AI projects in whatever language I choose (which is roughly what I do now). The fact that your compiler infers type information from a variable's name is an ugly hack - and frankly scares me (not only itself, but also more than a little about other design decisions you made). The hoops you guys had to jump through with Wasabi to do metaprogramming would annoy me - I'd rather focus on the fun stuff.
I recognize that, as a business, you made good decisions. But do you understand why I, as a programmer, would not want to work with those sort of technologies?
Oh, and for what it's worth, my language has all the features you've mentioned. For example, we used Parenscript (http://common-lisp.net/project/parenscript/) at my last job - it's a subset of common lisp that can be compiled to Javascript and runs on either the client or server.
Also - sorry about the 'Gouge my eyes out' bit. I meant it to be a bit of funny hyperbole, but guess I failed to convey that properly (humor is hard on the internet). Fogcreek, in my mind, would definitely be above the average Java or .Net shop, but probably below a few fun research labs, prototyping contractors, or small startups.