This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-04-16
Channels
- # atlanta-clojurians (1)
- # aws (1)
- # beginners (65)
- # boot (4)
- # cider (81)
- # cljs-dev (25)
- # cljsrn (27)
- # clojure (129)
- # clojure-dusseldorf (12)
- # clojure-italy (68)
- # clojure-norway (5)
- # clojure-poland (4)
- # clojure-spec (14)
- # clojure-uk (72)
- # clojurescript (144)
- # code-reviews (19)
- # copenhagen-clojurians (5)
- # cursive (16)
- # datomic (21)
- # editors (1)
- # emacs (15)
- # events (1)
- # figwheel (6)
- # fulcro (54)
- # graphql (1)
- # hoplon (24)
- # jobs (6)
- # jobs-discuss (2)
- # keechma (4)
- # leiningen (6)
- # luminus (17)
- # lumo (2)
- # off-topic (43)
- # onyx (6)
- # pedestal (2)
- # perun (2)
- # portkey (3)
- # re-frame (22)
- # reagent (11)
- # ring-swagger (5)
- # shadow-cljs (46)
- # specter (8)
- # test-check (2)
- # testing (3)
- # vim (16)
- # yada (1)
@ericnormand just FYI.. the http://purelyfunctional.tv issues archive page(s) needs a look. the pagination links all include a url param (`type=issues`) that's causing the server to have issues and display error in place of issues [1]. removing the url param manually solves it. same issues page[https://purelyfunctional.tv/topics/issues/] is also displaying oldest issues first. [1]
Warning: call_user_func() expects parameter 1 to be a valid callback, no array or string given in /var/pftv/wp-content/plugins/pftv_lessons/pftv_lessons.php on line 474
Fatal error: Call to a member function have_posts() on null in /var/pftv/wp-includes/query.php on line 767
Do you guys wonder why did LightTable die? It appears to me to be a very good replacement to an IDE, but actually even providing a new experience to writing code
@denisgrebennicov the main author (Chris Granger) moved on to another project (EVE), and most recently moved on from that as well.
I think other projects took the userbase. Namely Cursive, protorepl, Nightcode
Cursive - easy setup good for professional use Protorepl - Instarepl stuff (from what I understand) Nightcode - super-simple setup for new users
Do you see some sense in contributing to the project? Cause I found it quite interesting
I think lighttable was sold as basically an interactive way to develop side scrolling video games, which very few people write in clojure
that's nightcode https://youtu.be/0GzzFeS5cMc
And sadly I felt like Lighttable never really delivered on its goals. It had a massive refactor on every major release, and each time it became harder to understand.
I'd love a hackable editor, written in Clojure, but I'd want all the functionality found in Cider or Cursive first.
Random thought. I'd love to see deftype
become better. I'm reading the clojure.AVL code and just the deftype form is 325 lines, and most of that is telling it how to be equal, what to do if someone asks for its first member, etc. Compare to an OCaml version which is 123 lines in total and obviously its type definition is 1 line. The functions which operate on it are obvious. I know ztellman has worked on this a bit with https://github.com/ztellman/potemkin#def-map-type and the like. just wondering if anyone else ever thought this
I realize I'm several days late on this, but I very strongly agree. Clojure is the only language I'm aware of that makes a distinction between structural types like trees and data types (both of these terms are very lacking, but hopefully my point is clear) like shape/circle/square/etc., but I find the former really obnoxious to write. I never got into the whole "using Clojure to write Java" thing; frankly I'd rather just write that code in Java (and I really dislike Java). And compared to languages with actual algebraic data types like OCaml/SML/Haskell/etc. it's horribly unappealing. I'm not sure what the solution is, though. You have a fundamental problem with implementing recursive types using immutable data structures, e.g. as in defrecord
, hence why we fall back on interop 😕
Seems like a problem rooted in Clojure being based in interfaces instead of protocols.
yeah. wasn't sure if there was a good answer. i just can't imagine a paper ever describing their algorithm or data structure in clojure rather than some ML
You can do something like mixins with protocols. You can call extend-type
on a interface. Using that its possible to provide default equality semantics to something like IMap
I've worked on lisps that have protocols and allow extending protocols to protocols, that also works fairly well for this.
just a pain point i wish i had thought of during the developer survey. I have no good answer to it. just wanted to put it on the radar of what could be better.
it surprised me to see that update
was only introduced in 1.7. i figured that would have been around for a while. must have been painful without that
I think everyone just did like (update-in m [:whatever] f)
it wasn’t that bad
at least, I remember not thinking about it much
yeah, it’s a pretty obvious function I guess
i thought everyone was jsut associng with a let binding of current value and doing the update manually
not in my experience, not that I remember when update-in
showed up. I think I started using clojure around 1.3-ish?
oh for sure. i didn't think to look for update-in. figured teh whole notion of update came in 1.7
1.0 looks like https://github.com/clojure/clojure/blob/131c5f71b8d65169d233b03d39f7582a1a5d926e/src/clj/clojure/core.clj#L6113
so maybe before that, that’s what folks did (something like what you were suggesting)
it’s funny, because ironically it took me a while to remember to use update
, I just got in the habit of update-in
for everything
Yeah, I've had a couple cases where update
wasn't available. You don't realize how handy it is 'til you miss it.