This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-08-02
Channels
- # beginners (118)
- # boot (73)
- # cider (2)
- # cljs-dev (65)
- # cljsrn (18)
- # clojure (49)
- # clojure-argentina (4)
- # clojure-italy (19)
- # clojure-portugal (1)
- # clojure-russia (1)
- # clojure-spec (34)
- # clojure-uk (102)
- # clojurescript (202)
- # code-reviews (3)
- # core-async (5)
- # cursive (11)
- # datomic (25)
- # emacs (1)
- # graphql (22)
- # hoplon (6)
- # keechma (59)
- # leiningen (10)
- # luminus (31)
- # lumo (78)
- # off-topic (141)
- # om (32)
- # om-next (2)
- # onyx (6)
- # parinfer (55)
- # pedestal (3)
- # protorepl (3)
- # re-frame (8)
- # reagent (8)
- # ring-swagger (1)
- # rum (20)
- # specter (1)
- # sql (5)
- # test-check (11)
- # vim (13)
- # yada (7)
hmm, updating to: [org.clojure/clojure "1.9.0-alpha17"] [org.clojure/clojurescript "1.9.854"] appears to have shaved off 10 seconds from 50 to 40 for compile time
There's been a lot of compiler improvements in the past few versions of CLJs.
But yeah, if we're talking about fast compile times, someone has to mention Go 😉
But that's the problem, sometimes the compilers are hampered by the language they are compiling. Go is designed from the start to be compiled quickly, and so some features that would be nice (generics, templates, macro systems, etc. ) aren't going to be included anytime soon as they would complicate the compiler.
Likewise, Scala has compile times so slow they would make you cry, but that's the price you pay for about 2-3 type systems in a single compiler.
the worst I've ever seen is the stalin scheme compiler
OCaml is pretty amazing though - in terms of (language features) / (compile time) as a ratio
Just going to leave this here http://www.timewellspent.io/
and good compilation for starters - https://gist.github.com/reborg/dc8b0c96c397a56668905e2767fd697f
Hi. I’know that is a bit off-topic, but do you know any NBA (Next Best Action) systems to use?
Why Clojure is not licensed under GPL, MIT, etc?
MIT and BSD are not reciprocal licenses. I want a reciprocal license. But I don't want the license to apply to, or dictate anything about, non-derivative work that is combined with mine, as GPL does. I think doing so is fundamentally wrong.
What does 'reciprocal' mean here ?@qqq you can use Clojure more-or-less how ever you want. And by contributing to Clojure you give Rich (and everyone else) the right to use the code however they want
GPL says "you can have this code, but you can't use it to build commercial software"
(gross simplification, and I'm not a lawyer 😉 )
reciprocal means "if you distribute modifications (or for some extreme licenses, just modify) this code, it needs to be available under the same terms under which you received it"
patents mostly
When programming in Ruby, do you (anyone willing to answer) find it necessary to have your object instances contain data? I just put my heart and soul into trying to not doing that and i feel like i’m crippling myself. I think the logical argument here is that the only way to get polymorphism in Ruby is through objects. So unless i want to write switch statments, i’m going to need objects w/ data.
When I was writing both at the same time, and the ruby code was not in the context of rails, I tended to write apis that accepted and returned data to ease coupling, but never tried to keep my internal objects free of data.
What I did do very often was write immutable objects
I work exclusively in Ruby in my day job, and I try to use hashes instead of objects as much as possible.
I would use a hash instead of a Person
object if the object was just used to contain a bunch of fields, since you get the full power of enumerable, all hash methods just work etc.
but if you are dealing with a bunch of state, and some methods operating on the state, I would put it in a class, or the language will work against you
we use immutable objects + dependency injection + factories to help keep things straight
Surprisingly, the clojure feature I found myself missing more than any other when writing ruby code was protocols
agreed. we sometimes use classes that have a bunch of
def foo
raise "must implement foo!"
end
to emulate protocols / interfaces, but I’m not sure it’s worth the effortIn the US (and some other countries) you can patent some tech, and release some software as BSD that includes those patents
@noisesmith : I can see how that rules out MIT/BSD
With EPL you also give rights to use your patents as part of the code.
@tbaldridge : I understand the patent/license issue now. This is quite nice.
It's pretty weird to give someone the code, then sue them for patent violation over the code you gave them.
A silly side effect (and I blame the GPL) is that you can't use GPL and EPL code on the same project.
Yeah, I'm not aware of anyone doing that, but the EPL makes corporate lawyers a lot happier.
I worked for a megacorporation once and their policy was "You can never use GPL code on a project, ask permission before using LGPL"
I was okay with GPL until v3 or so -- the "if you run our code on a webserver, and people can access your webserver, you have to make the server side modifications public -- wtf"
I think the GPL can work for bits of code that should be free forever, like a OS. But even that gets murky when you include modules. Which is why NVidia's GPU drivers are wonky. They don't include them as a kernel module, and they don't compile them. They compile a GPL shim, then map in a binary blob of proprietary data that just happens to be executable.
Nothing is "linked" so the GPL does not apply.
And they have to do that because about 50% of GPU tech is software optimizations, and they don't want that getting out to their competitors.
but that whole situation is just insane, imo.
I'm just glad there are services like rpm fusion, so I can just "dnf install ... nvidia ... "
#### [Why no pattern matching?]()
If you are talking about the aspect of pattern matching that acts as a
conditional based upon structure, I'm not a big fan. I feel about them
the way I do about switch statements - they're brittle and
inextensible. I find the extensive use of them in some functional
languages an indication of the lack of polymorphism in those
languages. Some simple uses are fine - i.e. empty list vs not, but
Clojure's if handles that directly. More complex pattern matches end
up being switches on type, with the following negatives:
Is this an argument against core.match and saying the clojure way is to use multimethods instead ?@bronsa : I'm not aruging they are. However, https://gist.github.com/reborg/dc8b0c96c397a56668905e2767fd697f seems to be an argument stating "don't use haskell stype pattern amtching, use multimethods" -- am I reading that wrong?
I disagree with Rich there. When using a language like Haskell/Scala or Idris, pattern matching is a useful tool that can aid in creating some nice APIs. If Rich is referring solely to Clojure, yeah, pattern matching in Clojure doesn’t give you much.
their argument against that is that you can't extend it. and if you don't own the code you can't
for instance, in loom, there's an Edge protocol. Anything you make implement Edge
can be thrown into the loom mechanism
@qqq it's actually one of the reasons David gave in a talk long ago why progress hasn't continued lately on core.match
I can't find the video now, but the comment was that for pattern matching to fit in well with Clojure's ideals it would need (defmethod ...)
like support where any module could come along and extend a matcher
^ that's the argument for multimethods and protocols. anybody can add into your case statement rather than just the case statement author
for example, stinks to be whomever needs to extend this code: https://github.com/hoon0612/Lisp-in-OCaml/blob/master/types.ml#L15-L22
@dominicm yeah it wouldn't be hard to code up in CLJ with core.match + eval. It'd be really hard to pull off in CLJS
@tbaldridge to be honest I didn’t quite understand why it was particularly valuable to extend the internals of a library until I stumbled upon a couple of clojure librairies that weren’t doing exactly what I wanted to, browsed the source code, realised the stuff was implemented as multimethods, extended it myself and it just worked
Right it's a (ahem) complecting (ahem) of destructuring with dispatch.
so, I have a library I've been working on for the past few weeks where pattern matching is exactly what I needed, no amount of unification/destructuring/dynamic dispatch would do
I'm not saying I don't prefer protocols/multimethods over pattern matching for implementing custom behaviour, but sometimes you only care and need pattern matching and that is fine
The second argument made by Rich there applies to languages like ML. Where your structs are a lot like tagged tuples, and at runtime the members don't have a name, and cannot be introspected. In that hashmaps are just a lot more flexible
Try writing something like select-keys
in OCaml that works against any type, and you'll have real fun time getting that to work.
playing devil's advocate here for a second, the downside is that you don't get stuff like exhaustiveness checks, so it's tradeoffs
agreed
I personally prefer ordered matching, perhaps with optimizations where the compiler can figure out that order doesn't matter.
I find myself using pattern matching for the cases where I do need exhaustive check, and find that a pain to write in Clojure compared to a lang with that feature.
OCaml has polymorphic variants that give a bit of flexibility to do select-keys like func that can work against types that conform to it
But yeah, it s a very different style of programming, and some concepts from one lang do not necessarily mix well with another
I still don't see how pattern matching over structured data to pull out bits of it can be done elegantly with destructuring/multimethods
in my specific case, I'm using core.match to match over symbolic representation of code (more on this if my conj talk is accepted :)), so I want to couple destructuring and dispatch, and I think it's a legitimate use case
sure, but if multimethods supported patters, that'd work as well, right?
I'm really glad we don't.
It would encourage a style of programming that really has no place s the norm in Clojure, imo.
Funny enough, the only time I've wanted pattern matching was when I was writing compilers.
And when I'm in that mode, the only thing I can think of is "why can't I write this in OCaml"
I am writing an interpreter/analysis engine for first-order logic and I have been tempted to use core.match
@tbaldridge not sure how you'd make multimethods support patterns? control is off the multimethod dispatcher when you get to a defmulti dispatch value
yeah, it would have to be a custom implementation of MultiFn
but you could use core.match to do the destructuring/dispatch, then call into the correct method from there. Every time you extend the "defmulti" you'd dump the cached dispatch function and recompile it.
Or actually only compile it on-demand, whould make startup cheaper
agreed, and that's another type of dispatcher I've wanted in the past. "If there are overlapping rules, execute them both"
yep 🙂
if they had done their job and found the easy way to write correct parallel code, then it would have been
so in the big picture it's all their fault that they were wrong
hey! don't actors solve all those problems 😄
and then in the 90s, and then in the 00s...
clearly the solution is to use racket then in diferent modules, you can do #lang erlang, #lang haskell, #lang clojure and write each module in the way you want
how hard would it be to port racket's #lang (just the framework, not all the languges) over to clojure?
I'd love to be able to experiment with other languages with the power of clojure as the underlying language
and error on boxing!
the syntax is the easy part, there's macros that can do that, keeping numbers unboxed and ops efficient is tricky
re core.match: my mind was blown first time I saw this: https://github.com/clojure-cookbook/clojure-cookbook/blob/master/02_composite-data/2-27_and_2-28_custom-data-structures/2-27_red-black-trees-part-i.asciidoc