3 ms·

Wow, thank you for that reply! I don't think that C stays alive because people just automatically rejected anything else. There is something to C that I apprec

Wow, thank you for that reply! I don't think that C stays alive because people just automatically rejected anything else. There is something to C that I appreciate extremely, and that is the clarity and simple semantics: there is not much hiding and unintentional obfuscation that one can cause when writing C code. Maybe safety and simplicity are mutually exclusive if speed and fine-grained control over memory are the main goals. For Modula, the tools and documentation are not being updated anymore, I could not find a programming environment for eg., emacs and on armv6. Free Pascal and Lazarus are great, until I realized there were no resources to learn modern pascal from. The emacs mode is too basic and doesn't take any advantage of things offered by fpc. But I have to admit, I've never seen anything as good as Lazarus before. D is more like a C++ successor that's aiming at Java than a successor to C. It is complex and does not seem to be making any effort in unifying its concepts: in the same spirit of C++. Cyclone is definitely interesting, but unmaintained and not exactly simple, similarly to Rust but with a C-like syntax. Julia crashes all the time with segmentation faults, sorry, the quality of Julia is super low. I would not use it for anything serious. It has great ideas though. OCaml is super complex with its syntax and semantics. I love Haskell, which makes great efforts to unify its concepts: the language is super simple (its implementation can be arbitrarily complicated). Haskell is where I go to write beautiful things. Fast (like, systems programming fast) Haskell code is ugly and unmaintainable and defeats the purpose of choosing Haskell in the first place. I'll be taking a look at the rest! Thanks!

ihnorton 11y ago
> crashes all the time with segmentation faults We would very much appreciate any bug reports, even if you don't have the time to reduce (if you have filed under another username, thank you!).
StefanKarpinski 11y ago
> Julia crashes all the time with segmentation faults, sorry, the quality of Julia is super low. I would not use it for anything serious. I've seen a lot of Julia used in real world scenarios at companies and this is a pretty surprising claim. Segfaults are very rare – much rarer than in code written in C or C++. You may either have a messed up build of Julia or you could be using packages that call C libraries and do so incorrectly – that would certainly cause segfaults.
- fredmorcos 11y ago
  Sorry for not being clear on this. I was not talking about Julia code crashing. What I meant was when playing around with it, the julia binary would segfault here and there. echo "print(3)" > boot.jl julia --compile=all -O --inline=yes --check-bounds=no --output-o foo.o
  - nickpsecurity 11y ago
    Stefan can tell me if my hunch is right but check-bounds=no might turn off protections against out-of-bounds, memory access. If so, then that command is straight up telling it to segfault.
    - StefanKarpinski 11y ago
      That's true, but it shouldn't segfault unless you do an out-of-bounds memory access, which this code isn't doing. However, there seems to be a misunderstanding about how --compile=all (an experimental feature on the development branch of Julia) works. You can't run an impure operation like print during compilation. In the future, we may have a `julia-compile` command that translates a given Julia program into a binary equivalent, which seems to be what @fredmorcos expects, but that's not how the --compile=all flag works. If you use Julia in the normal manner like you would Python, it's very reliable and stable. If you use experimental features and use them wrong, you can get segfaults. See these posts for more information about and some examples of using the Julia's experimental static compilation features: http://juliacomputing.com/blog/2016/02/09/static-julia.html http://juliacomputing.com/blog/2016/02/09/static-julia.html http://juliacomputing.com/blog/2016/03/10/j2c-announcement.html http://juliacomputing.com/blog/2016/03/10/j2c-announcement.h...
      - nickpsecurity 11y ago
        That makes a lot of sense. Yeah, you should consider renaming it to something more clear. Maybe even change it into several commands with better names. Your docs frame the issue as whether it allows dynamic/JIT stuff or not. So, static-only, allow-dynamic, or allow-jit come to mind.
nickpsecurity 11y ago
"There is something to C that I appreciate extremely, and that is the clarity and simple semantics: there is not much hiding and unintentional obfuscation that one can cause when writing C code." It is pretty straight-forward. However, Modula-2 and Pascal's are even more so as you can represent everything with a simple BNF grammar. There's more consistency, less corner cases, and so on. Every change they make is specifically designed to improve it while maintaining simplicity. The most complicated and modern one can be described fully in around 30 pages [1]. The uppercase and declarations throw people sometimes but keep in mind people used text editors w/out syntax highlighting. http://www.oberon.ch/pdf/CP-Lang.pdf http://www.oberon.ch/pdf/CP-Lang.pdf re mutually exclusive. Nah, there's still tradeoffs you can make. Cyclone and Rust both do that with better design decisions to allow safe, manual management. At some point, you have to choose one or the other though. Your language design matters at this point where the compiler has to know it can remove a check. C's design is so rough and allows so much unpredictable behavior that this is an ongoing research problem for it. Whereas, it happened with Modula-3 libraries in one academic project and happened for Ada with SPARK. Re Modula. Oh yeah, it's not updated anymore. I was just illustrating a language as lean and efficient as C that was safer & easier to compile. A better foundation. It was rejected by C users when it did have compilers. Plus, there's a Modula-2 to C compiler floating around the net. Re Free Pascal and Lazaurus. Interesting feedback. I'll look into that to see if I or developers could remedy it. Except for Emacs: Lazarus is the IDE and better suited. Emacs support might stay dead. Re D. Yes, it's more like C++ but can be used where C is many times. I see you're looking for simple stuff, though. Re Cyclone. It's not simple but not hard either. Remember C is deceptively simple: using it safey is HARD. Cyclone is slightly more complex but way easier to use. Unmaintained, yes, but people (esp GCC or LLVM types) could pick it up any day... if they weren't glued to C. Good call on the Rust connection. https://doc.rust-lang.org/reference.html#appendix-influences https://doc.rust-lang.org/reference.html#appendix-influences re Julia. That's not good... re Ocaml. I think you're focusing too much on complexity of semantics vs complexity of effective use. It's worthwhile to increase learning curve a bit to boost productivity, safety, and maintenance. re Haskell. That reaction surprised me and you're the first to call it simple. Ive been holding off cuz it seemed ridiculously hard and different. What did you use to learn it? Btw, I agree fast Haskell is usually ugly but look up Tolmach's Habit programming language. It's on hold right now cuz he had a better project.

ihnorton 11y ago

> crashes all the time with segmentation faults We would very much appreciate any bug reports, even if you don't have the time to reduce (if you have filed under another username, thank you!).

StefanKarpinski 11y ago

> Julia crashes all the time with segmentation faults, sorry, the quality of Julia is super low. I would not use it for anything serious. I've seen a lot of Julia used in real world scenarios at companies and this is a pretty surprising claim. Segfaults are very rare – much rarer than in code written in C or C++. You may either have a messed up build of Julia or you could be using packages that call C libraries and do so incorrectly – that would certainly cause segfaults.

fredmorcos 11y ago
Sorry for not being clear on this. I was not talking about Julia code crashing. What I meant was when playing around with it, the julia binary would segfault here and there. echo "print(3)" > boot.jl julia --compile=all -O --inline=yes --check-bounds=no --output-o foo.o
- nickpsecurity 11y ago
  Stefan can tell me if my hunch is right but check-bounds=no might turn off protections against out-of-bounds, memory access. If so, then that command is straight up telling it to segfault.
  - StefanKarpinski 11y ago
    That's true, but it shouldn't segfault unless you do an out-of-bounds memory access, which this code isn't doing. However, there seems to be a misunderstanding about how --compile=all (an experimental feature on the development branch of Julia) works. You can't run an impure operation like print during compilation. In the future, we may have a `julia-compile` command that translates a given Julia program into a binary equivalent, which seems to be what @fredmorcos expects, but that's not how the --compile=all flag works. If you use Julia in the normal manner like you would Python, it's very reliable and stable. If you use experimental features and use them wrong, you can get segfaults. See these posts for more information about and some examples of using the Julia's experimental static compilation features: http://juliacomputing.com/blog/2016/02/09/static-julia.html http://juliacomputing.com/blog/2016/02/09/static-julia.html http://juliacomputing.com/blog/2016/03/10/j2c-announcement.html http://juliacomputing.com/blog/2016/03/10/j2c-announcement.h...
    - nickpsecurity 11y ago
      That makes a lot of sense. Yeah, you should consider renaming it to something more clear. Maybe even change it into several commands with better names. Your docs frame the issue as whether it allows dynamic/JIT stuff or not. So, static-only, allow-dynamic, or allow-jit come to mind.

nickpsecurity 11y ago

"There is something to C that I appreciate extremely, and that is the clarity and simple semantics: there is not much hiding and unintentional obfuscation that one can cause when writing C code." It is pretty straight-forward. However, Modula-2 and Pascal's are even more so as you can represent everything with a simple BNF grammar. There's more consistency, less corner cases, and so on. Every change they make is specifically designed to improve it while maintaining simplicity. The most complicated and modern one can be described fully in around 30 pages [1]. The uppercase and declarations throw people sometimes but keep in mind people used text editors w/out syntax highlighting. http://www.oberon.ch/pdf/CP-Lang.pdf http://www.oberon.ch/pdf/CP-Lang.pdf re mutually exclusive. Nah, there's still tradeoffs you can make. Cyclone and Rust both do that with better design decisions to allow safe, manual management. At some point, you have to choose one or the other though. Your language design matters at this point where the compiler has to know it can remove a check. C's design is so rough and allows so much unpredictable behavior that this is an ongoing research problem for it. Whereas, it happened with Modula-3 libraries in one academic project and happened for Ada with SPARK. Re Modula. Oh yeah, it's not updated anymore. I was just illustrating a language as lean and efficient as C that was safer & easier to compile. A better foundation. It was rejected by C users when it did have compilers. Plus, there's a Modula-2 to C compiler floating around the net. Re Free Pascal and Lazaurus. Interesting feedback. I'll look into that to see if I or developers could remedy it. Except for Emacs: Lazarus is the IDE and better suited. Emacs support might stay dead. Re D. Yes, it's more like C++ but can be used where C is many times. I see you're looking for simple stuff, though. Re Cyclone. It's not simple but not hard either. Remember C is deceptively simple: using it safey is HARD. Cyclone is slightly more complex but way easier to use. Unmaintained, yes, but people (esp GCC or LLVM types) could pick it up any day... if they weren't glued to C. Good call on the Rust connection. https://doc.rust-lang.org/reference.html#appendix-influences https://doc.rust-lang.org/reference.html#appendix-influences re Julia. That's not good... re Ocaml. I think you're focusing too much on complexity of semantics vs complexity of effective use. It's worthwhile to increase learning curve a bit to boost productivity, safety, and maintenance. re Haskell. That reaction surprised me and you're the first to call it simple. Ive been holding off cuz it seemed ridiculously hard and different. What did you use to learn it? Btw, I agree fast Haskell is usually ugly but look up Tolmach's Habit programming language. It's on hold right now cuz he had a better project.