This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2023-06-28
Channels
- # announcements (5)
- # babashka (7)
- # beginners (46)
- # biff (28)
- # calva (7)
- # cider (3)
- # clerk (82)
- # clj-commons (9)
- # clj-kondo (7)
- # clojure (37)
- # clojure-dev (16)
- # clojure-europe (18)
- # clojure-norway (7)
- # clojurescript (8)
- # clojureverse-ops (3)
- # cursive (5)
- # datomic (4)
- # emacs (20)
- # exercism (2)
- # lsp (58)
- # off-topic (32)
- # polylith (11)
- # reitit (7)
- # tools-build (7)
- # xtdb (4)
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/
Pretty good, but I wish it discussed a bit more the relationship with velocity, estimates, and conflicting priorities.
The company is not related to Clojure and they are just self-promoting. Their posts have been removed as spam and the user deactivated.
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.
That last part is mitigated by structural typing and inference though, where a type is defined by its structure and not by its name.
Around the 24 minute mark briefly summarizes what I think about runtime errors — the bugs causing them all passed the type checker…
This debate is not unlike asking "should you show up with a dress shirt, or a bulletproof vest?" The answer is completely context-dependent. 🙂
It is but this "bullet proof vest" is overly large/heavy and wouldn't even be effective at stopping a sharp stick.
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.
> 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.
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.
"The only thing I do in this department is fix people's Emacs" I probably do that once a week indeed 😂
Same with vim
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 😀
Well it likes waterfalls and cliffs... Don't break your legs and eyes and whatever you have.
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.
For now I want to stick to standard library. But yeah... your suggested library basically implements ->
in python :thinking_face:
Chopped snake is a tame snake. This backslash works the same as in bash:
> 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