5 ms·

I once wrote a C interpreter for scripting (picoc) which had memory safety. To my surprise I received a lot of complaints from people who wanted the more conven

by zik 10y ago

I once wrote a C interpreter for scripting (picoc) which had memory safety. To my surprise I received a lot of complaints from people who wanted the more conventional memory unsafe semantics. I changed it to being memory unsafe and I've never had any requests to change it back. Perhaps there's a place in this world for both approaches?

marktangotango 10y ago
That's really interesting. Is there any documentation around for memor safe version? I'd like to study your implementation!
mamcx 10y ago
Or more probable you userbase was full of C developers, that can't imagine to be possible to code outside the C-mindset. Take in account how many can't even consider the possibility that a full OS can (and have be made before) safer, have GC, is NOT C, is NOT EVEN ALIKE C, etc. C, C++, Unix are the biggest roadblock in the progres of computing. Or more exactly, the users, that prefer patch-along and commit million of dollars in wasted effort than in build (or rediscover) better ways. This is alike climate change resistance. Why go solar, if carbon is better and well understood? Instead, push ahead and waste money fixing symptoms instead of causes. And "causes" is a word that here mean, C, C++, Unix, etc...
- pmilot 10y ago
  That's an unfair judgement toward the C development community as a whole. There are legitimate use cases for C. If you're writing low-level, bare-metal programs then there is no other portable programming language that offers better semantics. C programmers often laud that language because they can easily reason what the output of the compiler will be. That is an extremely important and rare property for a portable programming language. But hey, don't listen to me, listen to an actual experienced C programmer: https://youtu.be/MShbP3OpASA?t=20m45s https://youtu.be/MShbP3OpASA?t=20m45s
  - naasking 10y ago
    > C programmers often laud that language because they can easily reason what the output of the compiler will be. They certainly do, and in doing so, conveniently forget all the instances of their compilers surprisingly deleting invalid code as optimization because it inadvertently depended upon undefined behaviour.
  - sametmax 10y ago
    Would rust fit the bill though ? It's not as mature, and don't support as many platforms yet, but it is considered now as a serious safer alternative, with as much bare metal capabilities.
    - geocar 10y ago
      No. Because it's not as mature, and doesn't support as many platforms. Those things are very important to me, and there is no steel thread for them. I imagine that in twenty years, it could be worth talking about rust as an alternative, but rust is only two years "stable", and it's unclear what the language, the tooling and the libraries are going to look like in that time. Meanwhile, I have software I wrote 20 years ago in C that still runs, correctly, and on the Internet, generating income, and a big part of the reason why is that C was already more than twenty years old at that point.
      - mamcx 10y ago
        > I imagine that in twenty years... But WHY in 20? With this thinking NEVER WILL BE IMPROVED THE SITUATION! And I don't mean you, I mean the whole industry. Obviously stability and compatibility is important, but is not this almost like the COBOL problem? Nobody try to move out from COBOL because "maybe in the far future a solution will emerge" and the the future get here, and we are decades LATE? And RUST is not the only viable alternative. Ada, Pascal, Oberon, Modula (to name the family of languages I know more, but is likely some lisp and others exist too) where already there (decades ago) without break too much from the C mindset (and go crazy with monads and stuff like that). So, because look like without {} a system language have not chance in hell, take oberon and put the C syntax? And them we are not waiting 20 years in the future for it. But this will fail, for the same reasons that renuevable energy will fail against carbon: The community will not accept the costs in the short-term, not matter how much things could improve later... P.D: And what if a "rust-alike" lang but trans-piling to C, like with Nim? Or even better: C2 (C with improvements and eliminating as much baggage as possible) trans-piling to C. Eventually this will allow to bootstrap and still keep a way to old code bases...

by zik 10y ago

marktangotango 10y ago

That's really interesting. Is there any documentation around for memor safe version? I'd like to study your implementation!

mamcx 10y ago

Or more probable you userbase was full of C developers, that can't imagine to be possible to code outside the C-mindset. Take in account how many can't even consider the possibility that a full OS can (and have be made before) safer, have GC, is NOT C, is NOT EVEN ALIKE C, etc. C, C++, Unix are the biggest roadblock in the progres of computing. Or more exactly, the users, that prefer patch-along and commit million of dollars in wasted effort than in build (or rediscover) better ways. This is alike climate change resistance. Why go solar, if carbon is better and well understood? Instead, push ahead and waste money fixing symptoms instead of causes. And "causes" is a word that here mean, C, C++, Unix, etc...

pmilot 10y ago
That's an unfair judgement toward the C development community as a whole. There are legitimate use cases for C. If you're writing low-level, bare-metal programs then there is no other portable programming language that offers better semantics. C programmers often laud that language because they can easily reason what the output of the compiler will be. That is an extremely important and rare property for a portable programming language. But hey, don't listen to me, listen to an actual experienced C programmer: https://youtu.be/MShbP3OpASA?t=20m45s https://youtu.be/MShbP3OpASA?t=20m45s
- naasking 10y ago
  > C programmers often laud that language because they can easily reason what the output of the compiler will be. They certainly do, and in doing so, conveniently forget all the instances of their compilers surprisingly deleting invalid code as optimization because it inadvertently depended upon undefined behaviour.
- sametmax 10y ago
  Would rust fit the bill though ? It's not as mature, and don't support as many platforms yet, but it is considered now as a serious safer alternative, with as much bare metal capabilities.
  - geocar 10y ago
    No. Because it's not as mature, and doesn't support as many platforms. Those things are very important to me, and there is no steel thread for them. I imagine that in twenty years, it could be worth talking about rust as an alternative, but rust is only two years "stable", and it's unclear what the language, the tooling and the libraries are going to look like in that time. Meanwhile, I have software I wrote 20 years ago in C that still runs, correctly, and on the Internet, generating income, and a big part of the reason why is that C was already more than twenty years old at that point.
    - mamcx 10y ago
      > I imagine that in twenty years... But WHY in 20? With this thinking NEVER WILL BE IMPROVED THE SITUATION! And I don't mean you, I mean the whole industry. Obviously stability and compatibility is important, but is not this almost like the COBOL problem? Nobody try to move out from COBOL because "maybe in the far future a solution will emerge" and the the future get here, and we are decades LATE? And RUST is not the only viable alternative. Ada, Pascal, Oberon, Modula (to name the family of languages I know more, but is likely some lisp and others exist too) where already there (decades ago) without break too much from the C mindset (and go crazy with monads and stuff like that). So, because look like without {} a system language have not chance in hell, take oberon and put the C syntax? And them we are not waiting 20 years in the future for it. But this will fail, for the same reasons that renuevable energy will fail against carbon: The community will not accept the costs in the short-term, not matter how much things could improve later... P.D: And what if a "rust-alike" lang but trans-piling to C, like with Nim? Or even better: C2 (C with improvements and eliminating as much baggage as possible) trans-piling to C. Eventually this will allow to bootstrap and still keep a way to old code bases...