HN Theater @HNTheaterMonth

⬐ revskill

This is Clojure, not Javascript though.

⬐ z9znz

The demo starts at 7:21 and is all JavaScript. There are moments where he discusses Clojure, but the refactoring illustrations are in JS.

⬐ z9znz

The relevant part starts at time 7:21. Not sure why the time didn't get embedded in the link.

In the second part of the "Solving Problems the Clojure Way"[0] talk, the speaker shows step-by-step transformation of the heavy imperative (book-keepish) JavaScript code to a more functional approach.

As a result of transformation, ~95% of the code is easily unit-testable and the only impure code is the call to main which basically starts all the domino falling.

[0] https://www.youtube.com/watch?v=vK1DazRK_a0

I understand your worry, but I've had a quite opposite take on this.

I think we can agree that it's not that hard to find ANY job as an experienced developer. However it's much more difficult to find a great, satisfying job. For that you need to navigate around a lot of corpo-bullshit type of projects, and Clojure has served me well as a useful filter in doing that. My reasoning is that Clojure is niche enough that when company is using it, you can assume that it's due to a deliberate technical choice, and not just because of its popularity. That tells me two things that are symptomatic, in my opinion, of a healthy tech company culture: - tech decisions are made by engineers, not by top-level executives, - their conclusions and bets align with mine because we all see and agree on Clojure's edge over more popular solutions.

Admittedly, there's always a risk that someone just followed the hype and got out of their depth but I think this risk is relatively small, because Clojure's no longer a new kid on a block and choosing a tech stack is a major decision and usually done by senior tech leadership, hopefully less hype driven.

Of course, Clojure is no silver bullet and it's just a tool that gives you enough rope to hang yourself. Messy codebases are just as possible as in other languages, especially when the team is new to lisps that are very different from mainstream languages, but that's a nature of software development - you learn with the experience. I do cringe when I look at the Clojure code I wrote when I was just starting and wasn't fully grasping Clojure's way of thinking, but the more I use it, the more I come to appreciate how powerful it is.

Great intro that made it click for me: https://www.youtube.com/watch?v=vK1DazRK_a0 (Solving Problems the Clojure Way - Rafal Dittwald, 2019)

Having said that, no software project is ever complete and so isn't Clojure as an ecosystem. The tooling is constantly evolving and new patterns are emerging. What's great about Clojure open-source community is that everyone seems to share the desire to harness complexity and Rich Hickey has convinced each one of us at some point that the way to do it is through simplicity https://www.infoq.com/presentations/Simple-Made-Easy/

Even within Clojure's community there's a diversity of approaches, and I think it's necessary to improve and evolve. The more recent trend, I've noticed is that the community is converging at Data Oriented Programming that's applicable in other languages as well, but has always been at the core of Clojure's mindset that is especially well suited for it.

Dropping some links relevant about DOP: https://youtu.be/8Kc55qOgGps?t=4175 (Rafal Dittwald, “Data Oriented Programming” 2022) - whole talk is valuable, but long so I'm linking to the most juicy snippets) https://blog.klipse.tech/dop/2022/06/22/principles-of-dop.ht...

Moreover, Clojure has already grown past the threshold of being just a niche toy and has sufficiently big market that it won't die off anytime soon. When you study history of programming languages, you'll notice that it's enormously difficult thing to do for an emerging player, especially without big corporate backing. And Clojure is as grassroot as it gets: https://clojure.org/about/history

-- (Even if you don't read this whole comment, I urge you to watch this fantastic video which illustrates procedural, OOP(lite), and FP approaches to a sample problem: https://www.youtube.com/watch?v=vK1DazRK_a0 (Despite the name, it illustrates JavaScript, not Clojure). If you follow this approach, you don't even have to tell people you are doing FP. You'll just end up with better, more understandable, and more easily testable code.) --

The early (early as in C++ days) benefit of OOP was probably that it made programmers stop and plan before coding.

Having learned FP 20 years after learning OOP, I feel certain that I can do the same things in less and more understandable (and MUCH more easily testable) code in FP.

OOP was awesome for a small set of cases and for academic scenarios. But like REST, it doesn't map well to all needs. Then it becomes awkward and unnecessarily complicated.

FP, or simplified as immutable data transformations with necessary mutations pushed to the edges, works everywhere, all the time. In FP you can still choose to model your data in hierarchies, keeping some of the useful bits of OOP. But it's still data in, results out.

Until you've spent time on real projects in both, you cannot appreciate why FP is superior.

(And to be clear, I'm not even talking about Haskell and type-obsessed FP. Perhaps because I'm not a Haskell guy, I can't appreciate it. But it smells to me like an extreme of a good thing (and therefore not usually the best thing for the situation); but I digress.)

Concretely, I worked recently for a client that needed Ruby on Rails development done on a production product. It was fairly OOPish (in the Ruby way, which is to say much less insane than Java from the past OOP). Even so, the OOP at the business logic level was unnecessary. Testing was complicated and full of code to mock and fake.

When we were given the task to build a completely new solution to the same problem, greenfield, I immediately began building modules with almost entirely pure functions. Because Ruby isn't designed for this approach, it does involve a bit of care to respect memory and object copy time costs. But in many business cases, the volume of data being processed isn't significant or isn't fast-repetative.

The new product had many fewer lines of code, and the test cases were as close to beautiful as maybe is possible for tests. That's a different subject for debate...

The less experienced devs took a bit of time to accept and adjust, but the mid-level engineers became big fans of the approach. The juniors just accepted it (so nice :D). Test coverage went up, and the cost of adding new features went way down.

My FP languages of choice are Clojure and Elixir in that order. Elixir does offer some pretty great features that Clojure doesn't have (extensive pattern matching), but the syntax is imo very noisy compared to the utter simplicity of s-expressions. Either is fine for me. Ruby is fine, with some care. Python too. Vanilla Javascript can be fine, and some libraries can improve this.

Anyone who has read this far and is not convinced, I urge you to follow some Elixir tutorials and reach the point of grokking it. Then if you're a web dev, Phoenix is a fantastic framework. Also, the Erlang (BEAM) VM provides so many useful structures and utilities to allow you to build big distributed things easily compared to other languages.

Be warned though: once you do this, you will forever be frustrated by OOP codebases.

Sometimes the architecture/algorithm matters, and sometimes the architecture/algorithm needs to align with the language. Absent seeing the broader code base [1], I'm inclined to think that the author's larger design led to these expensive functions existing as they did [2].

Pure speculation on my part, but if one has a lot of experience with imperative, mutable languages, one might design a system that ends up being not so great when written in a functional, immutable language. If so, then seeing improvements when directly porting to an imperative, mutable language might be not so surprising.

Tangent: Regarding the power and importance of code structure, I highly recommend watching "Solving Problems the Clojure Way" by Rafal Dittwald at Clojure North 2019 [3].

[1] I didn't see a link, but if it's available, I'd love to take a look.

[2] The `rule-field-diff` function for example seems to be burdened with some odd choices, e.g., taking in two "rules" as arguments, (which seem to be collections of rules keyed by field), then using two hard-coded "operations" (also keyed by field), and yielding a map whose values are sequences by field (I think). Off the top of my head I don't see why this fn needs to work across multiple fields in the first place (i.e., any field-specific "loop" should be in a surrounding context. Ditto for `diff-rules-by-keys`.

[3] https://youtu.be/vK1DazRK_a0?t=461

⬐ blunte

That Rafal Dittwald video is excellent. It gives a small but illustrative comparison of procedural, oop, and finally functional... and using javascript (thereby making it accessible to non-lispers).

Most developers should watch it.

In spite of its name this video use JavaScript to implement a game using the three styles of programming. Great video learnt from hacker news: https://youtu.be/vK1DazRK_a0

This talk kind of alludes to the data driven stuff at the end: https://youtu.be/vK1DazRK_a0?t=774

It's a shame the code examples are just the fp and oop solutions not how it could look in a data oriented way

⬐ joshlemer

In his refactoring of the JS game, I was with him until about 80% through his refactor, but in the change he describes from about 50:50 - 51:00, he's actually changing the meaning of the game. Instead of printing after each turn, he's running all turns, then printing them all out at once. This is a very different behaviour and I think it's glossing over / copping out from the difficulties of applying FP in side-effectful codebases.

I mean in this case, he's transformed the program from running with a constant amount of memory (only need as much memory as it takes to run a turn) to having to store the entire history in memory. So this would be really bad if there were many turns, or if the program was going to run indefinitely, responding to user input, etc.

⬐ hunterloftis

...or simulating the world every 16 ms as is typical in a "real" game.

You can bridge that gap by taking periodic snapshots of the reduced state, which is a useful pattern in distributed game development where you sometimes have to back-track and re-simulate when input arrives over the network.

There are lots of comments and no doubt JavaScript really has its problem. But one year still I watching this and how he used mainly JavaScript to demonstrate how to think in clojure way. It is not that bad, guys

https://youtu.be/vK1DazRK_a0 (solving problems the clojure way by Rafal Dittwald).

Hi fellow PHP'er and in a long time gone C#er here

I would highly recommend learning the spirit of Clojure first:

https://changelog.com/posts/rich-hickeys-greatest-hits

https://www.youtube.com/watch?v=vK1DazRK_a0

There are a few classes of tech that are uniquely Clojure:

Data driven DSLs:

- https://github.com/noprompt/garden

- https://github.com/weavejester/hiccup

- https://github.com/seancorfield/honeysql

Hyper normalised relational databases:

- https://www.datomic.com/

- https://opencrux.com/

- https://github.com/replikativ/datahike

Advanced SPA tech (hyper normalised data driven):

  - http://fulcro.fulcrologic.com/

  - https://wilkerlucio.github.io/pathom/v2

Once you understand the spirit and rationale for Clojure it becomes apparent why other communities don't have this kind of tech yet

Once it gets down to practical things I recommend using clj-Kondo with type hints, Cursive for Intellji, make sure you learn how to hot code inject new code into your running program using your editor shortcuts, and TDD in Clojure is also excellent and immediate: https://cursive-ide.com/userguide/testing.html

Also look out for GraalVM and Babashka we're using it to compile fast native binaries out of Clojure

⬐ adamkl

While this is a pretty complete list of some of the most interesting things out there, it might be a little overwhelming to a newcomer.

I'd suggest starting with what everyone seems to start with:

- https://www.braveclojure.com/clojure-for-the-brave-and-true/

Its a pretty fun read, and does a good job of covering the language (plus its free, which is probably why most people start there).

You could also take a look at Programming Clojure (written by some of the people behind the language, Alex Miller and Stuart Halloway), which I think is a better resource, but it does cost money.

It can be tempting to want to start in the deep end and try to create something like a web app from scratch as your first attempt at using the language, but there isn't really a Django or Rails for Clojure and you can easily get lost in the weeds (as I did).

My approach to learning Clojure was to start with a simple setup (for me its VS Code with the Calva extension, and deps.edn for managing the project files) and forcing myself to use Clojure for any small utility scripts that I might have otherwise done in bash or JavaScript.

This allowed me to get a feel for the language and how to work with the REPL without having to also digest a lot of information on how a specific library or framework works.

Maybe more of the hype comes from the fact that its a Lisp. To get a feeling for the "magic" of lisp, I would suggest either watching SICP video lecs[0] or reading the book. I started learning lisp, almost the same time I've started learning programming with Java (college). Honestly I was thinking why they don't just teach us that, instead of Java at that time.

Also Clojure is created by a fairly respected dude (afaik) Rich Hickey. His talks and Clojure design decision articles on the site are really insightful.

Also this talk[1] also pretty good overview of different paradigms and `Clojure way`, imo.

[0]https://youtu.be/-J_xL4IGhJA?list=PLE18841CABEA24090 [1]https://www.youtube.com/watch?v=vK1DazRK_a0

The main benefits of Clojure compared to Elixir?

I can create

  - Desktop apps
  - Server-side apps
  - Mobile apps
  - Unity games
  - Live coding music performance
  - AI apps
  - C libraries
  - Native apps

I can use libraries with low friction from the following ecosystems:

  - JavaScript
  - Java
  - .NET
  - Python

Runtimes include but limited to:

  - JavaScript
  - JVM
  - CLR
  - Erlang
  - SubstrateVM

Clojure specific advantages:

  - Datomic
  - Crux
  - Datascript
  - Datahike

Most "functional" languages bottom out into some highly mutable SQL thing and it's gross

Then there are the cultural things, so as you grew as a programmer you probably went imperative, OO to FP, well with Clojure you go another step: imperative, OO, FP, Data-driven: https://youtu.be/vK1DazRK_a0

Technologies like this: https://unity.com/dots, machine learning etc are showing that data and data processing is likely to yield the next frontiers in computer programming

The next things on the near horizon are data-driven declarative layers to raise the bar of abstraction like https://youtu.be/jkx9F-RIFiY

⬐ None

None

Watch the video via recommendations here, but no longer can find it.

[Solving Problems the Clojure Way - Rafal Dittwald](https://www.youtube.com/watch?v=vK1DazRK_a0)

It is a great video and is highly recommended.

Spent two days to type and tidy up the source code. If you want the source, and if you like me cannot find it, you may try my version. Just hope Mr. Dittwald would not mind.

⬐ rafd

Thanks a lot for doing this!

Here are the slides: https://docs.google.com/presentation/d/13nRcrbnbvpUZGtABY9UC...

Also, I gave the talk again and made some modifications (focusing only on FP, no mention of Clojure), here are the slides and notes: https://docs.google.com/presentation/d/1NRtJvV5bXZSpFe41i3Oh... https://docs.google.com/document/d/1VSCPIy_Zs04z9xThufmRO4nc...

The introduction was changed to focus on Functional Programming, explaining a bit more what it is and what pure functions are.

The refactor was changed to mark the use of Math.random() as being side-effectful / impure, and then added a few refactoring steps to account for that.

Here's the link, FWIW: https://www.youtube.com/watch?v=vK1DazRK_a0

If you're new to functional programming, I recently gave a talk on applying FP concepts at ClojureNorth:

https://youtu.be/vK1DazRK_a0

The main example I work through is in JavaScript so that Clojure's syntax doesn't get in the way (I love s-expressions, but they're not the point of the talk).

⬐ pdsouza

Came across this talk a few weeks ago and I have to say this is one of the best pragmatic talks comparing non-FP vs. FP paradigms I've ever seen. I really like your example problem, how you explore state and mutation in the different paradigms, and how you refactor step-by-step towards a functional design. Thank you!

⬐ rafd

I'm very glad you liked it! Thank you for your kind words.