Clojurians Log v2

hello all!

howdy

hi everybody, can anyone recommend a free video tutorial on how to build webapps with clojure?

@dev-hartmann: Hey there. Try this one: http://www.parens-of-the-dead.com/

@bluurn that actually looks like pefect, thanks a lot!

yw!

:deadpeople:

looking for some general advice on getting started. I want to build a websocket backend in clojure. I've read up on the basics of clojure, and I've made it through the first few chapters of living clojure. Would it be more advantageous to finish the book and learn the more advanced topics before I start the app, or should I learn as I go?

when I was learning python/django a few years ago, it was pretty easy to pick things up as I came across various problems. But something tells me clojure's more advanced topics might make that tough

bcoop713: Jump right in :simple_smile: You could also check out @magnars excellent game tutorial, http://www.parens-of-the-dead.com .. It features a frontend and backend communicating using websockets.

thanks, just bookmarked it actually. Does that tutorial use the core.asyc library at all?

Clojure is hard only if you are not familiar enough with functional programming IMO. Most of it's features are straightforward to understand. It might get a bit harder when trying to understand how to write applications with component or how to use core.async effectively, but for the most part the language is straightforward.

@jaen adopting a more lisp-like workflow takes a change of mindset

@bcoop713: there's quite a bit of core.async in Parens of the Dead, yes. :)

@tmtwd: do you mean repl/emacs style development?

and it seems to me the jvm makes that a bit more difficult still

@bcoop713: basically yes

Well, but don't you do that in Python as well? It has a REPL by default.

of course

At least I know I used the REPL a lot when developing in Ruby.

that is true

it does, but it's use isn't as heavily encouraged as in the clojure community

infact, I never heard the term REPL until after I got out of python development

python has fast startup, so not everybody cares to work from/on a repl, the jvm/clojure on the other hand....

I don't think I saw a single example of using the python repl for debugging. Only time it came up was in the first chapter of a python tutorial haha

@mpenet: exactly

in scheme, for example its so fast, you don’t need to adopt that typical lisp-like workflow

Interesting, I'd think it would be more similar to Ruby - I was debugging using pry all the time, which is basically an interactive REPL.

I learned a lot of scheme without using too much of the repl

it is common to use the repl in racket and in ML also.

Even though I agree it's not really all that needed, but I kinda got exposed to Haskell early on through ghci.

So I thought it's natural to use REPLs.

I think it is a common practice in more fp languages

because you are encouraged to handle state differently than in ruby/python etc

well once you're used to working like this it's painful to work without, it's not uncommon to have a single repl session running all day without a restart.

mainly due to the fact that it's very well integrated to the various editors/ide too

@tmtwd: but I'll give you that the JVM makes some things more difficult. I basically hate Java so when I had to deploy Clojure and had to deal with them JARs, WARs, servlet containers and what have you - that was painful. Also the parts where Clojure internals stick out or you have long-winded stacktraces and bad error messages.

But the language itself is I think pretty simple to grok.

I found ClojureScript a lot easier to get started with than Clojure, just because of the Java environment stuff.

I love the jvm

I think it depends on what you are familiar with. I found Clojure easier to start with because I’m familiar with the jvm.

I found Clojurescript harder.

I've always enjoyed using a repl; even with python, startup time wasn't so small that putting in several print statements was faster than loading a repl and blocking at the part I needed to debug

@roberto: Yeah, totally based on familiarity - there's a lot of web development stuff that is a bit of a nightmare to figure out if you've never done it before

I also find deploying jars easier than deploying a python app. I had so many issues deploying python and rails apps.

Oh, JVM is a solid piece for engineering, that's for sure. It also fives you an ecosystem of battle-tested libraries. But I just can't stop doing "UGH JAVA" each time something non-Clojure sticks out : V

being able to inspect the program state at the precise point where I'm having difficulty -- without having to restart the program -- has been an immense boon

But I actually thing ClojureScript is a more straightforward path for modern SPA development than a lot of the javascript options

@futuro: how do you do that?

tmtwd: depends on the language, but generally mark the line of code near where I'm having trouble so the debugging stops there

@roberto: re: deployment that's certainly true. Being able to pack up (almost) everything in an uberjar and just run it? That's certainly nicer than the dependency hell Python or Ruby have. But it's kind of assumed to be common knowledge in the Clojure land, which it exactly isn't if you don't come from Java.

so python is something like break someBuggyFunction or break 154

@futuro: oh of course, I mean in the context of clojure

well the I never touched the whole war/servlet containers thing, I just uberjar all the things and handle the static stuff separately in deploys. less headaches

tmtwd: I'm not entirely certain, tbh, since my functions are generally really small, I just iterate through definitions until I get it right

I've heard cider+emacs has the ability to place break points, but I haven't experimented with it yet

Weighing in on the whole JVM thing, The JVM is a plus if you’re already invested in Java and it’s ecosystem. If you’re coming from Python/Ruby/Erlang/etc, and you don’t already have that investment in the JVM then it can be a real downer.

small price to pay to an incredible ecosystem. depends on what you're into of course

tmtwd: but there again I'm using the repl to do so; so different kind of use, similar benefit

eh, the ecosystem is overstated. sure there’s a lot of java libraries out there, but frankly a lot of it is crap. And there isn’t really any killer library that doesn’t exist in other ecosystems. So I don’t really see it as a huge plus.

netty

for one

just on top of my head, it's probably the most polished networking lib out there, all languages/platforms considered

I mean, what do I want really, database drivers, web/networking stuff? all of those are covered just fine in other languages too. Aside from that I can’t think of anything in Java-land that I’d actually want.

plus, i think it becomes a negative when the internals of the wrapped java libraries jump out and bite you. then you’re back in imperrative-mutable-state-java-land again

I don’t think there is anything like drools in other langs, for instance.

maybe in .NET

oooh, drools looks kinda cool

also, Hikari

The connection pool?

yeah

java has some nice game libraries

Well, that's hardly unique. Maybe the quality of implementation is, can't compare that though.

good point @bcoop713, there are some cool game/3D libs

On the flip side - you can't really make a complex game with Java anyway.

But for some indie-ish explorations? It could be cool. Especially if you could model the world with Clojure STM.

minecraft not a complex game?

No, not really all that complex. And look at the performance problems it has.

still, none of this screams “OH MY GOD JVM IS AWESOME” to me, it’s a selection of mediocre libraries with correspondingly mediocre equivalents in other languages. I just don’t see the big draw, because I’m not already invested in the JVM. Now for the guys who have 15 years of production java to work with, and enterprise things to consider, I can see that being a boon. But that’s not me, and I suspect I’m not alone in that position in this community :simple_smile:

Hystrix

Oh yeah, all the Netflix ecosystem.

You get that only on the JVM.

good call @jaen, I’d forgotten about them

But then again, if you need to worry about that you already won big anyway ; d

What else... machine learning libraries, I suppose.

Python can probably rival that, since it's a go-to language for scientists, but I don't think much else can.

yeah, I suppose, and I was mostly coming from Python.

How does everyone structure their core.async code in their apps?

Hmm, that's rather vague.

Yeah, sorry, I'm trying to understand core.async so my questions aren't that well informed atm

I'm reading through a couple tutorials, but I'm still a little too ignorant to know what to ask

just continue working through the literature

I don’t understand transducers, and have not had any need for it. And that is ok. Similarly, if you don’t find a need for core.async yet, that is fine. You don’t have to grok everything and pile it in your code just because it exists.

Yeah, I suppose at first it might not be so obvious what to ask about. But in general how I structure core.async code isn't all that much different from how I structure normal code (at least not enough that I would have an obvious answer for you). It's a bit of a feature of core.async - that you can write your async code similarly to the sync code. Though I didn't yet have to write tons of core.async, just some, so maybe it's different down the line.

I’ve only used it when doing network requests. It isn’t a prominent thing in my apps.

when I was writing a frp node backend, i broke my code out into inputs, transformers, and outputs

not sure if that helps your situation, but it worked for my use case

look at the workshop given by david nolen in the cognitec website if you want to see some more intermediate to advanced usage.

I always go to that code in github when working with core.async

cool, thanks @roberto, @jaen and @bcoop713 :simple_smile:

On the JVM stuff, are there many products that only really have Java APIs and there aren't any other real options? I know of a couple instances like that in .NET where in the past your only real option was the .NET API or C++

again, I think java has the best game libraries outside of c++, but at this rate, probably won't be long before rust is a rival in that space

@bcoop713: Do you know of any really good ones off the top of your head? I've never really looked into that space for Java

https://libgdx.badlogicgames.com/index.html is the major one

Oh that does look cool

there's also this one, but I haven't looked at it much

https://www.lwjgl.org

and of course, there is Android

@shaun-mahood: I did once work at a job where we needed to interface with some ancient and horrifying database system, which only had decent drivers in java. We ended up wrapping it in python. That’s the only case I can think of, but I’m sure the enterprise world is full of similar stories.

Eh, but while the usual "Java is slow" spiel means little for webdevelopment, this is actually significant in game development unfortunately. So there's that to take into account.

core.matrix has vectorz-clj over vectorz

For Clojure you have a wrapper over libgdx, I think - https://github.com/oakes/play-clj

there is also Adobe Experience Manager, which is unfortunately taking the enterprise CMS world by storm

and many of AEMs competitors also run on the JVM

I'm kind of new to the concept of logging as opposed to just println'ing everywhere. Is it normal to put log statements everywhere in a codebase? I keep debuggins something, logging a bunch of stuff to figure it out, then leaving it there. Is it fine to pull in the logging stuff in pretty much every namespace and just logging stuff all willy nilly or should I be trying to be more discretionary?

set a log level

anyone? ^

@jjttjj as roberto alluded, you can have your cake and eat it too by using debug-level logs. you can just leave them in or take them out as you prefer, and you'll only ever see them if your log level is set to debug or below

@dave @roberto thanks!

no prob!

@dave so it's not really bad coding style per se to have a bunch of logging statements littered throughout all the namespaces, so long as they are potentially useful, ie they were added during debugging something then just left in?

it's fine, in my opinion

i generally like to keep things tidy, so if i put in a debug log statement that i don't think i'll ever need to see again, i'll remove it when i'm done debugging

but there are certain things that it's useful to keep in as debug logs

things you might need to see in the future

cool makes sense

you can see some examples here: https://github.com/alda-lang/alda/blob/4d29d7556ac2e238330542ef6f9b44fee1eb688e/server/src/alda/sound/midi.clj

being able to see when MIDI events happen is a useful thing when i'm debugging, so i keep those debug statements in

nice thanks again!

sure thing