51–60 of 363 posts
Earlier quoted context omitted.
I used to debate this but after learning Rust it’s undeniable.
I thought I wanted static typing until I started writing clojure.
It is very hard to make large programs simple, but lisps are some of the best PLs for that, especially if you stick with immutable data.
Earlier quoted context omitted.
> I see that my teams are more effective with static typing If you think you really can see evidence for it then I'd encourage you to write up a paper and submit it for peer review. I guess when you sat down to write it you'd suddenly realise that you don't actually have any hard evidence. > cannot really imagine writing large systems in not statically typed systems Ok but lack of imagination is not science. Some peo…
> Ok but lack of imagination is not science. Sure, but that’s what I said in the first place. It all seems there is no evidence, not even empirical for either way. I was looking for any, if there was. MS or whatnot must have something no?
I would say in summary that no, we don't have any evidence. Evidence that people have tried to present has been found to be flawed in peer review.
Earlier quoted context omitted.
> hugely reducing the likelihood of runtime errors You say this like it's a fact... but again nobody has been able to show this in a proper scientific study.
Considering how many null pointer bugs I've seen, I think that this is a case where absence of evidence is not evidence of absence (at least for null safety).
Write up your experience with null safety as a paper and submit it, because this would be a world-first if you can demonstrate it.
Earlier quoted context omitted.
I do reconsider it all the time; we only have short lives and I cannot build a lot large systems in my life. So that is why I asked if how it is measured. I see that my teams are more effective with static typing, but that also is my management as I, as I said, cannot really imagine writing large systems in not statically typed systems. I write a lot of scheme and k and bash and wrote a lot of tcl and Perl but never…
> I see that my teams are more effective with static typing If you think you really can see evidence for it then I'd encourage you to write up a paper and submit it for peer review. I guess when you sat down to write it you'd suddenly realise that you don't actually have any hard evidence. > cannot really imagine writing large systems in not statically typed systems Ok but lack of imagination is not science. Some peo…
Why, if not for reducing bugs?
Earlier quoted context omitted.
I thought I wanted static typing until I started writing clojure.
I’m not smart enough to program quickly and correctly in Clojure. I think it follows the same ethos Rich Hickey has about unit testing being “guard rail driven development”. I watched him talk about this a decade ago at Strange Loop. To understand your whole program all the time at scale is probably something Rich Hickey is capable of but I definitely am not.
1. If I don’t understand what code does just delete/noop it and see what tests fail.
2. Write my assumptions into new tests to be very loud people if someone wants to break them. Easier said then done with frameworks/callback patterns that want to call my code from god knows where but really powerful when you’re pulling a value.
3. In the case of callback spooky object at a distance stuff be strict about what you accept and fail loud.
Earlier quoted context omitted.
I occasionally missed types even in Clojure. “What keys are supposed to be in this map again? Hmm, turns out some callers are providing foo and some are providing bar…” That said, I certainly agree it comes up less than it does in, say, JavaScript
I agree. In another comment I mentioned how I think Elixir’s pattern matching and annotations (type specs) would take clojure to that next level and strike a perfect balance between between ergonomics and correctness.
Earlier quoted context omitted.
> hugely reducing the likelihood of runtime errors You say this like it's a fact... but again nobody has been able to show this in a proper scientific study.
Considering how many null pointer bugs I've seen, I think that this is a case where absence of evidence is not evidence of absence (at least for null safety).
I'm with GP, I'd really like evidence of this before people continue shouting things which aren't proven.
Earlier quoted context omitted.
> I see that my teams are more effective with static typing If you think you really can see evidence for it then I'd encourage you to write up a paper and submit it for peer review. I guess when you sat down to write it you'd suddenly realise that you don't actually have any hard evidence. > cannot really imagine writing large systems in not statically typed systems Ok but lack of imagination is not science. Some peo…
> We are adding optional static typing to it, Why, if not for reducing bugs?
Maintainability, tooling, and some people would argue for reducing bugs - but I'd challenge them in the same way I challenge you - can they prove it? And I would guess that they cannot.
If the person I was replying to was saying that they could not imagine a large system without types, and well they don't have to since I gave them a real example.
>Hype: "Static Typing reduces bugs." Oof, that one is a huge can of worms.
This one definitely hits close to home. By empirical measure, static typing reduces bugs, but maybe it's just me. I definitely like the comfort of trusting my types. My only experience with dynamic typing is really node, which improves a bit with typescript. But I'm still extremely wary of it because it doesn't give you runtime guarantees. It irks me a lot that you can just do JSON.parse, declare any type on it and c…
Quality of life benefits are where static typing (and in some cases performance) really shines.