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

(I was on alpha14 + 1.9.4xx)

wow. wonder why

I read some msgs on google groups, where updaing cljs version improved compile time.

Then I updated cljs version. Then compile time improved.

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.

@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 😉 )

I'm not a fan of GPL. What was the argument vs BSD/MIT ?

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.

In 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"

[since this is public -- I'm not a lawyer, and none of this is legal advice]

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.

lol

I'm just glad there are services like rpm fusion, so I can just "dnf install ... nvidia ... "

I remember having to compile nvidia drivers from 'source' before -- was not fun

#### [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: 

multimethods and core.match are not equivalent in power or features

@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 can't speak for rich

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

One doesn't exclude the other imho

^ that's the argument for multimethods and protocols. anybody can add into your case statement rather than just the case statement author

I thought I'd seen a library which does that

for example, stinks to be whomever needs to extend this code: https://github.com/hoon0612/Lisp-in-OCaml/blob/master/types.ml#L15-L22

does what?

@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

sometimes you do want closed dispatch and ordering guarantees tho

pattern matching is not just about dispatch

https://github.com/selfsame/pdfn/blob/master/readme.md

Right it's a (ahem) complecting (ahem) of destructuring with dispatch.

I misunderstood the library a little. No core.match in there.

same algorithm though 🙂

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.

for sure about the exhaustiveness

it is about trade offs

and it's really nice to see the whole case in one place

and like anything, if misuse pattern matching, you will have a mess too

and the dispatch could be different based on which namespaces are on the classpath

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

yeah i agree about the destructuring stuff

That d be quite odd and not performant surely

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

Compared to optimised hand rolled code that a pattern match lib could extend to

sure, but if multimethods supported patters, that'd work as well, right?

I guess spec conformers somewhat fill that gap, but performance is nowhere near that

Personally I wished we had pattern matching in core

nah I wouldn't go that far

I'm really glad we don't.

a library is fine for the few times you need it

It would encourage a style of programming that really has no place s the norm in Clojure, imo.

makes you think really hard about whether you want to use that style or not :)

Just got spoiled by its benefits in other langs i guess

Funny enough, the only time I've wanted pattern matching was when I was writing compilers.

heh, yeah, close to my use-case

that async code is no joke

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

Funny, Ocaml is very popular to write compilers & co

:)

@tbaldridge not sure how you'd make multimethods support patterns? control is off the multimethod dispatcher when you get to a defmulti dispatch value

unless the defmulti dispatch-fn reacted to a new defmethod being registered

but eugh

yeah, it would have to be a custom implementation of MultiFn

I've never used open dispatch, but now I'm starting to see it's power.

open dispatch is not perfect either, you enter in the realm of global mutability

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.

yup multimethods are super useful

Or actually only compile it on-demand, whould make startup cheaper

yeah that would work

but then you're still coupling ordering with dispatch

you can't tell core.match to ignore an early match and continue matching

but I guess that's just an implementation detail of this thought experiment

agreed, and that's another type of dispatcher I've wanted in the past. "If there are overlapping rules, execute them both"

... in non-deterministic order

yep 🙂

scarily close to how CLOS works

i think that was dykstras's original thought?

they all thought parallelism was gonna be rampant by the 80s i think

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 😄

https://www.youtube.com/watch?v=xrIjfIjssLE

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

that's basically taken over the world, yes

or use perl 6 and just extend it to support clojure

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

just as hard as it would be pointless

I'm writing some numericla algorithms in clojure

I'd love to have a #lang numerical ... and then use apl/numpy notation

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

there's underlying libraries, like nd4j , jcuda, ...

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