4 ms·

No language runtime is ever in a state of "obviously no bugs". Good luck demanding that of anything of JSC's or LLVM's complexity

TomatoCo 4mo ago
On one hand, sure, the entire point of a programming language is to make complex ideas able to be expressed in simpler abstractions. On the other hand, we can damn well try.
- pizlonator 4mo ago
  Damn well trying to enforce an "obviously no bugs" rule in a language runtime would mean zero progress in language runtimes. We certainly wouldn't have gotten to where we are with runtime and compiler quality and performance if we had damn well tried to enforce such a rule
  - nasretdinov 4mo ago
    IMO the very minimum requirement should be that you've demonstrated effort to reduce unnecessary complexity of the problem. Sure, some problems are complex enough that there might not exist an obvious solution, yet usually after a while once you're familiar with some topic the existing solutions do start to appear obvious. If they're not I'd argue we're doing something very very wrong
    - pizlonator 4mo ago
      Adding concurrency to JavaScript definitely falls in the "complex enough" category So does basically any feature or optimization in a JS runtime
      - nasretdinov 4mo ago
        I think it's also worth distinguishing _problem complexity_ and _solution complexity_. The problem might be really really hard (and it very obviously is in the case of adding multi-threading to JavaScript). But it does not mean that the solution has to be hard to understand. It doesn't mean that any average PHP developer (I can say that, I started with PHP) should be able to verify the correctness of the patch, but for a person who is well familiar with the area there shouldn't exist areas they can't understand. Look at the description of your own Fil-C: it focuses on clarity of explanation of how it works, and it actually does make sense (and, hopefully, works well enough too). Compare that with the pull request sent here. I'll wait
        pizlonator 4mo ago
        The solution to concurrency in JS is hard to understand and I would expect even hardened JSVM folks (me included) to be super confused by it
        nasretdinov 4mo ago
        I think you're underselling your own level of intelligence Fil. If even you would be confused by an implementation (and you're the author of the concept) what chances do you think this PR has to actually work correctly?
        pizlonator 4mo ago
        Lots of tests
- adamddev1 4mo ago
  Yes. People are losing the plot and embracing corruption with logic like this: There will always be a few employees stealing. So why don't we just use this system that consistently and randomly introduces theft into every level of our cashflow. We can't expect perfection!
norir 4mo ago
Perhaps then it would be better to not use tools of this level of complexity.
- peesem 4mo ago
  how would you suggest we compile literally anything?
- spankalee 4mo ago
  So don't use compilers at all?
  - nasretdinov 4mo ago
    Compilers aren't made equal either. E.g. compare Visual Studio C++.NET compiler and something like Go. And Go isn't that simple either to be fair
- nasretdinov 4mo ago
  I think LLVM is a perfect example of what happens when it's too complicated: it's slow, it's bug-ridden when you stray away from the beaten path (e.g. Rust hits bugs in LLVM like this one https://www.reddit.com/r/rust/comments/l4roqk/a_fix_for_the_llvm_noalias_bug_has_landed_in_time/ https://www.reddit.com/r/rust/comments/l4roqk/a_fix_for_the_... ), and it's really hard to use and understand. It's obviously not useless because of that, but it's a great example of what happens when you cannot fully control the implementation complexity
matsemann 4mo ago
My Elm code base was virtually bug free. My current python code base is riddled with small bugs. Some designs makes it easy to trust your code. Some make it die by a thousand paper cuts. Big llm rewrites I fear lead to the latter.
- jitl 4mo ago
  how similar is your elm app to a JIT compiler runtime?

TomatoCo 4mo ago

On one hand, sure, the entire point of a programming language is to make complex ideas able to be expressed in simpler abstractions. On the other hand, we can damn well try.

pizlonator 4mo ago
Damn well trying to enforce an "obviously no bugs" rule in a language runtime would mean zero progress in language runtimes. We certainly wouldn't have gotten to where we are with runtime and compiler quality and performance if we had damn well tried to enforce such a rule
- nasretdinov 4mo ago
  IMO the very minimum requirement should be that you've demonstrated effort to reduce unnecessary complexity of the problem. Sure, some problems are complex enough that there might not exist an obvious solution, yet usually after a while once you're familiar with some topic the existing solutions do start to appear obvious. If they're not I'd argue we're doing something very very wrong
  - pizlonator 4mo ago
    Adding concurrency to JavaScript definitely falls in the "complex enough" category So does basically any feature or optimization in a JS runtime
    - nasretdinov 4mo ago
      I think it's also worth distinguishing _problem complexity_ and _solution complexity_. The problem might be really really hard (and it very obviously is in the case of adding multi-threading to JavaScript). But it does not mean that the solution has to be hard to understand. It doesn't mean that any average PHP developer (I can say that, I started with PHP) should be able to verify the correctness of the patch, but for a person who is well familiar with the area there shouldn't exist areas they can't understand. Look at the description of your own Fil-C: it focuses on clarity of explanation of how it works, and it actually does make sense (and, hopefully, works well enough too). Compare that with the pull request sent here. I'll wait
      - pizlonator 4mo ago
        The solution to concurrency in JS is hard to understand and I would expect even hardened JSVM folks (me included) to be super confused by it
        nasretdinov 4mo ago
        I think you're underselling your own level of intelligence Fil. If even you would be confused by an implementation (and you're the author of the concept) what chances do you think this PR has to actually work correctly?
        pizlonator 4mo ago
        Lots of tests
adamddev1 4mo ago
Yes. People are losing the plot and embracing corruption with logic like this: There will always be a few employees stealing. So why don't we just use this system that consistently and randomly introduces theft into every level of our cashflow. We can't expect perfection!

norir 4mo ago

Perhaps then it would be better to not use tools of this level of complexity.

peesem 4mo ago
how would you suggest we compile literally anything?
spankalee 4mo ago
So don't use compilers at all?
- nasretdinov 4mo ago
  Compilers aren't made equal either. E.g. compare Visual Studio C++.NET compiler and something like Go. And Go isn't that simple either to be fair
nasretdinov 4mo ago
I think LLVM is a perfect example of what happens when it's too complicated: it's slow, it's bug-ridden when you stray away from the beaten path (e.g. Rust hits bugs in LLVM like this one https://www.reddit.com/r/rust/comments/l4roqk/a_fix_for_the_llvm_noalias_bug_has_landed_in_time/ https://www.reddit.com/r/rust/comments/l4roqk/a_fix_for_the_... ), and it's really hard to use and understand. It's obviously not useless because of that, but it's a great example of what happens when you cannot fully control the implementation complexity

matsemann 4mo ago

My Elm code base was virtually bug free. My current python code base is riddled with small bugs. Some designs makes it easy to trust your code. Some make it die by a thousand paper cuts. Big llm rewrites I fear lead to the latter.

jitl 4mo ago
how similar is your elm app to a JIT compiler runtime?