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

Reply via email to