Live data from Hacker News

A Clojure learning journey

stuttaford.me

51–60 of 72 posts

Re: A Clojure learning journey

#51
post #7

Earlier quoted context omitted.

It wasn't so much about ditching Lein as it was taking a clean-slate opportunity to learn and understand the new CLI tooling. Nothing wrong with Lein at all! Knobs and dials: this is true of every eco-system, wouldn't you say? Is 2018 the year of the linux desktop, finally? :-) I agree that Clojure has a lot. Right assumes a known context. Do what is right for you. Sometimes, that's Knob A, and sometimes that's Dial…

As a newcomer, I want sensible defaults. I want a Rails. Let me wait to learn the knobs and dials when I’ve got enough base knowledge to evaluate them fairly.

LuminusWeb is a great option for that. The generated code is simple to grasp and change as your knowledge grows.

http://www.luminusweb.net/

Re: A Clojure learning journey

#52

Not sure why the excitement around ditching Lein when it looks like there is little or nothing to be gained at this time? The author describes a handful of other tools that are necessary to do things Lein does out of the box (uberjar) The Clojure ecosystem (specifically through the lens of this post) reminds me of the Linux desktop ecosystem. Lots and lots of tweaks and knobs and dials for the sake of having tweaks a…

is there ever a single "right way" to do anything ?

Re: A Clojure learning journey

#53

I always read about those nice functional languages, but when I try to learn them myself I struggle pretty hard. Can anybody point me to some small (5k LOC maybe) project on github that solves some "real world" problem? I'd like to get some overview. As opposed to the usual tutorials that start with the very basics and don't seem to get anywhere...

We all learn differently, but I found Brave Clojure was a quick read:

https://www.braveclojure.com

From there I just started small by building some command line applications to solve every day needs. Many enjoy solving problems at http://www.4clojure.com as a method of learning.

Perhaps one of the main differences for someone coming from an OO world is that in OO, to learn an SDK means learning about all the classes and the methods they expose to operate on encapsulated data. You're limited to what you can do on the data via those public methods.

In a functional language, you instead learn a large amount of functions that operate on raw data directly. Then you build your app by creating functions that take an input and transforming it into a new output using these common set of functions.

One of the exciting things for me is Clojure Spec. One of the recurring problems in web development in an OO app is that you have some domain class like User and you have some service function which does CRUD on that User.

    // Look how great our model layer is!
    createUser(User)
Then as the app grows you have another service function which takes a Order object and 80% of the properties of User.

So you may start with this:

    // uses 100% of order, 80% of user
    doSomething(Order order, User user)
Then you have another service function which takes 3 object but only uses a few properties of each:

    // this feels like a code smell
    doAnotherThing(Order order, User user, SomethineElse somethingElse)
If you have a large team without a strong common practice an application can quickly turn into a ball of spaghetti:

    // let's list out specifically what this function takes
    doAnotherThing2(long orderId, double orderTotal, long userId, String userName, A something1, B something2)
And then you reach some maximum amount of parameters and refactor it to this:

    doAnotherThing3(DoAnotherThingRequest request)
DoAnotherThingRequest feels right but it's redefining the types of all of the properties already defined in our domain model:

    class DoAnotherThingRequest {
        long orderId;
        double orderTotal; ... }
And then you have another function which needs DoAnotherThingRequest and a few properties of another class:

    class YetAnotherThingRequest extends DoAnotherThingRequest {
        A something; ... }
And eventually you realize this is stupid and instead you do this:

    // Let's just use the raw JSON!
    doAnotherThing4(JSON json)
Clojure Spec on the other hand makes much more sense to me. You can define specs on namespaced keywords:

    :order/total is an integer
    :user/userName is a string with a maximum length of 10
And then your function can specify the shape of the data they receive:

    ; this requires an order total and a userName (Note: it doesn't redefine their specifications)
    (s/def ::do-another-thing-request (s/keys :req [:order/total :user/userName ...])))
This makes much more sense to me as a way of building large systems. And then you find out that Clojure spec can generate tests on your functions automatically based on the specifications you created and your mind is blown. :)

Re: A Clojure learning journey

#54
post #7

Earlier quoted context omitted.

It wasn't so much about ditching Lein as it was taking a clean-slate opportunity to learn and understand the new CLI tooling. Nothing wrong with Lein at all! Knobs and dials: this is true of every eco-system, wouldn't you say? Is 2018 the year of the linux desktop, finally? :-) I agree that Clojure has a lot. Right assumes a known context. Do what is right for you. Sometimes, that's Knob A, and sometimes that's Dial…

As a newcomer, I want sensible defaults. I want a Rails. Let me wait to learn the knobs and dials when I’ve got enough base knowledge to evaluate them fairly.

https://github.com/plexus/chestnut is Clojurescript, but it's fantastic. It's quite easy to roll out a UI and you can build your backend to your specifications. A bit less opinionated than Luminus, but both great for just getting started.

Re: A Clojure learning journey

#55

Not sure why the excitement around ditching Lein when it looks like there is little or nothing to be gained at this time? The author describes a handful of other tools that are necessary to do things Lein does out of the box (uberjar) The Clojure ecosystem (specifically through the lens of this post) reminds me of the Linux desktop ecosystem. Lots and lots of tweaks and knobs and dials for the sake of having tweaks a…

> Lots and lots of tweaks and knobs and dials

This is the case with all big-tent, "community-driven" PLs that have a high expressiveness, and attract contributors that have a multitude of preferences: Ruby, Javascript, Scala, Clojure, Haskell, Racket

Alternatively, are the 'prescriptive' cultures, that tend to select for predictability and high cohesion: C#, Elm, Go, Python (circa-2007).

Re: A Clojure learning journey

#56
post #55

Not sure why the excitement around ditching Lein when it looks like there is little or nothing to be gained at this time? The author describes a handful of other tools that are necessary to do things Lein does out of the box (uberjar) The Clojure ecosystem (specifically through the lens of this post) reminds me of the Linux desktop ecosystem. Lots and lots of tweaks and knobs and dials for the sake of having tweaks a…

> Lots and lots of tweaks and knobs and dials This is the case with all big-tent, "community-driven" PLs that have a high expressiveness, and attract contributors that have a multitude of preferences: Ruby, Javascript, Scala, Clojure, Haskell, Racket Alternatively, are the 'prescriptive' cultures, that tend to select for predictability and high cohesion: C#, Elm, Go, Python (circa-2007).

It would be interesting to study the MBTI psyche types in each of the major language communities.

Re: A Clojure learning journey

#57

Earlier quoted context omitted.

> so I got bored and ended up burning out. That left me without desire to work on anything computer related, I've been finding myself like this lately :( Sadly, I can't afford to buy a farm but working on a windmill sounds awesome! I've lately spent a lot of my time learning sleight of hand and magic illusions, but I don't expect I'll ever make any real money out of it, I'm just not a natural showman. I'll stick to s…

Some things that might help you: I've noticed that the real money is usually to be made on the intersection of disciplines rather than by going deep into a single discipline. So maybe it would be an option for you to branch out into a different field that intersects regularly with software, possibilities such as hardware or legal are most obvious. That will give you something new to sink your teeth in while at the sa…

Thanks for that, I really appreciate it!

Re: A Clojure learning journey

#58
post #56
post #55

Earlier quoted context omitted.

> Lots and lots of tweaks and knobs and dials This is the case with all big-tent, "community-driven" PLs that have a high expressiveness, and attract contributors that have a multitude of preferences: Ruby, Javascript, Scala, Clojure, Haskell, Racket Alternatively, are the 'prescriptive' cultures, that tend to select for predictability and high cohesion: C#, Elm, Go, Python (circa-2007).

It would be interesting to study the MBTI psyche types in each of the major language communities.

[deleted]

Re: A Clojure learning journey

#59

Earlier quoted context omitted.

It’s not Clojure, but the practical chapters in the book Practical Common Lisp might be a good way to get a feel for the way a Lisp works in a practical application.

>book Practical Common Lisp It is a wonderful book and Common Lisp is powerful to the max, but note that CL is a multi-paradigm language and examples won't necessarily be in the "functional" style. Quite the opposite, Common Lisp makes imperative programming very comfortable (and OOP as well.)

While Common Lisp definitely allows for imperative constructs, I’d argue that its flavor of OOP is part of the functional paradigm: i.e. generic functions aren’t part of the classes, they are protocols that can be implemented in different ways by different classes. They are closer to typeclasses than to java-style OOP

Re: A Clojure learning journey

#60

Earlier quoted context omitted.

Some things that might help you: I've noticed that the real money is usually to be made on the intersection of disciplines rather than by going deep into a single discipline. So maybe it would be an option for you to branch out into a different field that intersects regularly with software, possibilities such as hardware or legal are most obvious. That will give you something new to sink your teeth in while at the sa…

Thanks for that, I really appreciate it!

You're welcome, I really hope it works out for you. If I can help with introductions or in any other way feel free to mail me.
Post reply on HN