Ryan Tomayko projects what might be necessary to get better late-bound languages acceptance in early-bound organizations...
I think we need something to break through on one of the VMs if we're ever going to move this into the enterprise. There's no way I could bring Python into my place of business on any serious level. This really comes down to it not being blessed as Enterprise Class (blech!) by Sun. It seems we need the VM to get in the door and then maybe we can just move quietly toward CPython with a Java/CLR bridge?Maybe. The IT industry seems kind of in a "standardization" phase still, following the irrational exhuberence of the "anything goes" phase of the dot.com days. That can translate into the desire to choose one language to standardize on developer resources. I'm not sure getting CPython in would be any more difficult than Jython or IronPython.
We used to have these things called skunkworks. Do such things exist anymore where you can demonstrate value before being judged prematurely on cost? I think maybe but you may need radar detectors along the way.
3 comments:
Yes, I agree. I have tried Haskell and ML, but not for anything more than some toy programs. I've not found an advantage to them over what I consider simpler and more proven languages, but I am willing to listen to the people who are paving those paths.
Personally I'm rather conflicted about this. On one hand I'd ideally prefer something entirely static - in my personal experience many classes of bugs simply doesn't occur if you do as much as possible up to and including compile time.
On the other hand, I really love the flexibility I can gain from late binding.
What I'd like to see is more work on type safety in dynamic binding, including how to handle additional failure modes.
Static typing for me, is about predictability (and I'm all for type inference as an option btw.), as is any other method for limiting the runtime processing of an application (such as static linking) that reduces the number of states an application process can be in.
But that doesn't mean there aren't compelling cases for dynamic typing, and I think the key is to blend the two approaches, so that you use static typing (preferrably with type inference) wherever there is no reason for the type to be undetermined at compile time, but where dynamic typing can be used where it matters.
As for Haskell and ML I'm in much the same boat - there are aspects I love about them, such as being able to enforce single assignment, closures, lazy evaluation and type inference.
What I don't like about them is their "alien characteristics". That is, that they're functional ;) I'd love to see some of these capabilities and in particular type inference make it into more traditionl languages.
"On one hand I'd ideally prefer something entirely static - in my personal experience many classes of bugs simply doesn't occur if you do as much as possible up to and including compile time."
I'm conflicted about this because the time between code complet, compilation complete, and testing complete in the languages and style I use is well under one second. There is not much any kind of type checking can do in that short cycle.
I do want to incorporate more systems analysis like model checking, etc. I would be willing to decorate and generate code in some circumstances to get better understanding of concurrency, etc.
Post a Comment