Clojurians Log v2

welcome @tstephens @scottman @t0by

hi!

hi

I'm t0by, I'm a grad student with a vague knowledge of haskell and elisp who's curious about this Clojure thing :simple_smile:

Unfortunately doesn't have types and has pretty bad error messages, but has good concurrency support and macros P ;

@t0by: what are you studying at the graduate level

pkobrien: I'm doing a master's in computer science

pkobrien: at the university of padua, eeetaly.

you should find much to like about clojure/lisp

I hear this is where the fun is, fun that can carry over to the real world too.

feel free to discuss in detail in one of the other channels

pkobrien: thanks. I think I'll just lurk a while. I lurk a lot.

pkobrien: thanks for the warm welcome.

lurking is good to start

Lurking is not bad - you can learn a lot just by looking at what others discuss. Though asking questions is quite welcome here from what I can tell.

@t0by: out of curiosity where did you encounter Haskell?

@jaen: I know two types of people. Some who really like Haskell and some who really like Clojure. I also have a prof who belongs to the former group and has us working in Haskell on stuff, so that's how I learned Haskell first. (Or should I say "learned" with scare quotes.)

So at the university?

Neat.

Haven't done real world stuff with it yet. That's in fact one of the main reasons I'm curious about Clojure - I hear people build actual stuff with it.

#C050BB98B perhaps? not sure

pkobrien: sorry about the OT.

np

Well, you can build real world stuff with Haskell and people do. But it's certainly true you have to invest considerably more time into learning Haskell than Clojure in order to be real-world productive.

#C03RZGPG1 is a bit like at channel

and we all make "mistakes"

It's basically why I use Clojure - I'm a Haskell person (if we're talking about language tastes), but want to be able to write real-world code now, instead in two years after I had internalised all the typeclassopedia.

sometimes I even make them on purpose so I can get really good at it

as any lurker can confirm

jaen: I don't doubt that, what I meant to say is that I get the impression that there are more Clojure projects and companies popping up lately than Haskell. yes, that's awfully opportunistic (is that the English word?) :simple_smile:

<old joke about how you can in theory build stuff with anything that's Turing complete after all>

Yeah, I think that means what you want - that is taking advantage of opportunities for personal gain.

Yeah, that's true; Clojure has a steeper popularity curve than Haskell for many reasons - being on JVM and a dynamic the biggest of those, I think.

Oh, well, make it "selfish". You get what I mean :simple_smile:

Good to know

you can create even more with the support of the community

Which is what basically lets you be productive with Clojure faster. And for most jobs you don't need Haskell levels correctness guarantees.

At least, that's how I would explain this popularity.

And sure, everything is Turing-complete (or Church-complete to riff a bit on the eponymous hypothesis), but the question is not what language makes possible, but what it makes easy.

And I noticed that Clojure (or more generally - functional programming) considerably lowers the bar of what is a hard problem.

When I was doing websites in Ruby my problems were more like "how to wrangel jQuery to modify that DOM element when this AJAX request goes through" and not "how do I make a client side database with reactive queries".

It kinda makes you feel more powerful, because you can accomplish more with less.

Fragmentation of approach is quite the problem for me. Many languages propose so many different ways of doing similar things. And it feels so not right to not know, i.e., missing out on the concepts. This really hurts the focus that is needed in being productive with some language. Say if it takes around a week to get all the fundamentals down, being aware of and the curiosity towards other languages and technologies that surfaces makes me want to try another one without getting the current one right.

Really need to focus on this one though, value proposition is way high and is a lisp that can actually be used. Learning to use lein now, just tried user profiles which is very awesome, but now I'm attempting to... oh look a new statically-typed functional reactive programming language!

Well, programming is relatively young - we still don't know all the answers. OO seemed like the solution for the longest time, but when you look at it, it's more of a solution to problems of mainstream languages coming from imperative, mutable, procedural part of the lineage and in a FP language some of those problems are non-issues and others can be solved differently. It'll all come together in tens of decades, hopefully ; d

If you mean Elm then yeah, it's pretty interesting, but as opposed to Clojure it isn't really general-purpose at the moment (if ever).

So there's that to convince you to stay with Clojure.

Ahaha yeah

As for shiny things, but in Clojure land - boot should be worth taking a look at, especially if you're interested in using Clojurescript.

Its only been a year and a half since I started programming professionally, just as I thought I grasped OO, I immediately started to learn of its negatives and all the recent remarks that are around on the internet.

And if you think Elm is interesting, then there's Zelkova library that's inspired by it (no static typing though).

Well, OO is about the best thing imperative world has to deal with it's problems. But if you can step outside the imperative? There's a whole brave new world out there.

I really want to get clojure down this time around, I think I'll be starting from the backend, learned about compojure today, are there other alternatives?

I'm of the mind that learning people to program starting from imperative languages is doing them a disservice, but that's just me.

Alternative routing libraries?

I like bidi - https://github.com/juxt/bidi - though I must agree the route definitions are a bit less readable.

I do want to go full functional, because I've felt that joy too, did RxJava, albeit the boilerplate, it was sooo much fun to get things way functionally.

On the flip side - you get reverse routing and you can easily share routes with Clojurescript if need be.

I certainly can agree that functional programming is more fun. And sometimes more readily understandable even. I couldn't for the life of me grok event sourcing as described in the OO manner. But when I read it's basically a fold over events I understood it immediately.

It is a huge disservice, where I learned programming (college), the lecturers hardly could explain what for what. If I had the power, I'd change the entire syllabus to go the functional and traditional CS route.

Do you recommend clojurescript for the backend? That would go with node, wouldn't it?

Oh, I never tried Clojurescript on the backend, just on the frontend - I was talking about ability to share things between Clojure backend and Clojurescript frontend.

Understandable it is, but unlearning and getting it into the habit is tough.

Though yeah, you could use it with node, but I don't see many people doing that if they can reach out to JVM Clojure.

Oh I see.

Mostly if someone is writing a CLI utility that needs fast boot time or something

Which is a rare-ish case.

And the Clojurescript maintainer isn't really interested into improving Clojurescript+node, since not a lot people use that.

Is this the right channel to discuss workflow?

Hmm, yeah, maybe not, my bad '

There are things that I want to ask.

I see that Emacs is the favoured editor, but I'm using Atom, I'll get around Cursive once I understand the project structuring idiom things.

How does a Clojure programmer do actual development? Write to a sourcr file and reload in REPL? How does one be productive?

I'm using Cursive and it's really good. I used to hate IDEs, but Cursive made me reconsider. Never could get into Emacs on the other hand, prefer the vim way of editing.

Not sure what would be a best channel to talk about things like that, thought.

People don't seem to want to use this one, since it's unpartable.

Right.

Off-topic may be better.

Yup, could be.

can talk about workflow in #C03S1KBA2

jaen: the funny thing is that Milner and, of all people, Backus were functional advocates in the late '70s, way before OO was cool. I am no expert, but I suspect that it's the fact that hardware and compilers have gotten to the point where you can actually build efficient stuff - along with new software engineering models (i.e. not-waterfall) - that helped given rise to the recent popularity of the function approach.

but the short answer is that many folks start with a variant of: http://thinkrelevance.com/blog/2013/06/04/clojure-workflow-reloaded

*helped give

do we need a #bikeshed channel

or maybe #chitchat

someone solve this

Re: you don't need Haskell levels correctness guarantees - Haskell (no type system) has much to offer wrt correctness in domain semantics. Given that most bugs always center on domain semantics, static type systems are generally highly overrated. If you really want 'guarantees' of correctness you need to go with formal proofs (ala' Gries, Dykstra, et.al.) My go to example of this is - give me the HM type description that would 'guarantee' the correctness of an implementation of Interaction Information. I'm not sure it is even doable, but if so, it would likely take far more effort than just using proof principles and still not be as tight as the latter.

As Rich Hickey points out - what is it that all bugs in the field have in common? They all passed the type checker and they all passed the test suite...

Not that I am smart enough to know (or understand what interaction information is) but maybe even more powerful and proof-oriented type systems like Idris or Agda or Coq have could deal with that? But regardless of that yeah, it's getting pretty fringe.

OK, yes, this is fringe, and this is my last comment here. Re: Idris or Agda or Coq : Coq is a theorem prover not a type system, and yes that would help in a formal proof scenario. Idris and Agda both have embedded (limited) theorem provers along side their type systems, and so again could help in a formal proof setting. Actually all these things are 'limited' in the sense that all of them are necessarily incomplete (or alternatively, and even worse, unsound).

I'd also like to add that from a philosophical point of view I think it is impossible for us to create "correct" systems. I always see it like this. Humans are prone to error in everything they do. So everything they create will also be prone to error, given the complexity of a task will be greater x. Where x is dependent on the other stuff, like the humans involved, etc. For me the logical conclusion is to focus on "getting things done", fullfilling a goal instead of chasing down a path where I know that I can not succeed. So I know my solution won't be correct, but maybe it is enough to please people, my boss or my customers.

Also I would like to add that I make a difference between creating / crafting and discovering stuff. Mathematics and physics for instance, are laws of nature that the human being discoverd. Some script or program is something we invented to let repetitive tasks be done by a machine.

@sverl : nicely put - agree completely

Ooops, that should be @sveri - should use the slack suggestion list...