new strange loop talks are being published! https://www.youtube.com/channel/UC_QIfHvN9auy2CoOdSfMWDw/videos

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!

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.

https://github.com/egeriis/zipcelx and related blog post seems to be something what I’m after https://medium.com/@Nopziiemoo/create-excel-files-using-javascript-without-all-the-fuss-2c4aa5377813

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

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’. 😞

Hey, how come I didn’t know about this one: https://www.crowdcast.io/e/stu-halloway-running-with-scissors

the talk from the elm creator talk is really good too https://www.youtube.com/watch?v=o_4EX4dPppA (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?

@gklijs https://dev.to/kspeakman/elm-019-broke-us--khn

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

yes, about 3 times the loc then re-frame needed https://medium.freecodecamp.org/a-real-world-comparison-of-front-end-frameworks-with-benchmarks-2018-update-e5760fb4a962

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

https://github.com/rtfeldman/elm-spa-example/blob/master/src/PaginatedList.elm look at this for example

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

https://github.com/rtfeldman/elm-spa-example/blob/master/src/Timestamp.elm#L31-L77 better example?

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)

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. https://softwareengineering.stackexchange.com/questions/185660/is-the-average-number-of-bugs-per-loc-the-same-for-different-programming-languag

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: http://www.qers.net/

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?

http://www.haskellforall.com/2012/08/the-category-design-pattern.html

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.

Also seems like a great blog. Thanks @hiredman