On Thu, Jan 20, 2011 at 6:25 PM, Ben Kloosterman <[email protected]> wrote: For me the big things from BitC are - Can work without GC / non boxed types - Non null-able types - Type safety - Optional Memory safety - Type classes for light polymorphism - Functional language support - Mutable data support. - Deal with unusual types ( eg cast a index to a byte array to a variable size message - i do this at the moment with an external C function ...) This enumeration is very useful, and I agree with almost all of it. Type classes are currently being challenged, but the benefits are clear and the issues are clear. Not clear how that will play out, but however it does, it will be the result of taking type classes as a starting point and dealing with the practical engineering issues that arise. Functional programming, on the other hand, strikes me as "up for grabs", mainly because it's a term that means many different things. Some people mean (in the end) first-class procedures. BitC certainly isn't going to give that up. Others mean the ability to have pure [sub]programs. That's currently up for grabs. So it would be very helpful if you might expand on what you consider to be the key properties of functional programming in the context of BitC... Im interested in functional programming mainly to reduce bugs , reduce development time and make changes easier by capturing the essence of the logic in a more elegant fashion. I have little interest in concurrency benefits since I'm using single threaded code and IPC to different threads . I prioritise the human readability of code for non experts ( I think Haskell and some of the Haskell style unit tests fail there - but they are not meant to learn from ) which is why I was going on about struct methods like is_empty() and functional program can help with this ( though also make it worse eg monads). If code is easy to read eg few arcane symbols/operators people will quickly learn it and be comfortable trying to change it . I have some interest in the security aspects of pure functions eg it makes it easier to eyeball the code. If ex VB6 developers use a nice lib with lots of pure functions in a huge mutable monstrous single let , that if fine too since they write their code quick and the key functions are being re-used. Ie they are productive yet they would benefit from a functional standard lib . That said where needed I use mutable state eg hot spots , I see it integrated into the language better than doing it in a separate language. It would be nice if pure functions are so identified with a keyword for multi threading /security purposes but the idea of eliminating class/module / global static state to me is impractical and more trouble than it's worth but reducing it is great.. Im still learning more advanced aspects where the code builds the functions so it's hard for me to comment on them but it seems to work nice with type inference. To be more clear the elimination of null , functional programming ( encourage reducing state and mutability) , type safety and memory safety eliminates nearly all non logic programming bugs . Imperative programming should still be used in the 20% case where its much simpler/easier to write or performance demands it. It may be that it disappears / reduces but until the skillset has also improved I would like this to be a slow thing. Sometimes I see people struggling to make things purely functional - this is wrong and kills productivity. I still think we can do more to make the transition to BitC easier and to prevent bad programmers doing the wrong things , but getting something out to see what we hit in medium/large projects seems the most important as what is learned there will be of more importance and syntactic sugar can be added at that point. Ben
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
