>It's a big issue. It's a fundamental impediment to programming at scale.
-Its better than C and Rust allows pure C style as well as types.. there are large C and Haskell apps.... -if your target is systems programming than i think this is even less of an issue. - If your standard lib has most of the types than it becomes less of an issue ( not that Rust does well here , there standard lib is like C ) , since you wont often create the same type as the standard lib . I have been thinking about this more and more and over the years i think ALL large scale multi purpose multi team apps bascially degrade without a huge amount of work to keep it perfect ( nor is it practical to hire large amounts of gun programmers) , real life requirements and fixes always degrades the quality and when a few parts goes bad , the rest quickly follows .. Can anyone say a large ( 500K+ line) 15 year old OO app is better than a 15 year C app maybe a little but IMHO not a lot ? Most of those apps i have seen are butchered.. have static hacks , different coding techniques to suit trends eg EJB hacked out replaced with Spring etc , yet some C apps are nicely managed. Yet a "module" stays useable and maintanable for along time. , .. The more of these modules we have the better and by module i dont really mean a code lib i mean something like SOA but without the SOAP and within the app eg something thats easily discoverable , independent , sharable . COM went part of the way there ( COM had issues due lack of memory/ type safety and using the parents thread(s) MTA/STA but the concept was good) . Something with seperate binary deploment , its own thread and message pump is more independent and loosely coupled ( and also have improved cache hit rates / parralelism) . Rust Tasks with local pointers go a long way here , if you can make 50- 70% of your app independent tasks then the remainder will be smaller ( with less scope) , easier to maintain and have a smaller GC heap . Even better it has better team dynamics with less conflict on styles.. Mature small linked and dedicated libs behave almost like modules but with issues of linking eg try rebuilding a 10 year old app and get the right version of dependencies etc ( .NET assemblies are even closer ) .. . So to me the solution is less the language but more to make more smaller apps / services. Note the parralel here with the Unix suite commands while outdated ..and need of an overhaul grep , ls , awk , find , sed etc are just loosely coupled modules .. and a binary Linux 1995 command is still perfectly useable as part of a large command script. So to me the problem of programmign at scale is less the language but the app architecture and the way developers program . In such a scheme there will be many less globally visable type classes Ben On Mon, Jul 15, 2013 at 11:50 PM, Jonathan S. Shapiro <[email protected]>wrote: > On Mon, Jul 15, 2013 at 4:31 AM, Bennie Kloosteman <[email protected]>wrote: > >> Its not a huge issue in Haskel and they are making it less. Its also >> worth noting that a lot of the systems programming code uses very little in >> the way of traits.. maybe for the system program niche it will work... C# >> , PHP , JS and Java pretty much have GP programing covered anyway. >> > > It's a big issue. It's a fundamental impediment to programming at scale. > > _______________________________________________ > bitc-dev mailing list > [email protected] > http://www.coyotos.org/mailman/listinfo/bitc-dev > >
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
