On Thu, Jul 18, 2013 at 8:51 PM, Bennie Kloosteman <[email protected]>wrote:
> Is there are another way to think about this in terms of changing the way > we develop .. eg All large apps are a pain .. and hard to maintain , it > may be valid to say that applications should be > > 1) A single statically compiled crate .. In which case you can import all > impl into the crate and fault duplicates ( or explicitly indicate which > impl to import) etc . Great for emnbeded systems , drivers etc . > 2) A collection of loosely coupled crates ( including the above ) with > mostly pass by value messages and some tools to manage sharing. > > Is the problem space this doesnt cover that large ? > Yes. It is that large. To first order, it is the entire space of production applications in the world. The idea of a language that supports loosely coupled application construction seems like a fine thing. But a language that cannot address the need to support large-scale applications has no future as a general-purpose language. Perhaps I should be clearer what I mean by "large scale". While I could point to many examples that happen to involve millions of lines of code, the *real* measure of a large scale application is an application built from components that are supplied by different organizations and are not developed on a synchronized or even cooperative basis. The identifying characteristic of these applications is that human coordination cannot be used successfully to resolve failures of modularity - or even bugs. Scale isn't primarily a technical challenge (though those can be huge). It's a social challenge that can be exacerbated by poorly designed technology. By this definition, for example, Gtk hello world is a large scale application, because it pulls in countless libraries from innumerable parties that you are effectively stuck with. Open source is *not* a cure for this. While open source means that you can hypothetically patch a bad library or subsystem, in practice your customers are not going to deploy custom-updated libraries for the sake of your fix, because doing so would break a bunch of other applications. That sort of fix can be deployed *in extremis* by cloning the library or component with a new name, but doing so creates long-term support burdens. Would I like a different approach to application structure? Sure. Right now that's not the problem I'm trying to solve. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
