Fork me on GitHub
#off-topic
<
2018-10-12
>
enforser01:10:23

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!

vemv05:10:02

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

eggsyntax20:10:31

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

eggsyntax20:10:47

http://open-source.braveclojure.com/ (note that you can click a checkbox to see beginner-friendly projects only)

enforser20:10:24

that's great! thanks a ton.

eggsyntax20:10:39

For sure. Have fun! 🙂

valtteri06:10:55

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.

valtteri06:10:34

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

vijaykiran07:10:42

They can set Excel as the default application for opening CSVs

valtteri07:10:45

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

valtteri07:10:55

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.

vijaykiran07:10:12

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

😂 2
vijaykiran07:10:32

The separator mess is annoying though.

valtteri07:10:32

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
orestis09:10:15

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.

orestis09:10:54

I’ve used this: https://github.com/guyonroche/exceljs#browser with good results, but only from Node so far.

3Jane10:10:08

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. https://www.meetup.com/Virtual-Clojure-Meetup/

mpenet08:10:24

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)

borkdude08:10:29

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

gklijs08:10:21

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

gklijs08:10:08

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

borkdude08:10:04

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

gklijs08:10:00

I found removing websocket support more stunning

borkdude08:10:31

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

borkdude08:10:08

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

gklijs09:10:44

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

borkdude09:10:24

The boilerplate scared me away the most

gklijs09:10:15

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

borkdude09:10:21

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

borkdude09:10:05

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

bronsa09:10:36

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

bronsa09:10:28

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

borkdude09:10:33

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

bronsa09:10:13

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

bronsa09:10:30

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

bronsa09:10:52

elm people just love their newlines and vertical spacing

borkdude09:10:55

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

bronsa09:10:15

and elm-format somewhat enforces that

borkdude09:10:18

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

bronsa09:10:40

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

borkdude09:10:46

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

bronsa09:10:53

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

bronsa09:10:37

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

borkdude09:10:28

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

bronsa09:10:32

in short, LOC is a terrible metric :)

borkdude09:10:09

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

bronsa09:10:36

I feel like it's more habit than anything else

bronsa09:10:02

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

bronsa09:10:58

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

borkdude09:10:22

I’m all for more clarity vs golf

borkdude09:10:07

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.

borkdude09:10:41

personal preference I guess

borkdude09:10:58

anyway, curious to see the talk from Evan on youtube

dominicm09:10:15

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

mpenet09:10:23

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

mpenet09:10:12

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

gklijs09:10:51

it does help in reducing the errors/loc 🙂

borkdude09:10:24

what helps?

gklijs09:10:29

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

Conor09:10:51

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

borkdude09:10:09

so that is the errors/loc of no code?

gklijs09:10:15

also your compiled size relative to loc goes down

borkdude09:10:50

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

gklijs09:10:52

The best code is always the code you did not wrote

borkdude09:10:18

Like unwritten rules?

gklijs09:10:14

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

alexmiller12:10:42

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

3
alexmiller15:10:24

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

alexmiller12:10:02

I had a great talk with him afterwards about it

yen12:10:09

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

yen12:10:21

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

bronsa12:10:09

@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

bronsa12:10:52

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

bronsa12:10:24

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

yen12:10:03

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.

henrik12:10:20

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

henrik12:10:46

Oh, that was mentioned already.

henrik12:10:44

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.

bronsa13:10:22

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

bronsa13:10:36

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

mpenet14:10:36

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

jjttjj18:10:18

if anyone happens to be interested in the q programming language, I started a new slack channel for it here: http://www.qers.net/

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