Fork me on GitHub

is there a channel for people who are looking to contribute towards open source clojure projects? I'm interested in becoming more involved but am not sure the best place to start!


Seems unlikely to me but let us know any specific question 🙂


@UCQL6E7PY not a channel that I know of, but here's a good resource for finding one:

eggsyntax20:10:47 (note that you can click a checkbox to see beginner-friendly projects only)


that's great! thanks a ton.


For sure. Have fun! 🙂


Is there a trick to convert .csv file to something that MS Excel can open automagically? I’m looking for a client-side solution. My users get stuck when Excel doesn’t know how to open the csv when they double-click the downloaded file.


I’m being lazy and trying to avoid sending the data back to server to convert it to xls and such.


They can set Excel as the default application for opening CSVs


Thanks for the answer but that’s not really a user-friendly solution I’m looking for.


So instead of writing a CSV I’d write XLSX file directly in browser using a light-weight lib. Let’s see how that goes.


I guess that's one way to go when people get confused with "right click and open with Excel" 🙂

😂 2

The separator mess is annoying though.


Yeah I initially thought myself .csv wouldn’t be a big deal but we tested with a few actual users and each one of them got stuck when Excel didn’t know how to open the file ‘directly’. 😞

😭 1

CSV -> Excel is terrible — you get all weird issues like Excel thinking numbers are dates etc etc. Best way forward is just to export to excel directly.


I’ve used this: with good results, but only from Node so far.


This may depend on Excel version, but I remember one thing that fixed this for me ages ago was adding a BOM at the start of file. (Which also made it not work with some other csv-using tool, ah well)

Eric Ervin19:10:51

I heard about it as a member of the Virtual Clojure Meetup group.


the talk from the elm creator talk is really good too (it's not really about elm per say)


added to the list. he got quite some critique on his way of managing the community I heard, so it would be interesting to hear his perspective


@borkdude about the breaking changes, or also other things?


There never where native modules, it was a hack, and very few elm libraries used it.


> The tone is firmly set by the way the Elm Github issues are managed.


I found removing websocket support more stunning


They removed more things that people relied on, like the FRP thing. But since they are not 1.0 yet, you can argue it’s justified..


I never used Elm in anger and I’m not part of the community, so can’t really say anything useful about it.


Some of the changes are really not needed, like shortening the json file name.. I just played a few times with it, but things like this keep me back. Also there is no place to keep state as I understood. So when you have a multi language application you need to pass the language with every function..


The boilerplate scared me away the most


A current team member is very fond of it, and is also maintainer of an library, and sometimes talks at meetups about it.


Not being able to use existing React libraries (because it’s not React) or the barrier to interop with existing JS libraries also doesn’t appeal to me very much


sometimes a little more code to get the benefits of stability/typing is worth it, but 3x?


IME elm has the opposite problem of lisp wrt loc count: it has a very low density of code per line due to the way it's usually indented, I suspect that's causing artificial inflation in LOCs


IOW there may be 3x lines but there's definitely not 3x amount of code


@bronsa is Elm indented very differently from Haskell or does Haskell has the same phenomenon?


I've never written haskell in production, but from what I've read and played with I'd say haskell is denser than elm


in clojure we'd do the same in 10 lines, but not with significantly less code


elm people just love their newlines and vertical spacing


it seems they use a lot of more whitespace/empty lines


and elm-format somewhat enforces that


but note in the article: > Blank and comment lines are not part of this calculation.


yeah sure, but look at the code itself, let\n foo=\n { a = b \n c = d }


Elm doesn’t have typeclasses which may account for more code than Haskell


those are already 4 lines for something we'd keep in one line in clojure


the lack of automatic json decoders/encoders derivers likely also plays a part in the inflated code size


yeah, same for Haskell, although they do have a lot of automatic derivation stuff. once you write a type, you have json de/serialization and usually faster than clojure


in short, LOC is a terrible metric :)


agreed, but this way of bloating your code puts me off, even if it’s a bad metric 😉


I feel like it's more habit than anything else


if you're used to dense code you'll prefer dense code, if you're used to sparse you'll prefer sparse


I know people who'd love to write clojure indented as sparsely as elm for example


I’m all for more clarity vs golf


I’m really open to exploring new languages. I played around with PureScript. That language has potential to yield less code to do the same thing compared to Elm. I much prefer that one.


personal preference I guess


anyway, curious to see the talk from Evan on youtube


I think byte count where you skip whitespace bytes is best.


I am personally not a fan of elm (at all), I just liked the talk


I also disagree with some of the points he makes and some of his views on community management, but still


it does help in reducing the errors/loc 🙂


what helps?


if you have relatively many loc the erros/loc goes down


Conversely, if you write no code there can be no bugs


so that is the errors/loc of no code?


also your compiled size relative to loc goes down


I guess whitespace, the language, really shines in that benchmark (where blank lines are ignored)


The best code is always the code you did not wrote


Like unwritten rules?


more like if you can manage not to have some weird business exception and that sort of stuff


I thought Evan’s talk at Strange Loop was excellent and well worth anyone watching (not about Elm really)


and Stu’s upcoming talk at the Elixir conf will be in the same general vein


I had a great talk with him afterwards about it


If this stackexchange post is to be believed, the ratio of line count to bug count is pretty constant regardless of language.


Which implies that if a language needs more lines to express the same idea, it’s more likely to be buggy


@hello254 again, there's a difference between more code and more lines of code, see the above discussion we had about it. TL;DR elm tends to have less density per line, as a code style


i.e. there's a difference between comparing (reduce + x) with int ret = 0; for (int = 0; i < x.length; i++) { ret += x[i] } return ret and comparing (reduce + x) with let\n a = \n List.fold_left (+) 0 x\n in \n a


the elm example has significantly more lines than the clojure example, but they do operate on the same level of abstraction, compared with the java example which has less newlines but uses significantly lower level abstractions


The reason why bugs per line is relatively constant is because there’s only so many lines (like actual physical lines) of code a human mind can hold before it loses track of things.


LoC can be useful together with other metrics though. Like bugs written per LoC.


Oh, that was mentioned already.


In written text, a low semantic density will make the text seem shallow and unnecessarily ceremonial. There's something of that to code as well.


I agree, but the solution here is pretty simple then: indent your elm code in a different way that elm-format would suggest you to :) my point is that there's 2 reasons why code can span multiple lines, one is code density and the other is an actual need due to lower level abstractions


the one that matters is the second, the first is fixed simply by changing indentation styles, it's not inherent to the language


Well even density is a weird metric. Dense code can be horrible to read/understand (or not) depending on the language.


if anyone happens to be interested in the q programming language, I started a new slack channel for it here:

Daniel Hines23:10:36

So I’m going over the Gang of Four design patterns again for a new job where they’re very much in focus. I’m already totally sold on the functional paradigm, yet I’m also learning a lot about OO from the Go4 patterns. Are there functional architectural patterns that have a similar clout to the Go4 patterns. I thinking of something that only becomes possible when you have guarantees that a function is pure. Redux/Flow comes to mind, but are there others?

Daniel Hines23:10:46

That’s really interesting… I’ll have to think about how that compares and contrasts with the Go4 design patterns. It seems much more about the rules of logic/thought in general, but that’s why I’m drawn to functional programming in general - it seems, in a very deep way, more true.

Daniel Hines23:10:21

Also seems like a great blog. Thanks @hiredman