Everything Kristopher says is true, but I think he is being a little hard on Decca. Decca was an *undergraduate* thesis project. By the standards of thesis projects, it's a very nice piece of work.
To answer the original question, Eli Gottlieb and I have exchanged some email about his project. I think that Decca made some interesting choices and missed some others. Some of the things that he missed, in my opinion, are a function of inexperience. To build a good systems language, you have to be both a systems person and a languages person. It's very hard for someone that early in their career to be both. Heck. It's hard when you've been doing both for years, which is why we tried hard to co-develop BitC and Coyotos. And we *still* got some things wrong. I do not have the impression that the Decca project is continuing, so I doubt that it will turn out to be the winner in the safe systems programming space. shap On Sat, Jun 9, 2012 at 10:55 AM, Kristopher Micinski <[email protected] > wrote: > You can probably condense what I said to simply this quote from the > Google project page: > > "A malloc implementation is coming soon." > > :-) > > On Sat, Jun 9, 2012 at 1:53 PM, Kristopher Micinski > <[email protected]> wrote: > > On Sat, Jun 9, 2012 at 7:51 AM, Srujan Kotikela <[email protected]> > wrote: > >> Hi, > >> > >> I recently came across Deca. Sounds like an interesting programming > >> language. It's comparison to BitC comes from the fact that it tries to > solve > >> the same problems as BitC: > >> > >> Systems programs operate in constrained memory. > >> Systems programs are strongly driven by bulk I/O performance. > >> Performance and data representation matter. > >> Stateful programming is mandatory. > >> User-managed storage is a requirement. > >> > >> However, it doesn't try to support the formal verification part. I was > >> wondering to know how BitC developers see Deca as in comparison to BitC. > >> What's the good/bad/ugly in Deca with respect to BitC goals. > >> > >> ~ SDK > >> > > > > Writing a language is easy. Putting forth a set of goals that > > everyone wants is also easy. The hard part is making the necessary > > comprises in the implementation when it comes down to those goals > > being fundamentally incompatible. Insofar as that, Deca is a project, > > sure, but no more than any other model programming language > > implementation. > > > > You have to understand that BitC was an idea that was elaborated upon > > throughout years of development by a few people who were really > > working to make it great. Deca, by comparison, is an undergraduate > > thesis. These are vastly different things :-). While many of the > > problems faced in Decas development were also faced in the development > > of BitC, the devil is most certainly in the details. > > > > So basically, making a language is a lot more than writing down a type > > system, writing up a compiler, sticking a GC on top, and marketing it. > > For a system to really succeed there are a lot more practical things > > to think about, and there is no evidence that this has been done in > > Deca (or should be, making a good language is hard, takes lot of smart > > people, translating into lots of money). > > > > As a counterpoint to your example, (although this isn't strictly > > correct), Rust has also been cited as an example of a language solving > > some of the problems that were seen in BitC's development.. > > > > kris > > _______________________________________________ > 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
