611–620 of 632 posts
Earlier quoted context omitted.
>> It's for architectural reasons. > No, it's for architectural reasons. You win, I guess?
I'm not sure who you're quoting, but I never even used the word "architecture". I don't even know what that's supposed to mean.
Earlier quoted context omitted.
And you’re just doubling down on sophistry. Why should anyone take you seriously in this conversation?
Saying "you're doubling down on sophistry" instead of just "you're wrong" doesn't actually make you more convincing.
Earlier quoted context omitted.
> There's no such thing as "proving correctness". Given the caveats you mention, is there such thing as proving anything?
There are two meanings of prove. The one that type theorists are using is roughly "to derive your statement from axioms with pure logic." This sense of the term can never apply to things in the real world, like programs (of course, a program also exists both as an abstraction about which things can be proved, but when you're talking about programs which are actually doing things in the real world, you can't treat the…
I am not sure it's a meaningful distinction. There are no triangles in the "real" world -- if you look close under a microscope, there will be more than three sides -- but geometry proves to be of great practical value just the same.
The biggest issue with claims like "there are only diminishing results when using a type system better than the one provided in my blub language" is that it assumes people keep writing the same style of code, regardless of the assurances a better type system gives you. "I don't see the benefit of typed languages if I keep writing code as if it was PHP/JavaScript/Go" ... OF COURSE YOU DON'T! This is missing most of th…
The article makes two main points: a) static typing has a cost and b) thus, any benefit it brings should be examined against that cost. I am sorry, but I don't really see how you stating more benefits of static typing really counters either of them. I recommend reading the article again. But this time, try not to read it as defending a specific language (I only mentioned my blub language so that it's a more specific…
The point is to explore a comparative difference in value, and that is realized through mastery of the tool, not merely living in a world where it exists.
Earlier quoted context omitted.
The article makes two main points: a) static typing has a cost and b) thus, any benefit it brings should be examined against that cost. I am sorry, but I don't really see how you stating more benefits of static typing really counters either of them. I recommend reading the article again. But this time, try not to read it as defending a specific language (I only mentioned my blub language so that it's a more specific…
Those are not really 'points', though; they are far too trivial. Obviously, nothing counters them, because they are tautologies that could just as well apply to any subject. The point is to explore a comparative difference in value, and that is realized through mastery of the tool, not merely living in a world where it exists.
You'd have thunk I didn't have to make them than. But I did, judging from literally every argument I had about this.
Earlier quoted context omitted.
I agree that the third point is important, but it's not clear that it's static typing that is important, and not type annotations. One reason why I can still fairly easily read and understand Eiffel code that I wrote decades ago is Design by Contract. And there's normally nothing static about DbC, it's about assertions that are checked at runtime and that by convention are part of a class's interface. What both type…
I think one disadvantage of runtime type checking and DbC is that the compiler can't aid you in refactoring. For example, if you add a case to a variant or sum type, or change the parameter or return type of some function, in a static type system, the compiler can tell you all the locations you need to change. In a runtime system, you have to find them yourself, or wait till you see an error at runtime. Now, this is…
Now, whether you consider that's actually helping solve the refactoring, or actually introducing new bugs, well - that's another issue :)
Earlier quoted context omitted.
>OTOH, if you're using "codebase of significant size" as code for "big ball of mud", static typing certainly helps, but integration tests are the real lifesaver No. I mean when the codebase is of a certain size, new features require some thought and planning. Features may span multiple-modules. They may require partial or full rewrites or the refactoring of any number of sub-components to support the new behaviour. T…
>No. I mean when the codebase is of a certain size, new features require some thought and planning. Features may span multiple-modules. They may require partial or full rewrites or the refactoring of any number of sub-components to support the new behaviour. This means that you proceed carefully because you may not want to introduce regression bugs. This costs time. Yes. And all equally true for statically typed lang…
>Refactoring without tests is easier in a statically typed language, but still stupid. If you assume a decent body of tests, the benefit dissipates quickly.
We're not arguing whether dynamic language+extensive integration/unit test is better than static typing and no tests.
>And, if your design is solid ...
Yes, if you have a very solid architecture, strict coding guidelines, extensive integration and unit test coverage, experienced developers (etc. etc. etc.) you will mitigate a lot of problems with dynamic typing. So if you do everything right, avoid the pitfalls, you can have something solid. A similar argument is made to me when I assert JavaScript is a terrible language. I don't disagree with either but it doesn't prove anything.
>The cost of "extra typing" is cognitive, not a finger speed limitation.
Exactly.
Earlier quoted context omitted.
> I observe this in myself: my favorite language to code in is Groovy - a dynamic, scripting language with all kinds of fancy tricks. But my favorite language to decode is Java. Because it is so simple, boring, there is almost nothing clever it can do. Every type declared, exception thrown, etc. is completely visible in front of me. one of my favorite things about groovy is that it's easy to start strongly typing thi…
Static typing was grafted onto Apache Groovy in 2012, but no-one really uses it. I'm not sure about its reliability -- its use never took off on the Android platform, and none of the Groovy codebase itself has ever been rewritten in static Groovy. Groovy's still great for scripting on the JVM though, for stuff like those 10-liner build scripts for Gradle, glue code, and mock testing. Just don't use Groovy for buildin…
You keep saying this repeatedly but it just isn't true:
https://github.com/grails/grails-core/blob/master/grails-cor...
https://github.com/groovy/groovy-core/blob/master/src/main/g...
Earlier quoted context omitted.
This is basically why erlang's hot code reloading would be impossible as a general solution in a statically typed language
As long as we are here, with experienced programmers of both "sides", here's a question I've been wondering for some time: is it possible to create a haskell-like type system on an erlang-like language? Erlang has dialyzer, which is great but it's based on optimistic typing. Hot-reloading aside, what would be the issue to creating such language? Maybe some issue with the process pids, which are quite dynamic?
What amuses me in all "static typing versus..." discussions, is that it usually it is the comparison between two camps: Camp A: Languages with mediocre static typing facilities, for example: -- C (weakly typed) -- C++ (weakly typed in parts, plus over-complicated type features) -- TypeScript (the runtime is weakly typed, because it's Javascript all the way down) Camp B: Languages with mediocre dynamic typing faciliti…