4 ms·

As a Lisp programmer, I don't dunk on everything that is not Rust; I instead dunk on everything that is C. The extensive use of this language has brought us cou

As a Lisp programmer, I don't dunk on everything that is not Rust; I instead dunk on everything that is C. The extensive use of this language has brought us countless pain via stack overflows, buffer overflows, memory corruption, and multiple other vulnerabilities that are literally baked into the language model. Dropping C for any sane alternative will be a massive boon.

jayp1418 6y ago
I think ada can be good contender for C replacement
- MaxBarraclough 6y ago
  I think Ada's future is in safety-critical systems, where it makes sense to invest heavily in correctness, with the option of using SPARK and formal verification. Additionally, Ada has several mature compilers suitable for life-and-death applications. For more ordinary software though, doesn't Rust make more sense? Its approach to memory management for instance, with a borrower-checker, seems much nicer than what Ada has to offer. Disclaimer: I know neither language very well.
- imtringued 6y ago
  You need something with traction. How are you going to rally people to use ada? Where is the ada version of Gitoxide?
  - MaxBarraclough 6y ago
    > You need something with traction No language has traction, until it does. It would be fair to point out though that Ada has had decades to catch on and replace C, but it hasn't done so, except in certain narrow areas of highly critical embedded software development in aviation and military applications. My understanding is that it's not easy to work with for 'general purpose' work (command-line applications on GNU/Linux), as it lacks mature bindings. I think it's fair to say Ada failed to truly embrace Free and Open Source software. A pity, in my opinion.
    - jayp1418 6y ago
      Well they are trying to reach FOSS community. Recently they started survey asking community "Hello here, we (AdaCore) have some plan for the future of GNAT Community that we want to share and have your opinion on: https://forms.gle/Q34myTCQUXvrva5n7 https://forms.gle/Q34myTCQUXvrva5n7 " There is Ravenports very good port manager written in ada for FreeBSD so ada can be used for CLI apps and has good gtk binding too
      - MaxBarraclough 6y ago
        A good sign, see also relevant discussion at [0]. I like the idea of a FORTH target that someone suggested. Are the higher assurance-levels of SPARK going to remain unavailable to FOSS developers, as they apparently are now? [1] [0] https://groups.google.com/forum/#!topic/comp.lang.ada/M3yS4STOEBw https://groups.google.com/forum/#!topic/comp.lang.ada/M3yS4S... [1] https://www.adacore.com/sparkpro https://www.adacore.com/sparkpro
- erik_seaberg 6y ago
  Doesn't Ada have the same explicit deallocation and use-after-free problems C does?
namKS 6y ago
Better do not use Lisp, since the interpreters have at least around 10% C.
- phoe-krk 6y ago
  They're compilers, not interpreters - or at least SBCL, CCL, ABCL, ECL, Clasp, CLISP, ABCL, and LispWorks are. I'm not aware of any other alive contemporary Common Lisp implementations. Lisp is a memory-safe language with automatic memory management, which removes all of the aforementioned classes of attacks that are available in C. In addition, the Lisp compilers are written in Lisp itself, not in C, which further decreases the attack vector. Also, the currently-in-progress SICL project intends to do away with C completely, even for its garbage collection and OS-interfacing parts.
  - hmartins 6y ago
    CCL: Totals grouped by language (dominant language first): lisp: 336793 (84.60%) asm: 30410 (7.64%) ansic: 29862 (7.50%) sh: 718 (0.18%) objc: 299 (0.08%) java: 7 (0.00%) > Lisp is a memory-safe language with automatic memory management, which removes all of the aforementioned classes of attacks that are available in C. Yeah, right.
    - phoe-krk 6y ago
      > Yeah, right. In Lisp, the programmer never frees memory themselves, so use-after-free and double-free are not triggerable by the user. Bound checks for all array types are in effect, so overflows are impossible. Strong typing and a lack of casting prevent type confusion. Do you have any arguments other than the unsubstantial "yeah, right"?
      - deleted 6y ago
        [deleted]
- kazinator 6y ago
  Lisp implementations using C means that the implementations may have C-related vulnerabilities, not Lisp programs themselves. You're not facing the risk of creating new C-related vulnerabilities by writing new application code in Lisp, even if the Lisp you're using has substantial amounts of the run-time written in C.

jayp1418 6y ago

I think ada can be good contender for C replacement

MaxBarraclough 6y ago
I think Ada's future is in safety-critical systems, where it makes sense to invest heavily in correctness, with the option of using SPARK and formal verification. Additionally, Ada has several mature compilers suitable for life-and-death applications. For more ordinary software though, doesn't Rust make more sense? Its approach to memory management for instance, with a borrower-checker, seems much nicer than what Ada has to offer. Disclaimer: I know neither language very well.
imtringued 6y ago
You need something with traction. How are you going to rally people to use ada? Where is the ada version of Gitoxide?
- MaxBarraclough 6y ago
  > You need something with traction No language has traction, until it does. It would be fair to point out though that Ada has had decades to catch on and replace C, but it hasn't done so, except in certain narrow areas of highly critical embedded software development in aviation and military applications. My understanding is that it's not easy to work with for 'general purpose' work (command-line applications on GNU/Linux), as it lacks mature bindings. I think it's fair to say Ada failed to truly embrace Free and Open Source software. A pity, in my opinion.
  - jayp1418 6y ago
    Well they are trying to reach FOSS community. Recently they started survey asking community "Hello here, we (AdaCore) have some plan for the future of GNAT Community that we want to share and have your opinion on: https://forms.gle/Q34myTCQUXvrva5n7 https://forms.gle/Q34myTCQUXvrva5n7 " There is Ravenports very good port manager written in ada for FreeBSD so ada can be used for CLI apps and has good gtk binding too
    - MaxBarraclough 6y ago
      A good sign, see also relevant discussion at [0]. I like the idea of a FORTH target that someone suggested. Are the higher assurance-levels of SPARK going to remain unavailable to FOSS developers, as they apparently are now? [1] [0] https://groups.google.com/forum/#!topic/comp.lang.ada/M3yS4STOEBw https://groups.google.com/forum/#!topic/comp.lang.ada/M3yS4S... [1] https://www.adacore.com/sparkpro https://www.adacore.com/sparkpro
erik_seaberg 6y ago
Doesn't Ada have the same explicit deallocation and use-after-free problems C does?

namKS 6y ago

Better do not use Lisp, since the interpreters have at least around 10% C.

phoe-krk 6y ago
They're compilers, not interpreters - or at least SBCL, CCL, ABCL, ECL, Clasp, CLISP, ABCL, and LispWorks are. I'm not aware of any other alive contemporary Common Lisp implementations. Lisp is a memory-safe language with automatic memory management, which removes all of the aforementioned classes of attacks that are available in C. In addition, the Lisp compilers are written in Lisp itself, not in C, which further decreases the attack vector. Also, the currently-in-progress SICL project intends to do away with C completely, even for its garbage collection and OS-interfacing parts.
- hmartins 6y ago
  CCL: Totals grouped by language (dominant language first): lisp: 336793 (84.60%) asm: 30410 (7.64%) ansic: 29862 (7.50%) sh: 718 (0.18%) objc: 299 (0.08%) java: 7 (0.00%) > Lisp is a memory-safe language with automatic memory management, which removes all of the aforementioned classes of attacks that are available in C. Yeah, right.
  - phoe-krk 6y ago
    > Yeah, right. In Lisp, the programmer never frees memory themselves, so use-after-free and double-free are not triggerable by the user. Bound checks for all array types are in effect, so overflows are impossible. Strong typing and a lack of casting prevent type confusion. Do you have any arguments other than the unsubstantial "yeah, right"?
    - deleted 6y ago
      [deleted]
kazinator 6y ago
Lisp implementations using C means that the implementations may have C-related vulnerabilities, not Lisp programs themselves. You're not facing the risk of creating new C-related vulnerabilities by writing new application code in Lisp, even if the Lisp you're using has substantial amounts of the run-time written in C.