Clojurians
#hoplon
<
2016-01-03
>

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

mynomoto01:01:10

@laforge49: https://github.com/hoplon/javelin/commit/da9fb7439021a94ef4c92fc956c8600005eae900 is kind of a bad practice. Those kind of things should be in your global gitignore, not on each project. See https://help.github.com/articles/ignoring-files/#create-a-global-gitignore

mynomoto01:01:58

Except for the project.clj that probably makes sense. :wink:

laforge4901:01:16

This is one of the many perks of not working in isolation. Many thanks @mynomoto ! :simple_smile:

laforge4901:01:48

But one question. What happens if someone else writes those ide files to the repository. Will they not then overwrite my project files? Isn't it better to prevent everyone's ide files from being written to the common repository? With cursive growing in popularity, this becomes a growing issue.

mynomoto16:01:07

@laforge49: that's a good question, I only used Cursive for a couple of weeks before going back to vim. In general those things would be caught on PRs before getting merged so I don't think that would be a big problem.

mynomoto19:01:54

I converted the petrol examples (https://github.com/krisajenkins/petrol) to hoplon, they are an interesting pattern for applications inspired on Elm. The code is at https://github.com/hoplon/demos/tree/master/petrol

micha19:01:27

@mynomoto: interesting!

micha19:01:43

do you find the explicit types helpful?

micha19:01:53

i have to say i don't really see the benefit there over just functions

mynomoto19:01:58

There are no types on petrol, it's only the way components communicate and compose

micha19:01:19

i mean Message protocol

micha19:01:32

that's basically just a way to annotate messages with types

micha19:01:45

otherwise you could just call functions directly

mynomoto19:01:45

oh, I think that is for efficient dispatch more that types.

micha19:01:09

cause that's the main thing with elm, from the docs

micha19:01:17

extending types to the messages

micha19:01:27

so they can have compile time type checking

mynomoto19:01:38

The advantage I see is that the ui has no need to know about the app structure, only publish messages.

micha19:01:57

but passing a function would be the same, no?

micha20:01:09

there is no way for the ul to know where the function came from or what it does

micha20:01:25

i mean ui

micha20:01:59

not that i'm knocking the demo, which is sweet

mynomoto20:01:14

But then you would need to pass lots of functions right? Instead of one channel?

micha20:01:10

i mean you need one function for increment, and one for decrement

micha20:01:14

like in the counter example

micha20:01:28

but you need those two things there too

micha20:01:39

just as typed objects instead of closures

mynomoto20:01:26

So look at the multicounter example. There is no advantage on the small examples realy

micha20:01:48

whenever i've thought that a message bus was the thing i needed i've always regretted the decision later :simple_smile:

mynomoto20:01:24

I know the feeling, I used a horrible one for too long. But this one is different :stuck_out_tongue:

mynomoto20:01:22

The multicounter uses the counter2 ui as it was defined only forwarding messages to the component. The subcomponent don't need to know anything about the structure of the bigger component.

mynomoto20:01:57

Or the hydra one for a more complex example.

micha20:01:23

what is the (m/->SendChangeMessage) syntax?

mynomoto20:01:23

But those patterns are useful if you go to the one big atom church. They don't make sense if components have local state and are responsible for it.

micha20:01:52

yeah i am not a fan of the big atom lol

mynomoto20:01:52

Where is that? It creates a record with no arguments right?

micha20:01:03

oh, so like

micha20:01:28

(m/->ModifyCounter delta) is the same as (m/ModifyCounter. delta)?

mynomoto20:01:45

I'm usually not a fan either but this pattern at least make it sane for building apps using it.

mynomoto20:01:58

Yes, it's sytax sugar.

micha20:01:06

interesting, never heard of that before

micha20:01:11

is it also in clojure?

micha20:01:55

strange though, i wonder what that came out of?

micha20:01:10

is the dot notation problematic in some cases?

micha20:01:50

maybe it's a cljc thing, like some reason why the dot wouldn't work cross-platform or something?

mynomoto20:01:48

Don't know, don't use them often...

micha20:01:56

anyway the demo is very well done and clean, i like it!

micha20:01:17

i will play around with it a bit and compare to the small atom approach

mynomoto20:01:13

Kris Jenkins is the one to thank for, I only did a conversion. Only needed to change 2 functions of the library to make it hoplon friendly.

micha20:01:09

i really like how scheme-ish all the examples end up being

micha20:01:24

parens all over the place

mynomoto20:01:29

Yeah, I like that a lot too. If elm had hoplon syntax including the way things can be combined it would be perfect. Static type checking is a powerful thing for big apps.

micha20:01:04

i think it's a double edged sword, too though

micha20:01:36

i guess i need to use haskell for real one day

mynomoto20:01:00

It always has trade offs but it's more useful as the app grows. Useful error messages are a win too, elm has the best ones ever, really amazing.

micha20:01:13

ah, the fact that they're regular functions is the thing

micha20:01:23

that does seem pretty useful

mynomoto20:01:32

can be used with apply among other things...

micha20:01:46

yeah, and usually people make ad-hoc solutions there

micha20:01:00

this handles the common case in a uniform way, which is nice

micha20:01:07

and enliminates that boilerplate of course

micha20:01:22

macros ftw yet again

micha20:01:12

getting macros in lisp is like prometheus giving humans fire

micha20:01:20

now we can do anything

micha20:01:46

pretty soon we'll go to the moon

raymcdermott20:01:33

yeah, travelling to the moon is pretty much boiler-plate at this stage :wink:

mynomoto20:01:57

Yeah, macros are amazing.

micha20:01:19

usually you'd need to change the whole language to make something like that

micha20:01:25

in a non-lisp language that is

mynomoto20:01:10

I would like to see what kind of code people put on space shuttles and rockets. And how they check if it does what it should.

micha20:01:41

i was reading about either the new airbus or the 777, i forget which

micha20:01:47

but they have a fly by wire system

micha20:01:52

all computerized

micha20:01:05

so they actually run the code on 3 different types of hardware

micha20:01:19

in case there is a bug in the processor or something

micha20:01:29

that emerges during the flight

micha20:01:42

and they also compile the code with different compilers too

micha20:01:51

to make sure compiler bugs are caught

micha20:01:55

by consensus

micha20:01:03

while the plane is in the air

mynomoto20:01:17

static types? formal proofs? tdd? lol

micha20:01:25

program might crash or become faulty on one instance but it will just use the others then

micha20:01:31

i don't think they do that

mynomoto20:01:03

3 different hardware is interesting

micha20:01:06

i would enjoy learning about it though

micha20:01:18

my brother works on oil drilling ships

micha20:01:32

he was telling me about the software they have to control the rig

micha20:01:41

pretty interesting

mynomoto20:01:01

I read something about nasa but to few details. There is a spec and there is translation to code. And they said its about it.

micha20:01:40

on a drillship there are humans interacting directly with massive dangerous computer controlled equipment

micha20:01:56

if things go wrong there people can die in a split second

micha20:01:10

cause the things they're moving around and handling weigh tons

micha20:01:15

and are moving fast

micha20:01:50

they use token ring networks on the ships

mynomoto20:01:33

That should be interesting in the same way. Everything that cannot fail for one reason or another needs to have better processes at least.

micha20:01:33

to guarantee availability, so no single node can saturate the network and prevent other nodes from sending messages

micha20:01:08

they have plenty of time, those guys

micha20:01:19

probably spend months on a single page of code

micha20:01:36

that's what i imagine, anyway

mynomoto20:01:08

Not quite sure of that, there is too much code to be written to take so long on it. But certainly slower than web apps :wink:

micha20:01:07

the voyager spacecraft had a program on it that was almost an entire career for one dude, i think

micha20:01:24

a pretty small program, but perfect

micha20:01:38

although this may just be a myth

micha20:01:00

i think it was like 40,000 hours

micha20:01:06

or something

mynomoto20:01:26

People should write more about that instead of new js frameworks...

mynomoto20:01:56

wow, 40000 hours is something like 20 working years. Pretty impressive amount of time

micha20:01:56

maybe he worked late

micha20:01:04

and did it in 10 years

mynomoto20:01:30

yeah, and on weekends too and took no vacations it could be possible. I'm worst than useless working late, lots of bugs born this way.

micha20:01:14

same here