31–40 of 59 posts
Looks awesome, especially the type system. Check out http://code.google.com/p/decac/source/browse/examples/list.d... I'd love to see some discussions on possible/practical shortcomings.
I keep a (small) list of active awesome and interesting alternatives to C. Cyclone has been mentioned already, adding Deca now. the other two I know are: * ATS http://www.ats-lang.org/#what_is_ats_good_for * Clay http://claylabs.com/clay/
Dont you know about Rust? If you do why is it not on the list?
But when i was making the list I was thinking about if the language could possibly be used in an embed context. C is still king there. Rust I believe, is partially garbage collected in a way that is not practically avoidable. Any use of boxed types or abstract datatypes will incur this penalty. So with that criterion rust is not an option, in an embed system continuous execution is most vital. The languages I listed are either not garbage collected or with an ability to turn it off or use an alternative to abstract datatypes and have basically no overhead. The last time I saw Rust mentioned on HN a team member validly stated that such concerns are not the priority at the moment.
One possible feature that stands out would be macros local to a scope. I actually did this, defined a macro right in the middle of a function to automate some error-handling junk. It felt nasty, but not quite as nasty as copy-pasting or retyping the code, as long as I don't try to re-use the name. It would be nice if my language handled stuff like this.
This is obviously not a huge issue. The language looks awesome.
I greped for "core", "memory manager", "thread", "threading", and "cache", in the pdf [1]. Am I missing something? I'll probably get flak for this, but this programmer looks for a modern systems language that directly addresses these concerns. "The fundamental problems of a systems-programming task or environment are hard limits on computational resources and a lack of safety protections. Systems programs have to dea…
Ideally these would be disjoint sets (in my opinion) but consider this: ASM -> C -> C++ -> Java -> ... looks like a continuum if you're writing any kind of Java code, but there's a sharp discontinuity in there if you're writing (say) a boot loader.
I greped for "core", "memory manager", "thread", "threading", and "cache", in the pdf [1]. Am I missing something? I'll probably get flak for this, but this programmer looks for a modern systems language that directly addresses these concerns. "The fundamental problems of a systems-programming task or environment are hard limits on computational resources and a lack of safety protections. Systems programs have to dea…
I've always taken "systems language" to mean something you might write an OS in while the Go team takes it to mean something you'd replace Java with. Whichever way you want to look at it one thing the Go team can't say is that writing an OS is a "non-systems" problem. Ideally these would be disjoint sets (in my opinion) but consider this: ASM -> C -> C++ -> Java -> ... looks like a continuum if you're writing any kin…
I do agree with that. (Perhaps it would be helpful to apply the high/low qualifier to systems languages?)
> Ideally these would be disjoint sets (in my opinion) but consider this: ASM -> C -> C++ -> Java -> ... looks like a continuum if you're writing any kind of Java code, but there's a sharp discontinuity in there if you're writing (say) a boot loader.
Food for thought. I am not arguing for needless complexity (in a language) as far as the boot up phase is concerned. As far as I understand it, the loader has its critical, but short lived, life-cycle role to play and then it is out of the way. Arguably, it is distinct from the OS. Can we not continue to write them in ASM/C and load operating systems that are written in a more "modern" language?
Earlier quoted context omitted.
I've always taken "systems language" to mean something you might write an OS in while the Go team takes it to mean something you'd replace Java with. Whichever way you want to look at it one thing the Go team can't say is that writing an OS is a "non-systems" problem. Ideally these would be disjoint sets (in my opinion) but consider this: ASM -> C -> C++ -> Java -> ... looks like a continuum if you're writing any kin…
> Whichever way you want to look at it one thing the Go team can't say is that writing an OS is a "non-systems" problem. I do agree with that. (Perhaps it would be helpful to apply the high/low qualifier to systems languages?) > Ideally these would be disjoint sets (in my opinion) but consider this: ASM -> C -> C++ -> Java -> ... looks like a continuum if you're writing any kind of Java code, but there's a sharp disc…
I still don't imagine an OS being written in a non-systems application language, since you've got drivers and performance critical subsystems to write and things like GC to worry about from the apps-only languages.
Earlier quoted context omitted.
One of the examples in the repository is an implementation of malloc. I tend to think of Go as an attempt to redefine what a systems programming language is (hence the "modern"). I don't think that there can be an established definition of what a modern systems language is, otherwise it would no longer be termed modern. Almost by definition theorists will differ on what the essential characteristics must be.
> One of the examples in the repository is an implementation of malloc. Right. And (imho) malloc is quite possibly an "old fashioned" way of looking at things: function malloc(num_bytes: nat): @byte A reference to a byte block obtained from specifying the number of bytes! I would like to see the modern memory manger be type aware, have a very rich memory model, and allow for the propagation of application level seman…
Because these are system languages, that would happen when hardware is type aware.
It's great to see a language which doesn't ignore 20th and 21st century programming language theory. It's tremendously boring waiting for the future to happen.... Anyhow, the type system looks quite interesting. The choice of LLVM for C interface and performance is also really sensible. I was surprised to find the language implemented in Scala and Java though. Perhaps there will be some kind of bootstrap, or maybe th…
The language is a compiled language, with the JVM being used (originally) because I wanted a particular parser generator. Deca code can't access Java libraries because Deca code compiles to LLVM bitcode and thence to machine code. decac is a compiler, not an interpreter, so it takes the Deca code in and outputs the LLVM bitcode. Sorry about the lack of docs. I've been slowly dumping my undergraduate thesis on this in…
Earlier quoted context omitted.
The language is a compiled language, with the JVM being used (originally) because I wanted a particular parser generator. Deca code can't access Java libraries because Deca code compiles to LLVM bitcode and thence to machine code. decac is a compiler, not an interpreter, so it takes the Deca code in and outputs the LLVM bitcode. Sorry about the lack of docs. I've been slowly dumping my undergraduate thesis on this in…
Sorry to nag, but how is outputting to LLVM bitcode not interpreting? You are taking source code and turning it into intermediate form (i.e. LLVM bitcode), no?
A compiler transforms a program from one format into another. decac does not execute programs, so it's not an interpreter.
I keep a (small) list of active awesome and interesting alternatives to C. Cyclone has been mentioned already, adding Deca now. the other two I know are: * ATS http://www.ats-lang.org/#what_is_ats_good_for * Clay http://claylabs.com/clay/
A lot of work there has been done in completely replacing the entire current software development stack with something more reasonable (in terms of size/bloat and design). They aim for a full system (frontend user apps to the metal) in under 20,000 lines of code. Check it out. Quite the alternative to C, and everything.