Fork me on GitHub
#off-topic
<
2023-06-28
>
Tomasz Korzeniowski (spammer)14:06:33

Our CTO, Karwer, who is a Polish Sudoku Champion and two-time winner of the Polish Math & Logic Games, came up with a great Code Review Best Practices. If you’re up to challenging him, I double dare you 😂 But first check out this insightful post here 👉 https://blog.howareyou.work/code-review-best-practices/

😃 2
didibus18:06:25

Pretty good, but I wish it discussed a bit more the relationship with velocity, estimates, and conflicting priorities.

seancorfield19:06:27

The company is not related to Clojure and they are just self-promoting. Their posts have been removed as spam and the user deactivated.

J14:06:17

https://www.youtube.com/watch?v=Tml94je2edk (No mention of Clojure...)

👀 6
4
😨 2
Rupert (Sevva/All Street)18:06:41

Didn't watch the full video, but it seems any interactive (REPL) programming usually benefits from dynamic types. The other thing about static types (which Rich Hickey pointed out years ago) - is that they don't really prevent any important/interesting problems in code. You basically do all the ceremony and there just isn't much pay off to them. Type System is also pretty bad for code sharing - if all libraries define their own types -you spend tonnes of code coercing/synchronizing data between different types.

👍 8
dgb2319:06:37

That last part is mitigated by structural typing and inference though, where a type is defined by its structure and not by its name.

hifumi12319:06:49

Around the 24 minute mark briefly summarizes what I think about runtime errors — the bugs causing them all passed the type checker…

vemv20:06:20

This debate is not unlike asking "should you show up with a dress shirt, or a bulletproof vest?" The answer is completely context-dependent. 🙂

Rupert (Sevva/All Street)22:06:07

It is but this "bullet proof vest" is overly large/heavy and wouldn't even be effective at stopping a sharp stick.

phronmophobic01:06:11

It seems like these discussions degrade pretty quickly, in part, because we don't have good ways to talk about the different design decisions available. For decades, there was quite a big gulf between "statically typed" languages and "dynamically typed" languages. As he mentions in his talk, the differences between the two camps aren't quite as pronounced as before and there's lots of choices in-between. We now have the term "gradual typing", but that barely helps the discussion about the different choices available. For example, he says that in roc-lang, "type error reports don't block running code" and "no mandatory type declarations". To me, that sounds like gradual typing, but he says roc-lang is statically typed. We probably need more and better ways to talk about the trade-offs of typing.

10
Ben Sless03:06:28

@U45T93RA6 make like John Wick and ask why not both?

😎 2
Rupert (Sevva/All Street)06:06:24

> It seems like these discussions degrade pretty quickly, in part, because we don't have good ways to talk In autonomous driving they have levels 1-5 that helps quite a lot. People often look forward to sleeping or watching a movie on a drive - but then realise the car is only offering Level 1 or 2 Autonomous driving which is similar to cruise control that's been around for decades. The Type System in Java is much more limited to Haskell. e.g. If I want to define a Map where certain keys are Longs and certain keys are Strings and the values are constrained by the type of key - I can't express any of that in Java Type System - in that particular case the Type System is no different from Dynamically Typed - but in a dynamically typed language. In Clojure we would solve this with a simple data validation library (like clojure.spec) - no need to bake it in at the language level.

Ben Kamphaus13:06:39

https://danluu.com/empirical-pl/ is mandatory reading on this topic; little to no evidence of benefits of static types. a personal pet peeve of mine is when people bring up systems where guarantees are a life and death matter - like pacemakers. or aircraft, shuttles, vehicles of various sorts. nevermind that static types are 95%+ about coordination w/in a particular code base: i.e., I’ve got a 1/8" stereo plug, I want to plug it into a guitar amp — no you can’t do that, you need a 1/4" mono plug, oh ok, so if I put it into a stereo to mono converter than a 1/8 to 1/4 converter that only accepts mono input then I’m good, right? — yes, that works. And the difference is between doing it that by generating a wiring diagram and seeing if it will fail, or just trying to plug it in. the better ones ensure that if you want to connect things together a particular way, it will infer which wires you need. the worse ones, just tell you if a particular plug goes into a particular socket, but not necessarily help you with the overall task. none of this tells you whether your guitar is in tune or if you’ll play the right notes. now consider doing that statically vs. dynamically. when you’re talking about all the life or death mission critical systems people start discussing, they’re almost invariable about (1) timing constraints — where you’re in the world of rtos and jitter tolerance and the gradient b/t hard and soft constraints etc. are all about predicting how long things take, which boils down to static vs dynamic determinations of worst case execution time, about which there’s a well defined language of tradeoffs w/very little tribal polemic. I think part of the silliness in type discussions comes out of people just glomming onto the wrong part of the phrase. the most important aspect is “static” vs “dynamic”, not referring to languages as typed or untyped would be a nice first step in having coherent conversations about it. lucky for us Plato wrote about what’s behind the ferocity of arguments b/t advocates of static typing and dynamic typing in the euthyphro almost 2500 years ago.

👍 2
2
xbrln18:06:37

This is too funny and on point 😅 https://youtu.be/urcL86UpqZc

😂 10
ericdallo21:06:35

that guy is really fun haha

ericdallo21:06:48

"The only thing I do in this department is fix people's Emacs" I probably do that once a week indeed 😂

dotemacs05:07:17

Saw people sharing this vid for some time now, but didn’t watch it… until now… So many truth bombs in there… “People don’t quit Emacs… they just die at some point!” That made me laugh out loud 😀

Kimo21:06:26

🐍Py-thon:snake:

🐍 6
Kimo21:06:33

clj is all well and good but its just not snakey

Kimo21:06:02

doesn't have its ducks in a row.

p-himik21:06:40

CLJ is not snakey, it's kebab-ey.

🍢 4
🧆 2
Martynas Maciulevičius22:06:00

Well it likes waterfalls and cliffs... Don't break your legs and eyes and whatever you have.

2
Kimo01:06:19

That picture gives me paren ocd, haha.

Martynas Maciulevičius07:06:05

I wanted the stuff to be oneliner but I also wanted it to not be wider than 80 symbols. This is what python allowed me to do. Also I constantly want to select the whole statement sttmt(a,b,c) or surround it with a function call and I constantly have to create variables after variables for this.

Martynas Maciulevičius09:06:08

For now I want to stick to standard library. But yeah... your suggested library basically implements -> in python :thinking_face:

Martynas Maciulevičius09:06:53

Chopped snake is a tame snake. This backslash works the same as in bash:

sheluchin10:06:30

> Also I constantly want to select the whole statement sttmt(a,b,c) or surround it with a function call and I constantly have to create variables after variables for this. If you have nvim-treesitter-textobjects and vim-surround, you can do stuff like ysacf followed by your wrapping function name:

:keymaps {"af" "@function.outer"
          "if" "@function.inner"
          "ic" "@call.inner"
          "ac" "@call.outer"
          "ig" "@block.inner"
          "it" "@block.outer"
          "as" "@statement.outer"}
https://github.com/nvim-treesitter/nvim-treesitter-textobjects

👍 2
Kimo10:06:14

When I was a kid I'd give anything for a taste of yoda's snake soup.