Fork me on GitHub
#boot
<
2016-01-03
>
seancorfield05:01:14

Out of curiosity, what's the overall plan for 2.6.0?

seancorfield05:01:23

And is there an ETA?

seancorfield05:01:06

There isn't a milestone on GitHub for 2.6 (just 2.5.0 - completed, past - 3.0.0 and "future")

magomimmo12:01:54

https://github.com/magomimmo/modern-cljs has been fully ported to latest 2.5.5 stable release of boot

pesterhazy12:01:27

@magomimmo: wow thit looks great

pesterhazy12:01:40

it's a good idea to dive into the build tools, even for a introductory tutorial

magomimmo12:01:59

@pesterhazy: I still have to decide about the next tutorial: three choices at the moment:

pesterhazy13:01:21

just yesterday I wrestled with lein cljsbuild, if you don't know the ins and outs of the clojurescript build pipeline, it's a nightmare

magomimmo13:01:51

yes, I know what are you talking about..

magomimmo13:01:09

I was say that the choices at the moment are the following: core.async, react stuff, dependencies scope and other housekeeping stuff

jaen13:01:51

I would probably do reagent or something, to show the modern alternative to the domina stuff you showcased.

pesterhazy13:01:17

reagent would be cool (though possibly incompatible with some of the other tutorials like enlive)

pesterhazy13:01:40

wow there's so much stuff in modern cljs that I should check out!

pesterhazy13:01:16

personally, more housekeeping documentation would be great as well

magomimmo13:01:01

I want to take a look at rum and re-frame before decide about the next tutorial

jaen13:01:14

Well, I think re-frame is a bit too advanced for a first React tutorial to be honest.

jaen13:01:23

But taking a look at rum seems sensible

pesterhazy13:01:12

yeah, re-frame already assumes familiarity with reagent

jaen13:01:26

I'm not sure if it would be friendlier for a beginner or not, but for example the ability to use mixins in rum is powerful.

magomimmo13:01:49

reagent is so intuitive….

jaen13:01:25

At first glance

jaen13:01:37

I mean, yeah, it seems so simple for a newcomer

jaen13:01:45

But there are a few gotchas in how it works internally

jaen13:01:54

re-frame tutorials explain those really well

magomimmo13:01:24

yes I read them…very nice...

jaen13:01:47

Certainly reagent is a better choice for a newcomer than om to me

jaen13:01:55

But rum could be an interesting choice to, I suppose.

magomimmo13:01:38

I should admit that I never took a look at OM, because recently I worked a lot on nodejs on SoC. But anything touched by @dnolen gets diamantine in a moment

magomimmo13:01:13

perhaps all of them simple_smile

jaen13:01:45

Well, to me om.prev is too confusing and verbose and om.next while largely aligns with what I think will be the future of webapps - it just tackles problem a newcomer won't have for a while.

jaen13:01:55

So I don't think either of oms are good introductory tools.

jaen13:01:59

But that's just me.

jaen13:01:42

There's also quiescent and brutha, I think, but I have no experience with those at all, so I'm not sure how they compare.

magomimmo13:01:02

thanks for the suggestion…I’ll see next week...

jaen13:01:03

Sure. Keep up the good work : )

magomimmo13:01:57

@jaen: and @pesterhazy what about a tutorial on making a lib portable?

jaen13:01:38

Between Clojure and Clojurescript?

jaen13:01:38

Hmm, that sounds interesting, but I think showing people the proper alternative to domina/jayq/etc. is more important

magomimmo13:01:16

sure, but I have many tutorials to be added. even on electron, react native, etc…they will take some time and efforts, but I enjoy to be useful for someone

pesterhazy13:01:10

Maybe a little too specialized...

jaen13:01:43

Well, both those you mention have a quite hard dependency on showing React though

magomimmo13:01:03

yes to both of you….I’ll take the time to think about the order….I still have to find a way to leave some room for UX designers in the new web…the SPA model seems to be a little aggressive with them…there should be a way (enfocus/enlive like) to keep them in touch with us as programmers

jaen13:01:35

Well, there's https://github.com/ckirkendall/kioo if your designer can deal only in HTML and CSS and nothing more

jaen13:01:02

Using it with boot-middleman so they have more familiar Ruby workflow is a pretty good way to not let designers to be alienated

jaen13:01:12

Though it's a bit more annoying for the developers to be honest

magomimmo13:01:12

thanks! I’m going to take a look at it….my god, you know any single lib on the clojure planet

jaen13:01:56

Not every single.

jaen13:01:11

But I tend to remember a lot of things for some reason.

jaen13:01:04

I've used kioo though, even contributed a few fixes. It's great if you have HTML templates from an outsourced designer (that was my use case)

magomimmo13:01:22

I just realised that kioo is by the same guy I did somestuff in the past on enfocus...

jaen13:01:49

But creating form-2 components with reagent was a bit annoying - you basically had to have two functions - one for the component, and the other one that is the form-2 you close over things in.

jaen13:01:19

I guess you could somehow work around it using the function underlying the deftemplate macro, but didn't experiment in that direction though.

jaen13:01:24

Yeah, the same guy.

micha14:01:13

@magomimmo: re: designers, have you looked at hoplon?

magomimmo14:01:35

@micha: not in depth. Next week I’ll have a long list of reading with hoplon in the very first place simple_smile

jaen14:01:18

@micha: hoplon let you use HTML then?

micha14:01:59

hoplon is i think the most approachable way for designers etc to make web apps without just copying jquery snippets blindly from stackoverflow

micha14:01:34

@jaen: yes, but i don't think that's a big win for most designers, except maybe just because their editors are already set up for it

micha14:01:00

i'm talking about designers who know html and css, not photoshop designers

micha14:01:20

if you know html and css you're already programming

micha14:01:46

hoplon simply extends html and css with a means of abstraction, basically

micha14:01:14

html is a subset of sexpressions

jaen14:01:45

Well, I was talking about designers that know HTML+CSS as well. Hiccup is an alien syntax for them, and one that requires them at least some knowledge of Clojure. I just thought that hoplon template syntax was just like hiccup but with parens instead of brackets, but if you say HTML can be used it is already a big win, since most people will feel more comfortable with that, instead of something alien as sexps.

micha14:01:29

i think the familiarity issue with < or ( is a red herring

micha14:01:59

if the designer gets too freaked out by syntax when the semantics is the same, then i don't think it's worth the time to try to help them progress

micha14:01:19

like <h1>hello</h1> vs (h1 "hello")

jaen14:01:36

And I'm not sure I would call HTML+CSS which are basically markup languages with no means of abstractions. And understanding how to do HTML+CSS does not implicitly mean such a person would be comfortable with creating abstractions.

micha14:01:43

if that's a problem then i would say don't waste your time, let them just make templates or whatever

micha14:01:58

that's exactly the point of hoplon

micha14:01:04

what you just said

micha14:01:10

creating abstractions

micha14:01:20

hoplon uses the existing absrtractions

micha14:01:25

i.e. the DOM

micha14:01:38

you can make your own DOM elements, like web components, but in a much more direct way

micha14:01:50

so a designer doesn't need to know how to create abstractions

micha14:01:00

they just need to know how to use existing DOM abstraction

jaen14:01:10

Well, I see programmers freak out over ( in lisps instead of { like in C all the time. And I - under maybe a mistaken impression - designers would probably be even less comfortable with something alien. Though maybe I'm wrong, since HAML caught on.

micha14:01:22

yeah we don't cater to those people

micha14:01:29

they will come around eventually

micha14:01:46

i mean that's a pretty stupid thing to worry about imo

jaen14:01:57

Yes, it is, but most people do.

micha14:01:05

who cares about most people

micha14:01:12

i want to work with awesome people

jaen14:01:18

My whole university was like "lol parens" and "lol functional programming" '

micha14:01:30

and now they're probably the opposite

micha14:01:42

they're the drones

micha14:01:02

typing away in corporations writing another java adapter pattern

jaen14:01:07

Well, yeah.

jaen14:01:26

Yeah, so I was saying things like kioo are good in that it doesn't force designer out of their comfort zones if they don't feel comfortable leaving their workflow.

micha14:01:26

some people actually are curious and interested and care

micha14:01:45

those are the people i want to interact with

micha14:01:32

but yeah hoplon does the trivial translation of html->cljs

jaen14:01:40

Sure, that's a noble goal, but sometimes you have to adapt - I couldn't force people to write hiccup so I used kioo.

jaen14:01:12

But if you say you can use write HTML with Hoplon then that's neat, it could probably work in that case as well.

micha14:01:35

we used it for interacting with template guys, like outsourced

micha14:01:08

so it was impractical to work with them to develop their skills because they were subcontracting and in another time zone etc

jaen14:01:10

Yup, then yeah, the same use case. Nice.

micha14:01:36

it's interesting also because there are two disconnects

micha14:01:56

the designers can't program uis, and the backend devs can't program uis

micha14:01:05

but in the hoplon channel we have both

micha14:01:54

you really need to have the right abstractions to bridge the gap

micha14:01:01

and make ui programming accessible

micha14:01:56

like if you're a backend type of programmer and you need to make a ui for a prototype, you're in the same position as a designer who needs to prototype some behavior into their static template

laforge4915:01:48

@jaen As a dyed-in=the=wool backend java dev, I am quite excited about being able to write ui for my stuff.

laforge4915:01:15

So I'm a bit over-the-top on hoplon.

laforge4915:01:00

Ever so much better than Swing!!!

jaen15:01:43

Well, hoplon doesn't let you write desktop applications and vice-versa for Swing, so it's a bit different, but yeah - writing something like Holpon or Reagent is certainly far, far more pleasant than imperatively bashing together GUI in Swing (had to do that for university one-semester Java course, never want to touch that again).

jaen15:01:15

Though I think Clojure has Seesaw which is a Clojure sandpapering over Swing. Didn't use it though, so not sure how well it works in practice.

jaen15:01:33

There are also other interesting desktop GUI projects (in no particular order) - https://github.com/friemen/async-ui, https://github.com/FlatGUI/flatgui, https://github.com/aaronc/fx-clj - each of which is probably better than Swing as well.

laforge4915:01:56

I just really like the way hoplon unifies everything.

laforge4915:01:20

And is reactive without needing a virtual dom.

pesterhazy15:01:42

Question: if I want to hack on boot-cljs (i.e. use a local git branch), how do I do that?

jaen15:01:52

Well yeah, virtual doms are just performance optimisations. Which makes it quite interesting how Hoplon compares in that regard.

jaen15:01:49

@pesterhazy: I think you hack and then do boot build-jar which should install the JAR in your local maven repository

micha15:01:13

i don't think virtual doms are primarily perf optimization

micha15:01:22

i think that's how they sell it

pesterhazy15:01:33

@jaen, isn't there a way to use my checkout directly, i.e. without building a jar for every change?

micha15:01:42

but really it's there so you can think of the dom as a functional transformation over immutable data etc

micha15:01:04

the diffing part is key to the react component model

micha15:01:15

performance is orthogonal

jaen15:01:56

Yeah, but you can do the this state -> dom pure function thing without virtual dom as well if I understand correctly.

jaen15:01:10

And dom diffing is just a performance optimisation over that,

micha15:01:37

well you'd have to dump the entire dom and recreate from scratch for each little change

micha15:01:07

i don't know if that's exactly an "optimization" then simple_smile

jaen15:01:09

Yes, but that's orthogonal to being a pure function from state to dom.

micha15:01:35

i mean like is having tires on your car a performance optimization?

micha15:01:43

it can in theory drive without them

micha15:01:23

2.6.0 wil have much improved checkouts support btw

micha15:01:41

been working a lot on getting that exactly right the past few days

pesterhazy15:01:25

@micha, great to hear!

jaen15:01:32

Hmm, yeah tires would be a performance optimisation. Back in the day vehicles didn't have tires, yet they also fulfilled their task.

micha15:01:59

ah then i agree simple_smile

magomimmo15:01:48

@laforge49: all that reactive stuff remembers me the so called active values from the frame languages of 30 years ago or even the constrain propagation language (at those times I even get into the thesis by Guy Steel <ftp://publications.ai.mit.edu/ai-publications/pdf/AITR-595.pdf>)

micha15:01:56

amulet especially

micha15:01:16

hoplon is quite similar, given the restrictions imposed by the browser

micha15:01:31

in amulet they had full control over the entire stack

magomimmo15:01:35

@micha: back to basics! Like with our beloved LISP

micha15:01:26

i think there are things to be learned from ms excel too though, to improve on the amulet model

magomimmo15:01:56

@micha: with boot I’m getting everyday closer to my dev experience on my LISP machine of the 80’s...

micha15:01:58

excel is a really great example of software that helps you program without needing to know how to design abstractions or architect software

micha15:01:39

hoplon emulates that: the ui is a chart that reacts to spreadsheet values in "worksheets"

micha15:01:54

it's just that the worksheets are cljs namespaces with javelin cells in them

micha15:01:03

and the charts are reactive html

magomimmo15:01:25

yep. I just read about it….

micha15:01:00

@magomimmo: did you really have a lisp machine workstation?

magomimmo15:01:01

@micha: sure. I still dream of it. Can you imagine a LISP based OS?

micha15:01:36

it's hard to imagine it, unfortunately

magomimmo15:01:32

Everything was just there. that was the true immediate feedback environment, I mean totally immediate

magomimmo15:01:34

I’m following your talk rightnow (cloju3)

micha15:01:42

it must have been a real bummer to go from the lisp machine to a unix desktop

micha15:01:33

i guess unix is the C machine

magomimmo15:01:03

and to C, then C++/Objective C, then Java, then: back to basics: clojure

magomimmo16:01:29

@micha: imperative OO languages are like Ptolemaic epicycles compared with Copernican point of view. They are just false

micha16:01:11

we have an epicycles count badge on the hoplon repo

micha16:01:16

to keep us honest

micha16:01:16

although as my brother points out, you can approximate any function with epicycles

micha16:01:29

fourier series style

micha16:01:45

so he's not completely sold on the idea

laforge4916:01:31

Yeah, the hardware is fast enough and developers are cheap. stick with epicycles.

magomimmo16:01:00

wavelet can do better FFT

jaen16:01:03

Well, they are not false in the way it is how computers work. But they feel false in the way it is not how computation should be described.

micha16:01:31

definitely not the weapon of the jedi

micha16:01:35

epicycles

jaen16:01:40

Yeah ; d

micha16:01:07

that's the really awesome thing about clojure to me, really

jaen16:01:23

A friend wanted to learn programming and I'm explaining it to her starting from the lambda calculus and she just gets it. I don't think it would have been as easy if I decided to go the imperative route first.

micha16:01:30

like in star wars you don't see the jedis doing the dirty work of running a society

micha16:01:42

they just swoop in and do some swashbuckling

jaen16:01:48

Well, Clojure isn't exactly 100% elegant. Those stacktraces? Ouch.

micha16:01:49

and awesome things

micha16:01:13

it's the stormtroopers who are patrolling the streets and kicking in doors to get terrorists or whatever

jaen16:01:22

It's probably the biggest things that makes me want Racket to be the next stop after lambda calculus and not Clojure.

micha16:01:25

clojure lets you use the stormtrooper stuff too

jaen16:01:36

Just by not having to deal with explaining them stacktraces.

micha16:01:42

yeah i started with racket

micha16:01:15

but like no jedi lisp programmer is going to make an xml parsing library that works as well as the terrible java things with millions of lines of code

micha16:01:32

the jedi will make a monadic parser thing that's like 80% finished

micha16:01:39

with edge cases unhandled

micha16:01:00

because it takes a lot of grinding grunt work to get those things right

micha16:01:07

java is perfect for that

jaen16:01:40

Yeah, I'm wondering if it's something inherent to them lisps, like described this bipolar lisp programmer archetype article.

micha16:01:45

at least this has been my experience

jaen16:01:53

That they are somewhat too powerful for their own good.

micha16:01:13

this is the genius of clojure imo

micha16:01:36

you can use apache aether to interact with maven or whatver

micha16:01:57

there are hundreds of classes there that no sane lisper would fully rewrite

jaen16:01:51

Yeah, the choice of JVM certainly has it's upsides in that it facilitates reuse of all that code.

micha16:01:22

and making clojure a hosted language rather than having a cumbersone foreign function interface

jaen16:01:22

Hmm, well, FFI doesn't have to be cumbersome.

jaen16:01:12

But JVM has an edge over native ecosystem in that it was explicitly used in a lot of domains people weren't so keen to use C/C++ in, so there's usually easier to find libraries for certain tasks on JVM.

jaen16:01:22

Webdevelopment being just one example.

micha16:01:50

the crucial components are already robustly implemented

micha16:01:59

boot 2.6.0-SNAPSHOT deployed, testing / feedback greatly appreciated

micha16:01:04

there should be no breaking changes there, of course

tbrooke17:01:46

@magomimmo: I second @micha and I would suggest Hoplon for a chapter in modern cljs - I get the react fascination with om reagent etc but it seems to me like they are “overreacting” excuse the pun to the whole react thing and I don’t want to go down a react rabbit hole — btw I have thoroughly enjoyed modern cljs and I learned a lot keep it up

danielsz21:01:55

Seems like this clojars outage was a gift, because it spurred work to make Boot more robust.

danielsz21:01:33

@jaen Have you looked at Duct?

jaen21:01:05

@danielsz: I am aware of the library, but I think I'm missing some context - what exactly do you want to draw my attention towards?

danielsz21:01:11

@jaen Just asking. I had a look yesterday at the talk James Reeves gave about the library. It falls in line neatly with what we're doing with system. I am planning to implement the endpoint and handler component. It's kind of powerful.

jaen21:01:24

@danielsz: Ah, I thought you were referring to something and it just slipped my mind. I'm aware of duct, but didn't play around with it so far. Is the talk on it on ClojureTV or somewhere?

jaen21:01:59

Also in terms of structuring of applications with component I thought juxt's modular was interesting, let me find the relevant part.

jaen21:01:15

It had marker protocols of sorts the components then filtered out from dependencies automatically.

jaen21:01:38

And then there were components that provided bidi routes and could be mounted under contexts

jaen21:01:47

And the routes structure was derived from components

jaen21:01:37

Though not sure if it's too much flexibility though.

danielsz22:01:51

I like Duct's simplicity.

jaen22:01:59

Simplicity is nice, I have some unconscious overengineering bias that bites me in the end '

danielsz22:01:15

@jaen: Haha. I've had discussions with Malcolm about juxt, but it's not a good fit for system. I think Yadda is his best work. (Althoug I haven't had a chance to play with it).

jaen22:01:11

Yeah, it looks like an interesting alternative to liberator, but recently I've been doing mostly multimethod dispatch on events shuttled through sente instead of REST APIs so I had little incentive to try it yet.

danielsz22:01:27

@jaen yeah, I do that too. REST API for stuff that touches the database, all the rest via message dispatch.

jaen22:01:20

Though multimethod dispatch with components is kinda funny, I had to figure out how to create a multimethod without defmulti and defmethod

jaen22:01:37

But it actually works D :

jaen22:01:56

And then I can have components return handlers that get registered in MultiFn