On Mon, Jul 15, 2013 at 3:09 PM, David Jeske <[email protected]> wrote: > On Mon, Jul 15, 2013 at 1:56 PM, Jonathan S. Shapiro <[email protected]> > wrote: >> >> If you want the C memory model, stick with C. A language that purports to >> give type safety, and then uses the C memory model, is far worse than a >> language that makes no pretenses. > > > I didn't say the language would be typesafe. It most certainly would not be! > At the same time, I don't think it's too much to ask to have typechecked > enums and a few other modernizations. That's like advocating someone either > ride a horse or wait for someone (you?) to invent warp-drive. > >> The [C++] exception problem is a much bigger problem, and not just for the >> boundary between C++ and C. > > > Agreed. I think a bit of my feature-list came from the desire for something > which innovated from C into something very different than C++... > > Compiler checked enums, compiler checked exhaustive enum/type switch, and > compiler checked pass-or-handle error values would be a big step in software > construction (even if not for typesafety and security).... C++ only has one > of those, and that comes with a bunch of stuff we don't want. > >> I'm actually very disturbed that somebody might build the language you >> describe. From a computer security perspective, C and C++ are part of the >> problem we need to conclusively eliminate. > > > Now this I don't get. I respect your aims. However, advocating for the > replacement of systems with others that are demonstrably inferior in many > ways (overhead, performance, responsiveness) is the tail wagging the dog. > The onus falls on all-of-us to build a system which is so much better in all > of these ways it is flocked to. To do otherwise is just tilting at > windmills. > > In my idealistic heart, I want the mythical Apache 2.0 licensed > cross-platform CLR + Azul/Zing no-pause GC to be the solution that ends > C-development. However, my engineer mind knows that even in that fantastic > system, which I do think would be a much more capable C/C++ competitor > today, GC tracing work is proportional to pointer-count and > program-duration. There are certain programs for which that model can not > equal C performance. And then there is the fact that the mythical system > does not exist.
I would much prefer that people capable of inventing performant, low level languages focus on safe languages at the same time. Most of the code I personally write is performance-critical geometry algorithms, which for now (in part due the surrounding ecosystem of libraries, collaborators, etc.) restricts me to C++. However, at the same time we're trying to branch out into web applications, mobile, etc. If someone invents a slightly better but still unsafe C++, it makes part of my life fractionally better. It also may end up forcing us to rewrite a bunch of performance intensive algorithms in Javascript to avoid client/server bottlenecks, jumping through ridiculous hoops to compensate for the slowness of dynamic languages. I would gladly spend a few more years programming in C++ and then get a language which is simultaneously safe and performant, and is therefore capable of running in web / mobile / etc. at the same time. So please take your time and make everything safe! I am happy to wait longer as a consequence, and look forward to using the result! Geoffrey _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
