Fork me on GitHub

Good Morning!


@otfrom with the greeting double-tap


@alex.lynham I think @otfrom was testing his shift key 🙂


@alex.lynham I fell asleep in between

Wes Hall10:06:50

Stand by, I have an insight! As mentioned earlier, I have been studying some typescript really as something interesting to do. Been a while since I used a typed language. Something I have definitely noticed though is that the kind of programming I would be doing in Clojure, that of building lots of small little helper functions... lego infrastructure basically, is a terribly bad idea in ts. It's hell on earth to get such things to properly preserve types in the way you want them, requiring a lot of generics, conditional types, union / intersections in types, and engaging in an epic battle with the type checkers desire to widen everything. I entirely get the notion that type checkers catch bugs, but I am now wondering whether the way such languages discourage the kind of reusable infrastructure approach common to untyped languages (particularly Clojure due to homoiconicity / macros), actually balances this out. "Why don't you factor this stuff into a common library?" "Because i'd spend three weeks making the types work properly!" Is, I imagine, a fairly common exchange in TS shops.


i don't know typescript at all, but from my limited experience the haskell and lux stdlibs both seem to have plenty of small packages which get re-used a lot... maybe it just takes a while to grok the patterns in making such packages ?

Wes Hall10:06:01

@mccraigmccraig There are definitely such libraries in TS too. I have been studying a few of them, but the barriers to creating them are rather high. I actually emailed the author of one of them to ask him if he would take a moment to explain to me some obscure use of the type system notion (and he was kind enough to respond with an explanation). It definitely can be done, but the complexity of creating reusable infrastructure in languages with complicated type systems seems to be extraordinarily high. You really do need to be an expert in the type system notion. I am slightly uncomfortable with the notion that refactoring common code into utilities is a job only for experts.

Wes Hall10:06:06

An example.... ts supports string literals as types indicating that a string can only have that value, same for other core primitives. This can be quite useful because if you have objects with say a 'type' field that acts as a discriminator you can create a union of these types (think redux actions etc), and the type checker can do exhaustiveness checks on switch statements etc because the union ultimately becomes type: 'foo' | 'bar' etc. Now try refactoring something like this into common infrastructure without causing that type field to widen to simply 'string'. It can be done... i've seen it done.... but you have to fight it every step of the way.


isn't the difference between n00b and expert mostly just time and effort ? it might seem easy to extract utilities in a dynlang, but you've been doing it for ages (i assume) - most people who are just beginning produce pretty crappy libraries. perhaps the different in a statically checked lang is that you can't get your crappy abstractions to compile - which doesn't sound like an awful thing 😬

Wes Hall10:06:10

Sure, but when you can't get your crappy abstractions to compile, what do you do? Do you not bother creating the abstractions (this may actually be advisable), or do you just mark everything as, "any" and just move on. Essentially this is what untyped languages do, but then users of your abstraction don't expect type checking.

Wes Hall10:06:52

Don't get me wrong here, I actually think TS is rather nice. Preferable to pure JS by some margin, but I think the insight is probably to break the habit of being extraordinarily committed to principals like, "DRY". In Clojure I refactor out repetitions without even considering it too much because it is incredibly straightforward to do that. In TS the form seems to be to resist that urge.

Wes Hall10:06:36

Here is a single type definition in TS from a library that does more or less what I described above...

Wes Hall10:06:55

export type ActionBuilderConstructor<
  TType extends TypeConstant,
  TPayload extends any = undefined,
  TMeta extends any = undefined
> = [TMeta] extends [undefined]
  ? [TPayload] extends [undefined]
    ? unknown extends TPayload
      ? PayloadAC<TType, TPayload>
      : unknown extends TMeta
      ? PayloadMetaAC<TType, TPayload, TMeta>
      : EmptyAC<TType>
    : PayloadAC<TType, TPayload>
  : PayloadMetaAC<TType, TPayload, TMeta>;


never used typescript but this looks a bit mental Especially as it ultimately resolves to three possible types so a less expressive/correct type signature would be: PayloadAC<...> | PayloadMetaAc<...> | EmptyAC I guess this is really a case of shifting some business logic into your type system so that your compiler can "prove" things about your program, the downside being that you have to be able to express control flow in your type system which is an alien syntax. And who proves your types are correct 🤷 On your point re. Clojure idioms in TS that's an interesting discussion - Rich Hickey has gone on the record to be anti- static-types because he thinks being able to "prove" things about your program is a separate skill/concern to being able to express how your program should work (the latter being possibly the more useful/pragmatic of the two concerns) Quite a lot of Clojure/lisp idioms are quite hard to prove from a type-theory perspective: Though there's another question of whether Clojure idioms are "appropriate" for a language like TS which may also explain why some of the patterns you are using are hard to type - IIRC TS was meant to feel like C# in Javascript... If you tried to write Scheme in Java or C in Haskell there's an argument that you might find it hard to do so too.


anyway just some musings of my own

Wes Hall10:06:30

There are a few of these in that file, and quite a lot more simpler definitions too.

Wes Hall10:06:38

It's a complicated world all of this 🙂

Wes Hall10:06:15

By the way, brownie points for anybody who can tell me what those square brackets do there without looking it up 😉

Wes Hall10:06:23

This is actually the query that I emailed the author.


:man-shrugging: dunno - that looks pretty horrible, but i don't recall seeing similar horrors like that in the lux or haskell code i've read, so maybe it's a feature of TS' type system, rather than type systems in general ?

Wes Hall10:06:41

Entirely possible, I do have a few haskell books in my library but if I am honest, I am using them the way most people leave an unread copy of, "brief history of time" on their coffee table 😉

Wes Hall10:06:41

Though I will say this, I do remember having similar problems with Java's type system which is far more basic than TS (or rather was, last I used it, I am a bit behind on developments in the Java language now).

Wes Hall10:06:45

When they introduced generics, in... I guess Java 5. I can remember spending quite a lot of time discussing covariance vs contravarience and all these other little nuances.


I think this speaks more about the specific type system you're using than anything


ocaml type signatures are nowhere near that complex in general


any type system which allows NPEs should leave the room


neither are most haskell ones

Wes Hall10:06:00

Also, when I was at eBay we tried a scala project which was a fairly significant failure. Plan was to put a team together consisting of a couple of language wonks with some less experienced people in order to do some cross-training. Result was the opposite. Language wonks spent a lot of their time beard stroking about various subtlties (mostly around types), less experienced spent their time getting more and more confused.


scala is also pretty bad in this respect, depending on which "flavour" of scala you're using

Wes Hall10:06:33

There are flavours?


the scala type system supports a lot of wildly different features, teams often restrict themseves to a specific subset

Wes Hall10:06:19

@bronsa By the way, I would be doing the language a disservice to suggest that TS types are usually like this, though I think the way you keep them simple is to resist the urge to refactor out all commonality. I am just so used to doing this in clojure it has become a habit, and perhaps a bad one with respect to other tools.


you can try to write scala as if it was haskell, or as if it was java, to give a stupid down to earth example

Wes Hall10:06:48

Oh, I see what you mean. "Self-inflicted" flavours.

Wes Hall10:06:43

Need some strong enforcement of that I imagine. For people that do understand (or believe they understand) the heavily nuanced stuff, sounds a bit like handing a kid a box of crayons and then demanding they don't play with the blue ones 🙂

Wes Hall10:06:54

I don't mean to be as condescending as that sounds, but you see this kind of thing quite a lot. Usually the guy who actually does understand it all builds all the clever infrastructure.... then takes that job at Google and leaves you with a bunch of code that nobody else can really maintain.

Wes Hall10:06:05

It's easy to tell people not to use language features that don't work well, but far harder to tell them not to use powerful features because they might introduce more complexity than can be handled.


Without going all Harrison Bergeron on it, overly clever code is bad


Scala devs are particularly bad about it and Scala unhelpfully gives you many ways to shoot yourself anywhere you like

Wes Hall10:06:25

I very much agree with this. Defining the crossover for, "overly clever" is rather hard and varies not only from team to team, dev to dev, but also from language to language. There are certain things I do in Clojure as utterly routine, like higher order functions, or function factories, that would probably cross the line in other languages, or easily could.

Wes Hall10:06:45

These kinds of constructs in pre-lambda Java for example, were pretty crazy, with a bunch of single method interfaces etc etc. Back to Steve Yegge's, "execution in the kingdom of the nouns" stuff.

Wes Hall11:06:08

In any case, I just felt that mentioning an observation / insight that I recently had here would trigger an interesting discussion and you guys didn't disappoint 🙂. I should probably get back to hacking my Clojure, but food for thought. Thank you.


Following on from yesterday's discussion about indentation and Git commits… A while ago I wrote a Git hook in Bash and Planck that allows everyone on a team to use whatever indentation they like. If there's interest, I'll look into tidying it up and getting it into a state where other people could use it with some confidence. If you think you might find useful, please reply! Some details: • After pulling, you indent the code as you like. (To make things easy for me, I added an Emacs command to re-indent all Clojure and ClojureScript files in a project and create a whitespace-change commit.) • When you push, a hook rewrites commits to use the canonical indentation. This is done with cljfmt, using options that only change indentation. • Any commits that only change indentation are discarded. • After the rewritten commits are pushed, a new local commit is created with your local indentation. • It takes care to keep your untracked files, worktree and staged files as they were. (That was pretty fiddly.) For anyone super-interested, there might be enough information in the README to give it a go. If not, just ask. It's at I've tested it with: - lein-cljfmt 0.6.4 - Leiningen 2.9.0 - Git 2.16.1 - Planck 2.19.0 - Clojure 1.10.0 - Bash 3.2.57 (which is really old, but is what comes with macOS; maybe I should upgrade) - macOS High Sierra 10.13.6


Note that it only changes indentation, not whitespace in the middle of a line.


It allows you to avoid discussions about what indentation is "best", and just do your own thing.


Oh, if you try it out now, do it on a repo that you don't mind trashing! Just in case there are nasty bugs. (So maybe create a copy of a repo to experiment on.)


Man, archlinux. what a great distro! Actually getting stuff into AUR is soooo easy comparied to debian-based distros.


This is not always a good thing! I stopped using RedHat after the first few weeks as I was forever hitting issues with badly put together packages. I've used Debian/Ubuntu since 95 and they have been rock solid, never any intractable issues with package conflicts. Even the occasional personal package archive has never caused issues as they use the same tooling.


Arch failed to even install on this laptop, even after a weekend of trying to get it to work.


Anything that is not in debian just gets installed in my /bin or /app directories, which is rarely needed.


🙂 My first introduction to Linux was Debian, many many moons ago. Always a soft spot for it.


Debian in 1995 made Linux for me. I had been using Slackware the year before, when the install came on 84 floppy disks. The move from slackware showed me how important a well organized package management system was. That's ingrained now and hard to see the benefits of other approaches. I did get arch going on an older laptop, in the hope of creating a highly optimised experience. After a month it was no different in terms of resource usage than Ubuntu.


I think Arch is a great way to Learn Linux and dive into the details of how an operating system works.


I just want something to run Emacs efficiently (and Java, Leiningen, browser, obs, etc). Something with a keyboard driven desktop.


I am still in two minds about switching to a tilling desktop (Ubuntu is also a basic tilling desktop). If I could drop Gnome for something else that give the same experience but with less resources, I would


It's the Browser that eats most of my memory though 😁


For me, Arch has been a revelation. I have a deeper understanding now of the entire boot, through to prompt experience. All my packages are constantly up to date and as a rolling release I never have to worry about a "big bang" update every 6 months (that of course, may not be a good thing in some people's eyes). Since I'm rolling with the latest, I get the latest features and bugfixes to the critical software that I use. I actually find Arch a lesser drain on resources than Ubuntu as it only installed what I want it to install - plus anything that installs as a service isn't automatically started (unlike ubuntu or debian) unless you tell it explicitly. I use i3 as a window manager and will never go back to another window manager. Having a tiling window manager has changed for the better my way of working.


I use firefox for most of my stuff now, as I'm not liking the eroding of privacy (and monopoly) that Chrome is bringing.


I also come from a BSD background and the AUR repo is akin to the Ports repository on FreeBSD, making builds of software trivial.


and for me to take over maintership of an AUR package took all of 10 minutes to do, along with my first release into the AUR repo. On debian, being a maintainer of software is painful. There are numerous articles on t'interwebs on the non-triviality of being a debian package mantainer.


Did you get anywhere looking for a new laptop? Arch runs perfectly on my X1 Extreme 🙂


Thanks for the insights. I am not missing out on any updates and I run the latest snapshot of Emacs. It's Emacs that is important to me, not the operating system (mainly why Ubuntu is a much better fit). I run about 10 apps and services and that's it really. I just want things to work when I want to do something. I appreciate that Arch has a lot of benefits, none of them are that important to me though. I enjoy the simplicity of Ubuntu which just gets out of the way. I like that Debian packages have a specific process.


I am not employed at the momentum, so will wait to get my next laptop. The Extreme 2 looks very nice, though it won't be available in the UK until the end of the year. I'll probably wait until then to buy.


Then the extreme 3 will be nearly out....


just gotta say 🙂


Hey folks got a off topic question, i’ve got a friend who studied psychology but er wants to get into pen testing. I’ve never done pen testing before, just normal QA, but what would you folks suggest for my friend to go away and learn? I was going to say learn a bit of coding and learn about linux a bit too.


From my limited knowledge, re the linux thing, it might be worth them investing some time playing around with kali linux


Yeah thats what he said he was installing, is it just a pen tester pre set up linux distro?


So i was just going to teach him some basics and maybe some git stuff too


Sounds sensible. Gotta start somewhere 🙂

👍 4

Thats what i was thinking yeah 😅

Edward Hughes19:06:57

Archlinux with BlackArch installed on top is another good distro for pentesting. Might be better for them to learn Linux on an Arch distro like Manjaro if they're new to it.


specifically the syllabus


those are the requirements to be a certified pentester here in the uk


there is another one called CHECK as well, but I couldn’t find the syllabus


Oh agree, definitely check those out


ctf competitions. Also there are multiple infosec people on twitter worth following


also ages ago found this:


(they also now have a serverless goat looks like )


Thanks @UAEFFG05B and @U82DUDVMH thats great!! I forgot about the OWASP thing but didn’t know about CREST at all.

👍 4

I worked with a guy who went on to work for Google as a pen tester. He was initially some sort of business person but then figured he liked tech, saw that pen testers are paid well, so he concentrated on that. Apart from self study he enrolled at a bunch of pen test competitions and placed high, 1st or 2nd. Google approached him and gave him a job offer just based off of that. He then went to work for them to learn as much as he can.

👍 4

I would suggest creating a little mini network internally, with a few VM hosts (linux/windows/mac)


so i’m pretty bad at networking stuff, how would i go about doing that? so i can then show my friend? What would you google for a tutorial to get that haha? then i can go try it


and try to hack him/her self.


(using kali as suggested)

👍 8