|
Plorkyeran posted:ideally you'd want to only ignore non-semantic whitespace changes, which does require language processing don't use -w on Python code, I guess. pretending the user has some idea what's going on can simplify things oh you mean like line ending stuff? working line by line makes most of that moot I think?
|
#
?
Apr 11, 2015 03:23
|
|
|
|
| # ? Jun 1, 2024 21:08 |
|
|
i was thinking more of wanting to see whitespace changes inside string literals but nowhere else, but i guess there's also languages where a+b is different from a + b and python
|
|
#
?
Apr 11, 2015 03:29
|
|
|
Plorkyeran posted:i was thinking more of wanting to see whitespace changes inside string literals but nowhere else, but i guess there's also languages where a+b is different from a + b and python oh yeah, hmm it's a blunt tool, just read the whole diff you pussy
|
|
#
?
Apr 11, 2015 03:33
|
|
|
it's certainly not a critical issue that torments me on a daily basis or anything. i'm just saying that the simple language-agnostic tools are merely okay and not a totally solved problem
|
|
#
?
Apr 11, 2015 03:34
|
|
|
Plorkyeran posted:it's certainly not a critical issue that torments me on a daily basis or anything. i'm just saying that the simple language-agnostic tools are merely okay and not a totally solved problem "merely ok" is a pretty good situation, IMO. I think that's the case for most trades
|
|
#
?
Apr 11, 2015 03:37
|
|
|
there is a distinction worth making between type systems and other forms of static analysis. a type system is generally sound but incomplete: you may not be able to express what you want directly in the type system, but whatever you can express will be enforced without fail. in theory, a good static analysis should be both sound and complete, but due to rice's theorem you can't do anything non-trivial this way. in reality, commercial static analysis tools trade soundness for additional completeness: they'll find many types of errors, but there's no guarantee that for any type, every such error will be caught. this is mainly because being more sound involves generating a lot more false positives, which are annoying enough to the user that he may give up on the tool entirely. if the tool finds 1 of 2 errors in the code, well then that's 1 fewer error than you had before, and you don't know about the other one, so you're not gonna blame the tool. on the other hand, if the tool finds both errors but generates 100 false positives, the tool user must check all these false positives manually, and he's liable to just say "gently caress this"
|
|
#
?
Apr 11, 2015 04:18
|
|
|
JewKiller 3000 posted:there is a distinction worth making between type systems and other forms of static analysis. a type system is generally sound but incomplete: you may not be able to express what you want directly in the type system, but whatever you can express will be enforced without fail. in theory, a good static analysis should be both sound and complete, but due to rice's theorem you can't do anything non-trivial this way. in reality, commercial static analysis tools trade soundness for additional completeness: they'll find many types of errors, but there's no guarantee that for any type, every such error will be caught. this is mainly because being more sound involves generating a lot more false positives, which are annoying enough to the user that he may give up on the tool entirely. if the tool finds 1 of 2 errors in the code, well then that's 1 fewer error than you had before, and you don't know about the other one, so you're not gonna blame the tool. on the other hand, if the tool finds both errors but generates 100 false positives, the tool user must check all these false positives manually, and he's liable to just say "gently caress this" developer ergonomics matter, indeed
|
|
#
?
Apr 11, 2015 04:25
|
|
|
JewKiller 3000 posted:there is a distinction worth making between type systems and other forms of static analysis. a type system is generally sound but incomplete: you may not be able to express what you want directly in the type system, but whatever you can express will be enforced without fail. this is a good post and I had not considered this distinction
|
|
#
?
Apr 11, 2015 04:31
|
|
|
Mr. Glass posted:"static analysis" is a euphemism for "hacky tools i have to use because my programming language doesn't have an expressive enough type system" i'm sorry the project is not being done using your favorite language, but we're not rewriting the whole thing jut because you don't like it.
|
|
#
?
Apr 11, 2015 04:46
|
|
|
Mr. Glass posted:this is a good post and I had not considered this distinction 
|
|
#
?
Apr 11, 2015 04:47
|
|
|
Wheany posted:i'm sorry the project is not being done using your favorite language, but we're not rewriting the whole thing jut because you don't like it. that's fine, i'll go find another job then, there are plenty. enjoy working with all those fresh-out-of-college node.js wizards i mean ok i understand if we're talking about linux or firefox or some other huge codebase that isn't going anywhere, but if you're starting a new project and you choose a language with no static type system (or a useless type system) then S M D H
|
|
#
?
Apr 11, 2015 04:49
|
|
|
JewKiller 3000 posted:there is a distinction worth making between type systems and other forms of static analysis. a type system is generally sound but incomplete: you may not be able to express what you want directly in the type system, but whatever you can express will be enforced without fail. in theory, a good static analysis should be both sound and complete, but due to rice's theorem you can't do anything non-trivial this way. in reality, commercial static analysis tools trade soundness for additional completeness: they'll find many types of errors, but there's no guarantee that for any type, every such error will be caught. this is mainly because being more sound involves generating a lot more false positives, which are annoying enough to the user that he may give up on the tool entirely. if the tool finds 1 of 2 errors in the code, well then that's 1 fewer error than you had before, and you don't know about the other one, so you're not gonna blame the tool. on the other hand, if the tool finds both errors but generates 100 false positives, the tool user must check all these false positives manually, and he's liable to just say "gently caress this" Ty for this good post, Jew Killer 3000
|
|
#
?
Apr 11, 2015 05:01
|
|
|
fritz posted:i dont fully see what kind of type system would catch some of these errors: http://clang-analyzer.llvm.org/available_checks.html just require all programs to be provably correct, nbd
|
|
#
?
Apr 11, 2015 15:56
|
|
|
JewKiller 3000 posted:that's fine, i'll go find another job then, there are plenty. enjoy working with all those fresh-out-of-college node.js wizards
|
|
#
?
Apr 11, 2015 18:07
|
|
|
suffix posted:just require all programs to be provably correct, nbd and don't allow recursion on terms which aren't provably smaller
|
|
#
?
Apr 11, 2015 18:12
|
|
|
lisp is a cool dynamically typed language but it feels like its advantages besides metaprogramming have been long supplanted by statically typed languages
|
|
#
?
Apr 11, 2015 18:13
|
|
|
bbbut dynamically typed languages let me move fast!
|
|
#
?
Apr 11, 2015 18:13
|
|
|
JewKiller 3000 posted:that's fine, i'll go find another job then, there are plenty. enjoy working with all those fresh-out-of-college node.js wizards oh no, this project is nowhere near as big as firefox or linux, but it has been in production for a couple of years now. it works well and isn't a nightmare to maintain. but it needs to be maintained. we're not rewriting the whole thing jut because you don't like it.
|
|
#
?
Apr 11, 2015 18:20
|
|
|
Wheany posted:oh no, this project is nowhere near as big as firefox or linux, but it has been in production for a couple of years now. it works well and isn't a nightmare to maintain. but it needs to be maintained. how big is it
|
|
#
?
Apr 11, 2015 19:12
|
|
|
comedyblissoption posted:lisp is a cool dynamically typed language but it feels like its advantages besides metaprogramming have been long supplanted by statically typed languages dynamic + strong typing is super nice (like in python and erlang, not like javascript). there's evidence that dynamic typing makes programming more productive compared to static. and lots of applications doesn't need static typing because it'd be pointless optimization
|
|
#
?
Apr 11, 2015 19:35
|
|
|
also static type checking is redundant if you write tests, and you should write tests anyway yaddayadda
|
|
#
?
Apr 11, 2015 19:36
|
|
|
Symbolic Butt posted:dynamic + strong typing is super nice (like in python and erlang, not like javascript). there's evidence that dynamic typing makes programming more productive compared to static. first, python still relies on lame-rear end duck typing, i don't care how "strong" it is, it's pretty useless for enforcing my program invariants or static analysis statically typed languages can still be highly interactive, and that's where i think the productivity gains lie. i demand a compiler AND an interpreter, motherfuckers. lisp, haskell, scala's designers understood this. p-lang designers didn't Notorious b.s.d. fucked around with this message at 19:42 on Apr 11, 2015 |
|
#
?
Apr 11, 2015 19:38
|
|
|
comedyblissoption posted:lisp is a cool dynamically typed language but it feels like its advantages besides metaprogramming have been long supplanted by statically typed languages common lisp has a real static type system. it's completely optional, and therefore completely ignored programmers are lazy assholes, so optional strong, static typing reduces to being weakly, dynamically typed when real-world users touch your language
|
|
#
?
Apr 11, 2015 19:39
|
|
|
Symbolic Butt posted:also static type checking is redundant if you write tests, and you should write tests anyway yaddayadda why the gently caress should i write a blizzard of extra tests? i'd rather just have more expressive code. type systems are useful specifically because i don't need a shitload of extra unit tests to express my intended program invariants. the code itself says what is supposed to happen lousy type systems ruby/perl/python make it extremely difficult to write expressive code. to build a robust codebase, you spend lots and lots of time writing tests that are not interesting to future readers. Notorious b.s.d. fucked around with this message at 19:45 on Apr 11, 2015 |
|
#
?
Apr 11, 2015 19:43
|
|
|
Symbolic Butt posted:also static type checking is redundant if you write tests, and you should write tests anyway yaddayadda lol
|
|
#
?
Apr 11, 2015 19:43
|
|
|
Notorious b.s.d. posted:common lisp has a real static type system. it's completely optional, and therefore completely ignored Does it have inference? Erlang's got an optional type system too, and it gets rather well used around even on codebases that don't annotate anything. The type declarations can be used in documentation, analysis, tests (as quickcheck/PropEr generators). In practice the language remains dynamic, but you get to find type errors that would otherwise show themselves at runtime before then.
|
|
#
?
Apr 11, 2015 20:04
|
|
|
|
|
#
?
Apr 11, 2015 20:10
|
|
|
Notorious b.s.d. posted:why the gently caress should i write a blizzard of extra tests? i'd rather just have more expressive code. you don't need "extra tests" or whatever, that's bad tdd mumbojumbo assert(poop_type == type(butt())) <-- dumb testing by dumb people I'm advocating for the kinds of testing that you need to write in any kind of language anyway (the ones that test nontrivial invariants you know), those will always give you the benefits of static type checking for free realistically speaking, I can see it in a scenario where nobody writes any tests in your lovely company so you can be like "thank god AT LEAST I GOT STATIC TYPE CHECKING HERE". you're still hosed but you'd be more hosed with python in this case, mmyes
|
|
#
?
Apr 11, 2015 20:24
|
|
|
MononcQc posted:Does it have inference? Erlang's got an optional type system too, and it gets rather well used around even on codebases that don't annotate anything. The type declarations can be used in documentation, analysis, tests (as quickcheck/PropEr generators). In practice the language remains dynamic, but you get to find type errors that would otherwise show themselves at runtime before then. I do not know common lisp very well but I think it does Erlang seems like it's kind of an exception, because if you're working with Erlang then you're most likely already experienced enough to know that being a lazy bastard now gets you in the deep poo poo later (esp. when you're working with complex stuff like distributed systems), so use type annotations, static analysis, etc. as much as possible
|
|
#
?
Apr 11, 2015 20:25
|
|
|
Symbolic Butt posted:I'm advocating for the kinds of testing that you need to write in any kind of language anyway (the ones that test nontrivial invariants you know), those will always give you the benefits of static type checking for free oh, well, im convinced
|
|
#
?
Apr 11, 2015 20:31
|
|
|
fart simpson posted:oh, well, im convinced glad that's sorted out
|
|
#
?
Apr 11, 2015 21:28
|
|
|
here lies static typing killed by unit tests
|
|
#
?
Apr 11, 2015 21:40
|
|
|
i'm glad that the debate is over and i can now be ultra productive writing in a plang
|
|
#
?
Apr 11, 2015 21:41
|
|
|
I don't even p-lang much anymore I've been mostly writing C  ...and debugging bash scripts 
|
|
#
?
Apr 11, 2015 22:05
|
|
|
Symbolic Butt posted:I don't even p-lang much anymore i havent done any serious work in python for like 6 months now, it's been all c++ and java
|
|
#
?
Apr 11, 2015 22:09
|
|
|
Symbolic Butt posted:I'm advocating for the kinds of testing that you need to write in any kind of language anyway (the ones that test nontrivial invariants you know), those will always give you the benefits of static type checking for free please add "sufficiently good test suite" to the list of silver bullets alongside "sufficiently expressive type system" and "sufficiently smart compiler" me, I'll carry on using all the crutches available to deal with the imperfect world I have to live in, where static typing remains useful
|
|
#
?
Apr 11, 2015 22:19
|
|
|
how long until a dynamically typed codebase invents its own system of ad hoc type documentation through comments or hungarian notation or statically typed transpiler how many different ways do library authors end up documenting their types
|
|
#
?
Apr 11, 2015 22:21
|
|
|
comedyblissoption posted:how long until a dynamically typed codebase invents its own system of ad hoc type documentation through comments or hungarian notation well, phpdoc and rdoc are things p useful things, imo
|
|
#
?
Apr 11, 2015 22:24
|
|
|
Soricidus posted:oh cool this argument again don't gimmickshame please Soricidus posted:please add "sufficiently good test suite" to the list of silver bullets alongside "sufficiently expressive type system" and "sufficiently smart compiler" I'm not even idealizing one supposed kind of "good testing suite" like those silver bullets. I'm saying that by mere virtue of having a testing suite at all already makes static type checking redundant. and it's the 2010s, if you don't use vcs and write tests then I don't know what the gently caress
|
|
#
?
Apr 11, 2015 22:39
|
|
|
|
| # ? Jun 1, 2024 21:08 |
|
|
Symbolic Butt posted:I'm not even idealizing one supposed kind of "good testing suite" like those silver bullets. I'm saying that by mere virtue of having a testing suite at all already makes static type checking redundant. 
|
|
#
?
Apr 11, 2015 22:55
|
|