On Sun, Jun 10, 2012 at 2:00 PM, <[email protected]> wrote:
> > Message: 1 > Date: Sat, 9 Jun 2012 13:53:40 -0400 > From: Kristopher Micinski <[email protected]> > Subject: Re: [bitc-dev] Deca, successor of BitC? > To: Discussions about the BitC language <[email protected]> > Message-ID: > <caf1sy-f5tzfualfpxynokjortthhkwvtntejk95iebir52r...@mail.gmail.com > > > Content-Type: text/plain; charset=ISO-8859-1 > > 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 > > > > ------------------------------ > > Message: 2 > Date: Sat, 9 Jun 2012 13:55:27 -0400 > From: Kristopher Micinski <[email protected]> > Subject: Re: [bitc-dev] Deca, successor of BitC? > To: Discussions about the BitC language <[email protected]> > Message-ID: > <caf1sy-hl6uxofnoomqhwncoyy6ke6bh7ysuppjdqyvtdjm1...@mail.gmail.com > > > Content-Type: text/plain; charset=ISO-8859-1 > > 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 > > > > ------------------------------ > > Message: 3 > Date: Sat, 9 Jun 2012 17:00:25 -0700 > From: "Jonathan S. Shapiro" <[email protected]> > Subject: Re: [bitc-dev] Deca, successor of BitC? > To: Discussions about the BitC language <[email protected]> > Message-ID: > <CAAP=3QNag8E4gJ13_xi9oV=ctijctzj5p5y7ehlykv0dskw...@mail.gmail.com > > > Content-Type: text/plain; charset="iso-8859-1" > > 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 > > > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://www.coyotos.org/pipermail/bitc-dev/attachments/20120609/a85a470c/attachment-0001.html > > ------------------------------ > > Message: 4 > Date: Sat, 9 Jun 2012 20:13:28 -0400 > From: Kristopher Micinski <[email protected]> > Subject: Re: [bitc-dev] Deca, successor of BitC? > To: Discussions about the BitC language <[email protected]> > Message-ID: > <caf1sy-fchhh-dpc_5yng-uh2fkqdjbdjxv4w2j_arzix+tz...@mail.gmail.com > > > Content-Type: text/plain; charset=ISO-8859-1 > > On Sat, Jun 9, 2012 at 8:00 PM, Jonathan S. Shapiro <[email protected]> > wrote: > > 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. > > > > > I shouldn't have undersold it, it's an amazing piece of work, but the > OP seemed to believe that it was the "next" BitC. For an > undergraduate piece of work, especially compared to the amount of work > *typically* required in such projects (next to nothing), it's very > good, but comparable to BitC in the number of man hours put in, or the > amazingly large amount of email on the list? Not close. > > Designing languages is hard, it's that simple, :-). But both projects > have served to advance the field with some great anecdotal evidence of > what works well, and elaborate upon the kinds of problems you run into > when designing real systems. > > (It always starts out "it's going to be Fast! and Functional! and > Verified! And it's going to run Without a Garbage Collector or > Runtime System! And we're going to write Real Systems in it!") > > kris > > > ------------------------------ > > Message: 5 > Date: Sat, 9 Jun 2012 20:16:40 -0400 > From: Kristopher Micinski <[email protected]> > Subject: Re: [bitc-dev] Deca, successor of BitC? > To: Discussions about the BitC language <[email protected]> > Message-ID: > <caf1sy-hg42krn8pff5e0wgypn5m9o83jsstmgqak6gxsu+9...@mail.gmail.com > > > Content-Type: text/plain; charset=ISO-8859-1 > > On Sat, Jun 9, 2012 at 8:13 PM, Kristopher Micinski > <[email protected]> wrote: > > On Sat, Jun 9, 2012 at 8:00 PM, Jonathan S. Shapiro <[email protected]> > wrote: > >> 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. > >> > > > > > > I shouldn't have undersold it, it's an amazing piece of work, but the > > OP seemed to believe that it was the "next" BitC. ?For an > > undergraduate piece of work, especially compared to the amount of work > > *typically* required in such projects (next to nothing), it's very > > good, but comparable to BitC in the number of man hours put in, or the > > amazingly large amount of email on the list? ?Not close. > > > > Designing languages is hard, it's that simple, :-). ?But both projects > > have served to advance the field with some great anecdotal evidence of > > what works well, and elaborate upon the kinds of problems you run into > > when designing real systems. > > > > (It always starts out "it's going to be Fast! ?and Functional! ?and > > Verified! ?And it's going to run Without a Garbage Collector or > > Runtime System! ?And we're going to write Real Systems in it!") > > > > kris > > As Dr. Shapiro notes, systems languages with real PL influence are > hard to write, because few people are good systems people and good PL > people. (I am neither.) > > There's a long history of programming languages targeting safe systems > programming, but I haven't seen a comprehensive list anywhere, which > might be an interesting read. (For example, the one I'll throw out is > Cyclone,..) > > kris > > @Kris, perhaps I picked up the wrong phrase (successor of BitC) from the ycombinator comments :-) I am not trying to equate or elevate Deca here. I was only curious how BitC developers evaluate Deca. I have great respects to the people involved in BitC project and people involved in the informative discussions in the mailing list. @Shap, Can you please elaborate on what you mean by Deca made few interesting choices and missed others. ~SDK
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
