|
Re: A (Brief) History of Object-Functional Programming
|
Posted: Dec 9, 2009 6:39 AM
|
|
> Haskell is mind-bogglingly well architected, but it won't > run on existing virtual machines,
Why does that matter? Haskell has its own runtime environment.
> or make use of OSGi for runtime management,
I have no idea if such a beast exists for Haskell, but remote installation/uninstallation/start/stop/update of services may not be that difficult; certainly no more difficult than native services, since Haskell code is compiled to native executables.
But why is this important? I don't know anyone that uses OSGi.
> or be amenable to existing techniques > that the operations team have already learned for dealing > with Java deployments.
Maybe these techniques are redundant with Haskell.
> The barrier is in the ecosystem,
Haskell, despite what you or I think, has a lot of libraries.
> and the steep steep learning curve
It's actually easier than Java.
> and the support infrastructure,
I think the support infrastructure argument is overestimated for its importance.
>and the available optimised database connectors
I think Haskell can use the native ones. I have no idea if there are connectors in Haskell.
> and vendor support. Everything that's needed for a large-scale > enterprise deployment basically. The actual language > syntax is a minor consideration.
You have a point, but the things you mention are not that critical for most businesses. It's not that every business has that big needs.
> Compatibility is considered paramount. Although this has > caused some challenges in designing the language, it must > surely also be the greatest strength in terms of > encouraging adoption.
I think it depends on the task at hand. If you write a module that only communicates with other modules via messages, then you can do it in any language. In this case, the language is more important than the infrastructure.
|
|