Fork me on GitHub
#clojure-uk
<
2017-06-06
>
yogidevbear06:06:11

umawn šŸ”„

thomas07:06:34

morning šŸ˜¼ mogge

agile_geek07:06:12

@glenjamin I like that analogy. I think of Monadic types as making side effects explicit...not sure how acurate that it but it's my mental model to make up for my deficiency in category theory!

mccraigmccraig08:06:01

@agile_geek the IO trick sounds mysterious, but it's pretty simple - here's lux's definition of IO - https://github.com/LuxLang/lux/blob/master/stdlib/source/lux/io.lux#L11 - so an (IO a) (where a is a type variable representing any type) is under the hood a function which takes a Void argument and returns an a

mccraigmccraig08:06:28

and while running such a function results in impure side-effects, creating the function itself is pure - and it's the creation of the function that gets statically type-checked - which is where the idea of 'hiding' comes from - it's semantically equivalent to 'delaying'

agile_geek08:06:32

@mccraigmccraig ah, that makes sense. Is Lux your next language of choice by any chance?

mccraigmccraig08:06:02

@agile_geek i'm investing time in to it atm to learn it properly, and it's looking excellent so far... but i am not fully committed yet

agile_geek08:06:11

I worry...I am all for the right tool for the job but in moving from language to language are we (as an industry, not you and I as individuals!) doomed to keep reinventing the wheel?

mccraigmccraig08:06:17

i don't think so - i think we need to strive for better languages

glenjamin08:06:23

the explanation that stuck with me is that IO a is a type which will produce a after IO has been performed. So semantically it acts like a tag on the type of a, and in terms of execution itā€™s an instruction for the interpreter to do that I/O at some point

mccraigmccraig08:06:12

my current position is a good example - i'm a big lisp fan - the minimal syntax and macros make lisps much more flexible than non-lisps, and clojure's functional nature (easy closures, immutable DS) make it an improvement on most other lisps, but i am heartily sick of having to track down errors which could have been caught at compile time - the whole point of computers is to automate the things that can be automated and leave the thinking machines to to the things they do best, which is most definitely not tracking down another pointless NPE. hence i went looking for a lisp with a mathematically validated static type checker, because if it is well done it will free me from the tyranny of the NPE

mccraigmccraig08:06:14

i could have switched to haskell, but haskell keeps needing compiler mods where a lisp would only need a macro, so haskell also seems lacking

Rachel Westmacott08:06:50

@mccraigmccraig if you don't find the type-checked lisp you are looking for, will you write it?

glenjamin08:06:38

thereā€™s a guy in my office who thinks haskell is amazing but wonā€™t try learning clojure because of parens šŸ˜ž

dotemacs09:06:38

glenjamin: maybe explain to him that he doesnā€™t have to limit himself to the way editors worked 60 years ago: editing text line by lineā€¦ if he understand sexps heā€™ll stop seeing the parens

glenjamin09:06:23

I did vaguely try, but he doesnā€™t appear to want to have his mind changed, and the project we work on is in javascript anyway

glenjamin09:06:30

maybe iā€™ll try again another time

Rachel Westmacott09:06:42

I find that there are the same number of brackets in clojure as in javascript, just less of everything else.

thomas08:06:50

@mccraigmccraig I think I agree with you.

glenjamin08:06:14

I have had good experiences with gradual typing with flow in JS

glenjamin08:06:31

great inference, and it catches some errors early

glenjamin08:06:48

and makes rename / signature refactorings much easier

mccraigmccraig08:06:17

@peterwestmacott i would like to think so - but i am not sure i am up to it

glenjamin08:06:19

but i donā€™t think it has prevented any bugs in practice, because those errors would have been caught by unit tests - or were simply unreachable paths in practice

glenjamin08:06:48

one thing i have found, is that if i start a new project in a good strongly typed language, iā€™m really lazy about writing unit tests at the start

glenjamin08:06:07

because the types give me (false) confidence that everything will ā€œworkā€ correctly

glenjamin08:06:34

so while I wonā€™t get any runtime errors, my code will still be wrong in subtle ways, or hard to change because i have no regression pack

Rachel Westmacott09:06:10

"wonā€™t try learning clojure because of parens" I really can't understand this. Have people never heard about judging books by their covers?

practicalli-johnny16:06:50

peterwestmacott: its like refusing to use json because of the weird way it uses commas (although that seems to me to be a more reasonable argument)

seancorfield19:06:20

Besides, if you look at the average Java program and the equivalent Clojure code, there are likely fewer parens/brackets/braces in the Clojure code!

mccraigmccraig09:06:05

@glenjamin perhaps a convincing argument - in haskell applicative-do is a compiler mod - https://ghc.haskell.org/trac/ghc/wiki/ApplicativeDo . in a lisp, it's just a macro

mccraigmccraig09:06:13

and then show him this - type-classes as a macro - https://github.com/LuxLang/lux/blob/master/stdlib/source/lux/type/auto.lux#L307 - in lux macros are run in a state-monad with the full compiler state, and syntax macros use parser-combinators to destructure the source AST for the macro to process - and it's the parens which make this plausible

mccraigmccraig09:06:14

hmm. that's not entirely fair - you could have compiler-state-monad macros in haskell along with AST parser-combinators - but parens make the mental model required to write macros very simple

glenjamin09:06:04

i dunno if itā€™s the parens as such, but more the fact that thereā€™s so little syntax

glenjamin09:06:18

so building valid syntax trees is relatively straightforward

agile_geek09:06:29

@glenjamin I think you have a valid point around 'developer discipline' in writing tests but my big worry in the Clojure community is I often hear "why do I need tests, I have a REPL". Personally this argument doesn't hold water. Unless you enjoy retrying every REPL experiment in every change (I don't) and I find well written tests a great vehicle for communication (executable docs).

agile_geek09:06:25

I think not writing tests is an act of laziness and, dare I say it, unprofessional. Bit like not documenting your external API's!

glenjamin09:06:11

itā€™s often hubris

agile_geek09:06:54

Personally, I have to write tests (and I have to do it alongside my implementation - I use TDD YMMV) because I'm not a very good at holding a mental model of every concept in my head at once and I often break stuff!

agile_geek09:06:06

So it's an act of self preservation!

glenjamin09:06:30

i recommend reading that article for gaining a good vocabulary for talking about approaches to testing though, it talks about getting away from value judgements like laziness or professionalism

mccraigmccraig09:06:20

i don't entirely agree - i often don't write tests on a new project when i don't yet know what i'm doing or where i'm going. later on i go back and write tests, and i'm more likely to start out by writing tests TDD style, or hand-in-hand with RDD, on a project which is already 'solidified'

Rachel Westmacott10:06:54

mccraigmccraig: its certainly very hard to write the tests upfront when doing exploratory coding!

agile_geek09:06:54

Like I said YMMV. I don't have the discipline to write my tests after the fact so I tend to write them TDD and refactor them if required. Probably slower but works for me.

mccraigmccraig09:06:21

i do feel exposed without tests - like cycling without a helmet - and that gives me the motivation to write them

thomas09:06:29

@mccraigmccraig I have never cycled with a helmet šŸ˜‰ šŸš²

thomas09:06:15

I do write tests though

mccraigmccraig09:06:05

@thomas 99% of my cycling is off-road - and despite my best intentions i do come off with distressing regularity

thomas09:06:58

aaah ok in that case it makes sense. I tend to stick to the cycling paths

glenjamin09:06:44

that metaphor might extend to tests šŸ˜„

thomas09:06:45

which reminds me... I saw two people the other day with cycling helmets on what looked like normal road bikes... but they were so fast I suspect they had e-bikes.

glenjamin09:06:02

but yeah, i recommend people read that article above, itā€™s very relevant to this discussion

agile_geek09:06:15

I've saved it for lunchtime reading

thomas10:06:52

good read @glenjamin thank you for the link. It certainly had a few reminders and a few new points.

agile_geek11:06:20

Some of those points are similar to the ones I've made myself in my own blogs on TDD.

maleghast11:06:25

That Devmynd article is really good - thanks @glenjamin

practicalli-johnny16:06:50

peterwestmacott: its like refusing to use json because of the weird way it uses commas (although that seems to me to be a more reasonable argument)

yogidevbear19:06:48

What do the experienced speakers in the room use for doing presentations at conferences? Is powerpoint the "go to" software or are there swankier options?

thomas20:06:28

@yogidevbear I would say what ever you feel comfortable with.

thomas20:06:07

and if you really wanna stand out use an overhead projector. very old skool

seancorfield20:06:11

@yogidevbear PPT is kinda the default and what Iā€™ve generally used for most of my talks. Iā€™ve also used Appleā€™s presentation software which I like a lot more than PPT (but is not as portable, of course, and Iā€™ve needed to fallback to a loaned non-Mac laptop a few times).

seancorfield20:06:11

Iā€™ve dabbled with some of the JS-based presentation tools and theyā€™re nice in that you get both ā€œnext pageā€ and ā€œnext sectionā€ navigation easily, as well as being able to jump into browser-based demos too if you need that.

mccraigmccraig20:06:45

i like (apple's) keynote because i can edit the presentations on my phone as well as my laptop, and the few times i have ever given presentations i always seem to be still editing them at the last minute while travelling

seancorfield20:06:10

Much depends on whether you want to leverage ā€œspeaker notesā€ live while youā€™re presenting (can make it more complex for presenting since you need non-mirrored screen projection but can also make sure you remember all your talking points).

yogidevbear20:06:17

Sounds like PPT is what it'll be (I'm on Windows so Mac options not really an option)

seancorfield20:06:05

Keep the theme very simple and legible. Large, dark font on light background works best IME. Also remember that code fragments need to be small (in terms of lines) and a large monospace font so they can be read from the back of the room.

yogidevbear20:06:26

I might try do a js browser based version, but don't want to waste too much time getting distracted by getting the presentation to actually work like I'm expecting it to

seancorfield20:06:09

Keep slides to seven bullet points at most (if you can). Use images to elaborate points if applicable. Donā€™t read your slides (thatā€™s why you want ā€œspeaker notesā€ for most slides).

seancorfield20:06:55

@mccraigmccraig I have a terrible habit of completely rewriting my talks the night before I give themā€¦ sometimes the hour before I give them šŸ˜

mccraigmccraig20:06:51

i've always been last-minute @seancorfield , but quite good at judging when the last last-minute is. maybe it's a personality characteristic thing

glenjamin21:06:30

personally i prefer large light text on a dark background, if the room is dark the big white screen can be a bit bright

glenjamin21:06:49

i like to aim for one point per slide

glenjamin21:06:07

sometimes iā€™ll use bullets if i want people to be able to still read the last few things i said

seancorfield21:06:44

Most of the conference rooms Iā€™ve presented in have been fairly well-lit ā€” but, yeah, it definitely depends on the location. Be prepared to switch from black-on-white to white-on-black at the last minute if you need to šŸ™‚

dominicm23:06:27

I use deck.js via asciidoc. Very quick to write.