A piece of advice from “A Philosophy of Software Design” is that increments should be abstractions and not features. The author (edit: John Ousterhout) warns of “tactical programming” that can emerge from for example agile development (which he neither fully rejects nor praises). He similarly criticises TDD as promoting the tendency of tactical programming when it is relied upon too much. Instead, more thinking and possibly experimentation (design twice) should be done before writing code. Comments and documentation should perhaps precede code for example. A guiding question should be: which abstraction enables this feature, rather than tunnel-visioning on a feature alone. I think this is an interesting take. In many ways it goes against some of the agile/OO advice (refactoring, TDD, sprints etc.) and I see some philosophical parallels with Clojure (hammock, system design etc.). I think there is value in both approaches. Sometimes the force of nature needs to kind of bang on a piece of code before we understand what the right abstractions are later, but sometimes a clear up-front design can enable better long term growth. Usually it is a combination of the two, as long as one is disciplined enough to actually take a step back and redesign and redo the thing at the right point in time.

#nbb is currently on the front-page of hacker news 🎉

I have a program running on a server that produces a lot of messages, and I want to enable pub-sub across other machines. How do I evaluate options here? I've looked a little bit at redis, zeroMQ, amqp. But I'm not sure at this point what factors should motivate the decision

A really off-line topic, but that I think worth mention. I have been working with a lot of projects that are not more than integration middle-wares with custom rules engine in the middle, and more curious is that a big part of those projects were built with Ruby on Rails, just because it’s a full batteries included solution with everything you can need to setup this integrations fast, but as generally happens with projects of this kind, things start getting complicated. I have a sort of intuition/gut that it’d be really wonderful to have the power of Clojure available in such projects, as a way to start really fast with Ruby and rely on Clojure as needed, and I think that it’d not feel unnatural, given that Ruby has a LISP heritage, so I bring this here, because it’s something I have been observing.

@marciol It's maybe a bit of a stretch, but you could try running Ruby and Clojure in the same VM. E.g. jRuby + calling Clojure should work I think within a JVM.

Another possibility is using GraalVM with TruffleRuby but this is probably harder to get off the ground, since Ruby is a guest language and Clojure would run in the host environment.

Another possibility would be to implement your "front-end" business app in Ruby and delegating some things to another service written in Clojure. That's not even that uncommon I think.

it was very common in the early days of clojure, a rails website with a clojure data processing backend. A former coworker used to call it the mullet (business in the front, party in the back), amusing to refer to ruby as business

when at I worked at a place like that we didn't have any kind of special sauce for communicating between clojure and the rails app, just http apis. not very different from what is in vogue these days (a react frontend talking over http apis to some backend)

My only memory of Ruby/Rails is that I had to learn it very quickly for a client project in a consulting company and it turned out to be a non-standard Rails project: we needed to disable the ORM stuff (https://github.com/nulldb/nulldb) and at the same time deal with a real database. Because we didn't manage that database and to reduce going back and forth with their sysadmins we asked for just one text column we could write to in which we just wrote JSON. Half way in the project the client imposed to use that we needed to run in their JBoss server so we switched to JRuby and only needed to port some imagemagick code to awt, which surprisingly all worked. Debugging prod problems was very hard since we could not access their machines because of security reasons. After that, I never used Ruby/Rails again.

Yes @borkdude, I was wondering on how common/uncommon it’s approach and hope to gather other opinions

(That project I was referring to would have been much easier (yes, easier!) in Clojure instead of working around Rails.)

Yes, @deleted-user Sean did a awesome work on Coast

It’s another Sean

ahahah

Ah nice, so you know him

I follow his work with Janet as well

The joy framework

I think I saw a talk about this on ClojureD once

Yes, I think that he presented there

(https://www.youtube.com/watch?v=24PRtDJGvW8)

> (That project I was referring to would have been much easier (yes, easier!) in Clojure instead of working around Rails.) Definitely!

I think the last project I heard about is the classical Flighcaster case: https://www.infoq.com/articles/flightcaster-clojure-rails/

@borkdude Would it be too hard to use libSCI to run some Clojure code inside Ruby? Or am I deep-dreaming too much? 😄

yeah, you could prepare yourself a native shared lib like that and then use that within Ruby, no problem ;)

Hmmmm

(more info: https://github.com/borkdude/sci/blob/master/doc/libsci.md)

you don't even need SCI if you don't need evaluation. just GraalVM native-image and compile as shared lib of what you want to expose.

I’ll play with it