Clojure(+Script) is a most illuminating language. It teaches (forces) you to structure the flow of data in a refreshingly simple way.
(next Rich)
141–150 of 158 posts
Re: (next Rich)
#142Earlier quoted context omitted.
Hah, very fitting way to put it :)
Agree. For those not familiar with Rich's famous use of etymology, see his 2011 presentation "Simple made Easy" as a good example: https://www.infoq.com/presentations/Simple-Made-Easy/ Side question: Rich seems to use etymology as a tool for original thinking and clear explanations. Are there other people who do this as well as he does?
And yet, the word Hickey coined, "complect", is silly at best, and a gatekeeping obstacle to outsiders/newcomers at worst.
Re: (next Rich)
#143Amazing news. I saw a video cast of Rick during a meeting @ NuBank, and it looked like corporate life had sucked the life out of him [1]. So, I'm glad he got out of there, and I hope he's able to shake it off like a bad dream. Building something like Clojure require radical thinking, and creative freedom. I can only imagine how trying to fit that into your weekly scrum sprint would be draining. And in the monthly mee…
Maybe you're just used to seeing him in "on" mode (giving legendary conference presentations) and he's more subdued when doing everyday work. It's a bit distasteful to virtually follow him around and speculate about his mental health.
After two years at Cognitect (pre-nubank), I can say that his talks are more subdued than his usual way of speaking (in slack, at least). He's not as mild-mannered as he appears.
Re: (next Rich)
#144Earlier quoted context omitted.
Agree. For those not familiar with Rich's famous use of etymology, see his 2011 presentation "Simple made Easy" as a good example: https://www.infoq.com/presentations/Simple-Made-Easy/ Side question: Rich seems to use etymology as a tool for original thinking and clear explanations. Are there other people who do this as well as he does?
And yet, the word Hickey coined, "complect", is silly at best, and a gatekeeping obstacle to outsiders/newcomers at worst.
Re: (next Rich)
#145This is probably great news for clojure devs. It sounds like Rich just wants his autonomy back. Being able to choose exactly what you do, and do not, work on is precious.
[deleted]
Re: (next Rich)
#146I started on the JVM in '97 at University. Damn I'm old.
The company I founded uses full stack Clojure for our product development (https://kpow.io).
We're a small team pushing through a big product roadmap at pace, love programming every day, no chance we'd have made it in Java (and I quite like Java).
Thanks Rich (and Stu, and Alex, and Fogus, and David, and..)!
Re: (next Rich)
#147Earlier quoted context omitted.
Agree. For those not familiar with Rich's famous use of etymology, see his 2011 presentation "Simple made Easy" as a good example: https://www.infoq.com/presentations/Simple-Made-Easy/ Side question: Rich seems to use etymology as a tool for original thinking and clear explanations. Are there other people who do this as well as he does?
And yet, the word Hickey coined, "complect", is silly at best, and a gatekeeping obstacle to outsiders/newcomers at worst.
Funnily enough, your complaint here is that although it may be simple, it is not necessarily easy, while the talk is an argument that we should prefer simplicity even at the cost of some (temporary) un-ease.
Re: (next Rich)
#148Rich, thank you for creating and maintaining a tool that has helped me build a successful SaaS business. I could not have done this without your work and your insights. I also learned a lot from your talks, and I do hope to meet you again at one of the Clojure conferences.
Curious, what SaaS space are you in where you found Clojure was a good fit? Would love to add this info to my brain-base for future ideas :)
I think Clojure is a good fit in a lot of SaaS applications, especially those that are complex. It helps in dealing with complex problem domains, and lets you reuse the same code on the client side (through the magic of ClojureScript). Small benefits accumulate, and while it's possible to write anything using any language and tools, Clojure reduces the amount of code and work that I have to do, thus enabling me to run a solo-founder business.
Re: (next Rich)
#149Earlier quoted context omitted.
> because Clojure / Java wasn't performant enough Languages aren't "performant". You can write good or bad code in most languages, or code that isn't a good fit for a language. That said, there are languages which will make you incur certain penalties, as there is a price to be paid for automatic memory management with garbage collection, for example. These penalties generally do not matter except for edge cases (and…
There is “the expected performance of idiomatic code”, though, which is what most people mean when they talk about the performance of a language.
Yes. And it really doesn't matter in practice. In a larger system this kind of performance won't matter. What will matter is design decisions, data structures, databases and access patterns — things that are much more high-level than "language performance".
Re: (next Rich)
#150Earlier quoted context omitted.
So you had to switch to C++ because Clojure / Java wasn't performant enough?
> So you had to switch to C++ because Clojure / Java wasn't performant enough? Clojure yes, java no. Many HFT firms build their systems in java and run on the jvm(specialized hardware aside), its plenty fast if you avoid memory allocations. It is also possible Clojure is more than up to the task now and its also reasonable to believe that I wasn't a strong enough clojure developer to fix those issues at the time and…
> ... its also reasonable to believe that I wasn't a strong enough clojure developer to fix those issues...
Technically it can likely be done but in practice pushing Clojure code for performance (eg, [0]) doesn't follow the usual language idioms and relies on a sophisticated understanding of the interactions between program design, Clojure, the Clojure compiler and the JVM. I'd suggest pointing more at the language than the programmer. In a situation where direct memory management is required Clojure is a weaker choice.
Although in Clojure's defence it leverages immutability to squeeze out some surprising performance benefits without much effort. I would expect Clojure code to be fast by default but challenging to hand-optimise further if that extra level of control is required. Clojure makes it easy to write code that performs well, it is a stronger language for situations where ordinary business logic changes are the productivity bottleneck.
[0] https://blog.redplanetlabs.com/2020/09/02/clojure-faster/