5 ms·

> Maybe type system help is for people who don’t practice enough. That's like advocating that tests are for people who "can't" write bug free code. Is this the

by tiles 9y ago

> Maybe type system help is for people who don’t practice enough. That's like advocating that tests are for people who "can't" write bug free code. Is this the attitude of all JSC developers toward engineering abstractions? I would expect designing a system that JITs third-party code from adversarial parties would lead you to be more cautious about code quality, not less.

pizlonator 9y ago
Tests are great. No harm in tests. I just don't think that we have sufficient evidence to conclude that using type systems to aid the development of concurrent code actually leads to better concurrent code. Therefore, I err on the side of not using the type system for that purpose so that I can use it for many other things that I think it's really good at. (Just take a look at JSC's source code if you want to see our extensive reliance on those areas of C++'s type system that we can use to get hard guarantees. It's not that we don't like types. It's that we use types in an evidence-based way in those places where they actually help us catch bugs.)
- first_amendment 9y ago
  > I just don't think that we have sufficient evidence to conclude that using type systems to aid the development of concurrent code actually leads to better concurrent code. This is like saying we don't have evidence that evolution is real. Type systems are proof systems. If a type system encodes concurrency safety, and a program is valid under that system, then you can be 100% certain that program doesn't have a race condition bug due to shared state between threads. If a type system can prove buggy concurrent code is invalid code, then by definition it leads to better valid concurrent code.
  - pizlonator 9y ago
    Lol! You would not be successful as a scientist with this attitude. A type system is a proof. But the proof in the type system is not a proof that it’s better to use a type system than not. That’s an entirely separate question. I think that type systems are good at some things. Concurrency isn’t one of them.
    - first_amendment 9y ago
      I made an argument. What's yours? You just made a statement of opinion without any justification. Additionally your opinion is wrong, by simple counter example. Rust's type checker already has the ability to prevent data races: https://blog.rust-lang.org/2015/04/10/Fearless-Concurrency.html https://blog.rust-lang.org/2015/04/10/Fearless-Concurrency.h... This works today.
- blub 9y ago
  Any specific parts of JSC one should look into? Btw, in case others are also wondering: JSC is JavaScriptCore.
  - pizlonator 9y ago
    All over. We use smart pointers over raw pointers. We have probably hundreds of data types defined as classes, which have only very controlled conversions to other data types. See things like DFG::AbstractHeap or B3::ValueRep.

by tiles 9y ago

pizlonator 9y ago

Tests are great. No harm in tests. I just don't think that we have sufficient evidence to conclude that using type systems to aid the development of concurrent code actually leads to better concurrent code. Therefore, I err on the side of not using the type system for that purpose so that I can use it for many other things that I think it's really good at. (Just take a look at JSC's source code if you want to see our extensive reliance on those areas of C++'s type system that we can use to get hard guarantees. It's not that we don't like types. It's that we use types in an evidence-based way in those places where they actually help us catch bugs.)

first_amendment 9y ago
> I just don't think that we have sufficient evidence to conclude that using type systems to aid the development of concurrent code actually leads to better concurrent code. This is like saying we don't have evidence that evolution is real. Type systems are proof systems. If a type system encodes concurrency safety, and a program is valid under that system, then you can be 100% certain that program doesn't have a race condition bug due to shared state between threads. If a type system can prove buggy concurrent code is invalid code, then by definition it leads to better valid concurrent code.
- pizlonator 9y ago
  Lol! You would not be successful as a scientist with this attitude. A type system is a proof. But the proof in the type system is not a proof that it’s better to use a type system than not. That’s an entirely separate question. I think that type systems are good at some things. Concurrency isn’t one of them.
  - first_amendment 9y ago
    I made an argument. What's yours? You just made a statement of opinion without any justification. Additionally your opinion is wrong, by simple counter example. Rust's type checker already has the ability to prevent data races: https://blog.rust-lang.org/2015/04/10/Fearless-Concurrency.html https://blog.rust-lang.org/2015/04/10/Fearless-Concurrency.h... This works today.
blub 9y ago
Any specific parts of JSC one should look into? Btw, in case others are also wondering: JSC is JavaScriptCore.
- pizlonator 9y ago
  All over. We use smart pointers over raw pointers. We have probably hundreds of data types defined as classes, which have only very controlled conversions to other data types. See things like DFG::AbstractHeap or B3::ValueRep.