Fork me on GitHub
#off-topic
<
2019-02-15
>
emccue03:02:53

I've been using Scala for the last month and a half for work and wow

emccue03:02:05

That is a complicated freaking language

emccue03:02:27

Every week I learn about some new language feature and my reaction is rapidly becoming "oh God really?"

mattly03:02:02

Scala is the C++ / Javascript of the JVM world

dpsutton03:02:20

@emccue how are you liking it?

emccue03:02:53

I'm on the big data team so I don't have to actually interact with other people's code all that often

emccue03:02:10

I'm just writing my own jobs and queries and stuff

emccue03:02:30

So it's fine, I can do whatever I want and it doesn't hold me back all that much

emccue03:02:33

But my teammates have varying degrees of competence in the language and varying clashing ideas about how they should write their own software

emccue03:02:53

So Scala is providing a giant footgun to code reviews

dpsutton03:02:49

are there "encode it in the types" arguments vs encode it in the data? a friend of mine got big into haskell and if you didn't put some constraint into the types he would think it very poor code

emccue03:02:58

It's certainly a people problem, but I don't think I'll ever truly understand the dev who uses implicits

dpsutton03:02:04

not sure if types have gotten like that in scala

emccue03:02:04

No, never that in depth

emccue03:02:38

If we have conversations it's always about the business case, which sucks because it just lets underlying code problems fester

emccue03:02:40

I don't think there is anyone on my team who has ever used haskell

dpsutton03:02:19

ok. i've never used scala so i wasn't sure if it was "types first" like haskell

emccue03:02:48

Okay maybe too topical

emccue04:02:56

As always rereading my opinions I realize I'm not super coherent

emccue04:02:15

But whatever, more of a snapshot of my emotional state than anything else

Alex Miller (Clojure team)07:02:05

I think all of the channels are the wrong channel and you should not post it anywhere here

seancorfield07:02:00

Spam-be-gone 🙂

borkdude12:02:45

What does this tell? You can show a similar pic of the class hierarchy of the seq abstraction.

cvic12:02:57

I would like to see that.

mpenet12:02:41

most of it are impl details in clj (some more important than others ok)

cvic12:02:12

Don't see any FilterMonadics here... Eh, nvm.

cvic12:02:37

At the end of the day, if that language gets stuff done... that's all that matters.

jsa-aerial15:02:21

That looks way simpler - doesn't look like you can even draw the scala version without crossing 'lines'

aisamu19:02:09

"is your graph even planar"

Lennart Buit19:02:04

lets play: find the k5 or K3,3

val_waeselynck18:02:11

Might want to count edges before reaching for to Kuratowsky minors :)

💯 5
Lennart Buit20:02:00

Haha someone got the reference and made me reread about discrete math. Thanks!

Daniel Hines16:02:18

Does it make sense when doing TDD or unit tests in general to write a test for an API in terms of the API itself? E.g. in JavaScript Mocha syntax

it("should get and retrieve things from a DB", () => {
  // Returns null when it key doesn't exist
  assert(thing.getFromDB({key: "foo"} === null);
  const result = thing.insertIntoDB({key: "foo", value: "bar"});
  assert(thing.getFromDB({key: "foo"}) === "bar");
});

dpsutton16:02:22

what do you mean in terms of the API? wouldn't you want to use the API? why does this seem weird?

lilactown16:02:36

@d4hines is your question specifically re: thing.insertIntoDB?

Daniel Hines16:02:49

Well, I think of a unit test as testing the smallest discrete chunk of functionality possible. But the test above tests two functions: get and insert.

Daniel Hines16:02:08

I'm using one API function to validate another.

Daniel Hines16:02:14

When both are under test.

Daniel Hines16:02:57

The only downside I can see is that if the test fails, I have to check both getFromDB and insertIntoDB for bugs.

lilactown16:02:33

it's testing whether your library is consistent at least 😄 that things you put in the DB you can get back out

dpsutton16:02:15

this isn't a unit test really. it's an integration test since you're using some kind of real database. so seems fine to me. if this usage doesn't work you've got a problem

Daniel Hines16:02:51

What if that DB is a datascript DB, atom, or similar?

Daniel Hines16:02:59

It happens to be an in-memory thing... But isn't it better not to care whether something is in-memory or over the wire or whatever? As long is it meets your expectations (including performance, if you have any), isn't it better not to know?

dpsutton16:02:12

then i don't think you are testing anything

wekempf16:02:01

We've been trying for a very long time to abstract away the wire. The reality is, you can't. The wire has certain characteristics, such as not being reliable, that you simply can't abstract away, and your code will be more reliable if you don't try to. So, I can't agree with "isn't it better not to care whether something is in-memory or over the wire".

lilactown16:02:17

but I agree you're probably not testing what you are talking about