4 ms·
Right you are. I am not at all arguing for using any of those languages. I too think automatic buffer overrun checking is the sort of thing a true C replacement
by tinco 14y ago
Right you are. I am not at all arguing for using any of those languages. I too think automatic buffer overrun checking is the sort of thing a true C replacement should not have.
Nor should it have _even more_ idiosyncrasies like C++ or automatic memory management or even a runtime (so no rust).
You bring to light the painful question, who is going to do it? Language designers are far too keen on fancy features. All C replacements that have been suggested in the past decade, Java, Go, Rust, Vala, rely on runtimes that take away true control in trade for features like typesafety, memory management and security.
The person who is going to be the creator of the next C has to be a hero in an epic tale, first he should grow up with clean comfortable languages like C#, Ruby or Haskell, but then dark times will force uncomfortable languages like C and C++ on him. But the rough times will make him stronger, and in the end he will slay the dragon with a tool that unifies his love of comfort with the cold pragmatic of bare metal code.
Someone should make a movie out of it ;)
- andrewflnr 14y agoI'll watch that movie. :) You might want to look at the languages ATS, deca, BitC, and Clay, if you haven't already. Yes, I've been keeping a list, but I haven't looked at all of them in depth recently. Edit: just discovered Tart. Can't tell if it requires a runtime.
- tinco 14y agoWow thanks! I actually didn't know any of those languages!
- eli_gottlieb 14y agoNot sure if House requires a runtime or not. Deca has been... delayed by my continually having to revise its goddamned type system. Maybe if ECOOP says yes to me in February... or at least sends a rejection notice in which the reviews don't point out some unsoundness issue.
- andrewflnr 14y agoGoogling "house [programming] language" gives me nothing useful. Can you give me something more specific? And keep it up on Deca. We need it. ;)
- eli_gottlieb 14y agoSorry, turns out House was the kernel and Habit was the language. http://hasp.cs.pdx.edu/ http://hasp.cs.pdx.edu/ And keep it up on Deca. We need it. ;) If you know a type theorist who could check over my paper without any obligations to the ECOOP programming committee so I could finally have someone confirm that this algorithm isn't Doomed To Failure, that would be incredibly helpful. Also, if you could come up with any neat ideas on the following matter, that would be great. http://marmoach.blogspot.co.il/2011/10/multi-method-type-classes.html http://marmoach.blogspot.co.il/2011/10/multi-method-type-cla...
- andrewflnr 14y agoThanks, a fun new OS to look at too. I don't know any type theorists, and I'm afraid I'm not much of one myself (yet). I'm mostly just looking forward to something DRYer and safer than C for low-level programming. I'll do my best to grok the type class versus multimethod thing. That seems to be within reach.
- eli_gottlieb 14y agoI'll do my best to grok the type class versus multimethod thing. That seems to be within reach. Thanks, actually. My brain one-tracks itself too often to handle everything. In the meanwhile, I'm taking a look at the paper below, "Integrating Nominal and Structural Subtyping". If its type-system works the way I intuit it does, I might be able to tear out both existential types and sum types from Deca and replace them with something more familiarly object-oriented-looking. The bit-level implementation would work a lot like Deca's current existentials and extensible sum types, but the syntax would transform to become more Scala-like (I really like Scala) and I could substitute class extension for existential packaging. http://dl.acm.org/citation.cfm?id=1428525 http://dl.acm.org/citation.cfm?id=1428525 EDIT: Confirmed. I can tear out existential types, sum types, and recursive types for a single, intuitive, object-oriented-style type construct.