Fork me on GitHub

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


That is a complicated freaking language


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


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


@emccue how are you liking it?


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


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


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


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


So Scala is providing a giant footgun to code reviews


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


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


not sure if types have gotten like that in scala


No, never that in depth


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


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


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


Okay maybe too topical


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


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


Spam-be-gone 🙂


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


I would like to see that.


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


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


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


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


"is your graph even planar"

Lennart Buit19:02:04

lets play: find the k5 or K3,3


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");


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


@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.


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


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?


then i don't think you are testing anything


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".


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