Fork me on GitHub
#off-topic
<
2019-10-06
>
hackeryarn00:10:41

@ericnormand I'm curious where you find spec to fall short in doing the static analysis of a type system?

andy.fingerhut00:10:26

Spec itself does zero static analysis. There is another add-on tool where another developer has implemented some amount of static checking on top of spec: https://github.com/arohner/spectrum

hackeryarn00:10:31

I'm sorry, that was a badly worded question on my part. I meant to ask if there is a class of errors where spec falls short compared to static analysis.

seancorfield00:10:43

Back in the early '90s I worked for a company that built static analysis code tools (for C, C++, FORTRAN). There's a lot of stuff that static analysis can detect in a code base -- with a lot less effort than trying to find those problems with tests in general.

hackeryarn00:10:15

That makes a lot of sense. Thanks for the explanation @seancorfield!

seancorfield00:10:30

The tricky part is avoiding false positives -- you don't want to flag things that are actually correct just because they might violate some "rule" of the system.

seancorfield00:10:48

And type systems are the same: there are a lot of correct programs that violate the type system.

seancorfield00:10:19

When we were experimenting with core.typed that was a problem we ran into at work.

seancorfield00:10:01

It would complain about the type signatures of some of our code -- or be unable to deduce types from certain code.

hackeryarn00:10:07

Yeah kind of reminds me of problems with linters flagging something just because of a rule despite it making sense in the particular use case.

seancorfield00:10:09

The code was correct but we had to refactor it to satisfy the type checker.

hackeryarn00:10:15

Does not sound like a fun situation.

ericnormand00:10:42

that's a simple question with a complex answer

ericnormand00:10:02

not least because I have not used spec very much

ericnormand00:10:16

i will have to think about it

seancorfield00:10:38

Spec is powerful, but it's a runtime system.

hackeryarn00:10:22

Wasn't sure of your mileage with it. I've used it at the boundaries of a couple apps to check input I don't have control over, and have been pretty happy with it.

seancorfield00:10:13

I haven't looked at Spectrum. It's an interesting idea.

hackeryarn00:10:18

Well, you can use it to generatively test your app too.

seancorfield00:10:29

That's still runtime πŸ™‚

seancorfield00:10:11

(but generative testing is a very powerful technique)

seancorfield00:10:27

We love Spec at work. Used it very heavily in production code since the early alphas. We use it for a lot of data validation (and conforming).

hackeryarn00:10:41

Totally agree. I'm just concerned with catching errors. I don't want to discredit a solution just because it's runtime and not compile time. I'm not sure how big of a role runtime vs compile time should play if the main concern is correctness.

dpsutton00:10:44

Typed languages have generative testing. It’s not abandoned in typed languages

hackeryarn00:10:58

Right, but if you use all these other techniques to ensure good code, how much benefit are you getting for the cost of a type system. Just exploring the cost benefit of a type system.

dpsutton00:10:23

have you worked in a typed language? there's a lot of pros about them. and finding an expressive language makes it even better. its really nice when a helpful compiler works with you to ensure your code is typed correctly. there have been lots of studies but they're usually pretty superficial and not "real world". Best to try an expressive typed language and see if you dig it

hackeryarn01:10:36

Yeah, I've worked in C, Java, Go, TS, Rust, and Haskell. I still keep bouncing back and forth. I find that it helps me some times, but others it makes refactors, testing, and some simple things much more difficult.

dpsutton01:10:48

i've never heard typing making refactors more difficult

dpsutton01:10:40

(and i didn't mean to imply that you hadn't worked in typed languages, was curious. i find that preferring typing or dynamic is usually a pretty personal predilection more than anything else)

dpsutton01:10:10

refactoring in C# with resharper was extremely powerful. And having a compiler direct is so confidence inspiring. I can't imagine changing the signature of some low level stuff in our current clojure codebase or in my last clojure job. ensuring the call sites were updated would be a nightmare

hackeryarn01:10:33

Sorry, I didn't mean anything by the list. It's just that all those take their own approach and I was hoping to find common ground. The refactoring bit, it definitely helps in some cases, but in others it requires more code changes over all. At first you have to modify the type, then possibly the interface, then possibly some references that don't care about your change, and only then you get to your logic.

dpsutton01:10:50

that was never my experience. can you explain more what you mean by references that don't care about your change?

hackeryarn01:10:54

Well recently in Go, I had to move a concrete implementation to a interface to make a specific testing scenario work. Because of that I had to change a bunch references to now take an interface so I could pass in a mock of the interface.

hackeryarn01:10:35

All those changes were required only because there was a type system in the first place.

gklijs12:10:02

Not uncommon in a Java setup either.

seancorfield01:10:59

It's the reverse of the encapsulation argument: if you encapsulate data and use getters/setters then you can change the implementation as much as you want.

emil0r07:10:30

What are people's opinion on Go?

πŸ‘ 1
🀐 1
1
kulminaator12:10:22

you could as well ask what's people's opinion on ford πŸ™‚

kulminaator12:10:44

does go solve a problem for you that nothing else that you already know doesn't ?

hackeryarn12:10:50

Pros: It gives you a lot fewer opportunities to shoot yourself in the food. The code is straight forward to an extreme degree. You can teach it to someone in a day. A lot of decisions gets dictated by the language. Cons: The lack of abstraction gets frustrating quickly. The type system is limited. Error handling is tedious. A lot of decisions gets dictated by the language. I see why large enterprises started using it. It makes coordination between teams easy. But, I would not say I ever enjoyed using it.

kulminaator12:10:24

i personally don't have problems to solve with Go ... for high level stuff i pick java or clojure for simplicity.... for low level i pick C or if i'm adventurous i go with Rust

Nate Sutton13:10:35

the design of the language is pretty awful

Nate Sutton13:10:43

the language implementers get access to certain crucial features that you don't

Nate Sutton13:10:29

things like append can either mutate or make a new thing at runtime which is super weird to me

emil0r14:10:41

Thanks. Useful replies.

seancorfield19:10:01

If you Bing/Google for go is an awful language or what's wrong with go language you'll get a lot of detailed analysis that aligns with @U8QBZBHGD’s comment.

seancorfield19:10:48

I share those opinions too. I was very disappointed with Go when I learned it several years ago. I learned Rust the next year and it was really what I had hoped Go would be in many ways.

emil0r07:10:47

Thank you @seancorfield. Will take a look

kulminaator16:10:44

if you seek a really good low level language then rust beats the pants off from go

ericnormand16:10:41

the types discussion reminds me that I did use spec in my Building Composable Abstractions talk. https://lispcast.com/building-composable-abstractions/