Fork me on GitHub

i agree that judging things on 10 years old ruby horrors is a bit harsh, but i have seen very little amounts of code there that makes me think "hey, this looks nice and clean". maybe i have just been following on the paths of people with a very bad touch for ruby.


picking up a stihl does not make one a lumberjack


I've seen very scary Ruby code, and very clean Ruby code, and have found that it is surprisingly easy to write Ruby that feels extremely clean. It's got a lot of sharp edges, to be sure, but those edges are tucked away far better than, say, JS' sharp everything. You have to reach for many of the sharp edges fairly intentionally. It is easy to get overenthusiastic about Ruby's metaprogramming once you learn it, but that's true of pretty much any language with metaprogramming capabilities, best I can see.


with javascript my relationship is different ... learned it the very wrong way in the beginning of 2000s, avoided it for 6-7 years meantime, then in 2011 or so picked up the douglas crockford book "javascript the good parts", actually found a way from there how to write it and even partially love it without going insane 🙂


i'm a bit sorry to see where the npm world is driving that boat though, too many libraries that depend on too many other libraries of which some lack quality 😞


even though the book has aged i can still recommend it as a good read.


Have read it. I get that it has good parts, but also feel that its sharp points are much more present at all times, and must be consciously avoided. Doubly problematic when it is taught as the first - and often only - language for new developers.


The issue with any language is more about the ecosystem, other programmers, common practices and so forth. You can certainly write good code in any language, but the point is about anyone being able to write reasonably good code.

☝️ 12

The 'pit' or 'valley of success'


Yep, exactly. Downside being of course you have to climb the hill of learning :)


(Reminds me, though, that it could be worse - my brother tried an introductory programming course series while going to school for networking. The entire syllabus was PHP. 😧 )


People have different opinions on PHP, sure, but I'd definitely argue it makes for an extremely poor foundation.


Which is why I hate the “you can write bad code in any language” argument. Sure you can, but do you have to go out of your way to do it or is it the default and you have to be very disciplined to avoid it?

☝️ 4

well one of my friends from the imperative world looked at clojure and said that he could do what he would normally do and just "def everything and mutate in place that way" 😄


I just finished my first reagent app. And compared to a react/redux/saga app, it is 10 times less overhead code. Hiccup encoding is really smooth, much better than JSX. And it seems that all the async frameworks for js/react are not really needed. Reagent really should be promoted as the new clojure usecase.

💯 4

Do you have time to write a success story blog post somewhere? That would help!


Yeah sure.


I think i might put the project on github also.


Just need to remove a little bit proprietary code..


Then that is easy.


Famous last words ;)


i'm also choking from all the overhead code in our react/redux/observables app. sadly there is no interest in adopting clojurescript


Exactly! I also believe the clojure compiler works very well on clojurescript. The Webpack bundler seems not to remove unnecessary code sell. At least the react starter template I used to get started hasn't adopted it nicely.


My only criticism of reagent is that it is much more difficult to load third party components out of the box. I used a very simple highchart component and I had to tweak it big time to get it working in reagent.


third-party react components? like this one


I haven't looked into that with clojurescript, so it's interesting to hear. I guess the JS react component interop that reasonml has is a big plus in that scenario. (which is my best chance of migrating our codebase to something other than JS)


@UCSJVFV35 I have used Vega, VegaLite and VegaEmbed and all work without a hitch.


@U06C63VL4 using vega in react would be amazing. I have not found any reagent examples on vega homepage; I only found oz which uses vega for reagent, and when I tried it, it sort of has overridden the "/" route of my webserver. Can you recommend any samples ?


(defn home-did-mount [this data] ; (js/console.log "calculating chart: " data) (js/Highcharts.Chart. (reagent/dom-node this) (clj->js (make-chart-config data)))) (defn lineplot [data] (reagent/create-class {:reagent-render home-render :component-did-mount #(home-did-mount % data) ;:component-will-receive-props #(home-did-mount % %2) ; (reagent/props %) :component-did-update (fn [this] (let [ [_ series-values] (reagent/argv this) ] (home-did-mount this series-values))) }))


I had to use override component-did-update in order to get highcharts to work in reagent. I have seen samples that override component-did-mount but none showed how to sort of create a pure function that can be used in a reagent/hiccup template.


Yeah, I am almost ready to release Hanami and Saite These are light years beyond Oz and actually in many ways better than Altair (the Python VegaLite only system)


@U06C63VL4 It would be really nice to see more work on this sector. Clojure/Clojurescript should be way more suitable for data-science than Python. But so far Python still has better libraries. Can I use vega / hanami in reagent also?


Yes, I agree that Clojure(Script) is far better than Python at data crunching overall, but we still have a library gap. Though things like Neanderthal, MXNET, Flare and others are getting closer to 'lib break even'. I think Hanami will go a long way for the vis aspect


Yes, Hanami is reagent based and re-com enabled. Saite is an example app written on top of Hanami and Aeroviews (coming...) will be another more domain (RNASeq analysis) specific application


@U06C63VL4 Do you have examples for reagent usage? The samples you have in the git repo do not seem to be reagent based...


@UCSJVFV35 All of those samples are reagent based. As I mentioned Hanami is completely based in reagent and re-com/hiccup. Everyone of those examples is rendered via reagent


I'm totally lost why you would think otherwise. If you are looking at the code, every render goes through aerial.hanami.core/vgl (under cljs) and that creates a form 3 component for the canvas/svg


@U06C63VL4 cool! Thanks! From quickly reading the github it was not clear to me. That it is reagent based....


Currently this is on VGL 2.6 and VG 3.3.1 and vegaEmbed 3.16.1 - I built the CLJSJS for these and will be upgrading them for VGL 3.0+ and VG 4.0+ when they are finalized


@UCSJVFV35 If you are building a vis app (on VGL/VG), Hanami is intended to provide all the base infrastructure for that. It wouldn't surprise me if there are holes - I found some when starting on Aeroviews - and if you found some blocking its use for your case, I would be very interested in fixing those


I will play around with hanami and will let you know how it goes :-)


Dang - I need to actually release the thing - it's not on Clojars. Well, you could clone and fool around with it I suppose.


How would I use the library then?


Ha! - exactly why I originally mentioned it was not quite released. As mentioned, cloning could be used, but I agree it is much better to be released. I'll ping you in a few days when it is. You may not find it applicable to what you need - but I have found it very nice in the local work I've been doing.


start(() =>
        ["h1", "Hello hdom"],
        // the hdom-canvas component injects a custom branch-local
        // implementation of the `HDOMImplementation` interface
        // so that one can define virtual child elements representing
        // shapes which will not become DOM nodes, but are translated
        // into canvas API draw calls
        [canvas, { width: 300, height: 300 },
            ["g", { stroke: "none", translate: [50, 50] },
                ["circle", { fill: "red" },
                    [0, 0], 25 + 25 * Math.sin( * 0.001)],
                ["text", { fill: "#fff", align: "center", baseLine: "middle" },
                    [0, 0], "Hello"]


The similarity to Hiccup can’t be a coincidence

jaihindhreddy-duplicate16:09:36 is very impressive! Too bad all the libs seem abandoned 😞


oh no, I originally planned to learn/practice computer graphics/computational geometry (partially) by writing library in clojure (searched this space before and didn’t find any)… I really ought to have heeded the advise here: :face_with_monocle:


To me it looks like it has seen activity recently. Mostly one person, but still.


Most of his current work has been on the TS versions I believe.


Is hdom a lightweight vdom implementation?


hmm, maybe the "target implementation" is a swappable thing


A potential alternative to react/react-native?


well, native has its own machinery. But sorta reactish


But, the swappability maybe means you could put hdom over react too, to get react-native

👍 4

There've been some vdom experiments in cljs, iirc


looking into aws' s3 object listing , i wonder what exactly happened here once upon a time ..

:thinking_face: why is ETag as a silly quoted value here

😬 4

This here looks pretty cool

👍 8

Geez, I wonder if this lisp "closure" browser will run Clojurescript compiled by the closure compiler 😂


I feel like we're reaching some kind of "epistemic closure" lol