Clojurians Log v2

@alexmiller I also would like to translate into Japanese. I’ll do whatever I can to help.

Thanks for this. Preordered a physical copy on Amazon. Would buy it direct but can't seem to find a preorder option?

Pragmatic does not print physical books themselves, they go through a distributor for all of that

they only directly sell ebooks on their site

Great to know. Am a direct ebook buyer of many other Clojure works, including your 3rd edition

I'm happy you get the book, really don't care about the revenue side of how you get it (as there is very little of it that trickles down to me regardless :)

ultimately, I would love to work with the publisher to make it freely available, but that will be a few years out I suspect

Just let me know whatever I can do to keep tricking you into writing them 🙂

@alexmiller Hi Alex, sorry to ping you like this, but what should I do to translate the book into Georgian? Legally speaking. I have never done it before and I'd like to take on this mission; to this day we still don't have introduction to programming in Georgian and this way we might bring considerable number of my fellow countrymen and women into the community ^^

I'll dm you

Thank you ^^

intriguing challenge thinking-face

Learning everything is impossible. I have to be very selective with what I learn. I'm running out of time.

I'd say posts like that are more suitable for #off-topic. Anyway, it seems to me that all it's saying is basically "know your tools". As such, the message is quite limited and doesn't consider the following things one should also know: • What the limitations of the tools are • When to use the tools • When to work on improving them • When, instead, to switch to learning and using other tools Meaning, just the fact that you know Clojure and some bits of its ecosystem that were pertinent to your previous projects, doesn't mean that it makes sense to stick to Clojure and those specific bits. Maybe you should be using a different library for the next project because it's sufficiently different, maybe you should write one from scratch, or maybe you should switch to a completely different language.

It's true that I can't anticipate the future, but in retrospect, I recognized that there is a value in gradually growing your core tech stack over time. You will gradually develop something like a core tech stack over time. It's not like you will suddenly become a drone programmer and have to write C++ after doing web programming for 10 years. You can be forced to write javascript or typescript, but that can be anticipated in advance. I can't perfectly anticipate what my core tech stack will look like, but I have a good guess.

I know that I will stick to web development for as long as possible. I want to control my tech stack from top to bottom, so I am trying to launch my web development agency.

You will gradually develop something like a core tech stack over time.I don't think I agree with this statement, unless "core" here means "something unchangeable", and that limits the scope beyond any usefulness. Yeah, I know and love Clojure and so far I have no plans on switching to some other language (which by itself adds factors other than efficiency in terms of the target output of a project). But I've switched between many libraries throughout the years, and will most definitely continue doing so as my tastes change and further mature, as new libraries are developed, as old ones stop being suitable for my needs. E.g. I used to use Yada. It never got finished, I don't use it anymore. I used to use Aleph, but it's insanely hard to debug and doesn't bring me anything that would be useful to me compared to a regular Jetty with a Ring adapter, so I don't use it anymore. I used to use clojure.java.jdbc, but I switched to a sufficiently different next.jdbc. HoneySQL v1 -> v2, lein -> clj, figwheel -> figwheel-main -> shadow-cljs, and a plethora of other libraries/tools with smaller scale.

Well, that can happen, but clojure is still a part of your core stack, isn't it? You write HTML, CSS, and javascript if you do web development? There are parts that don't change. I'm aware that some parts change.

> You write HTML, CSS, and javascript if you do web development? Occasionally, yes. Depends mostly on the project. > There are parts that don't change. I'm aware that some parts change. The thing is, a language is a very small part of your stack. (That is, unless that language is as enormous and complex as C++ or as everchanging as Scala or Swift, but screw that noise.) And everything else can and will eventually change enough for anyone to consider it a "new" thing. I've switched my main language 4 times: C++ -> Java -> Python -> Clojure. I know or dabble in multiple other languages, although none of which I would call my "main". And I would never say that learning anything other than those 4, or even learning C++/Java/Python before Clojure was an inefficient usage of my time.

I wish I won't have or want to change my tech stack as often as you do.

It doesn't happen often. But I've been a developer for almost 20 years now. :) As I said - from my perspective it's actually quite beneficial, at least when you like the process of making things and not just observing the results, in which case you probably should simply hire someone else instead of caring about stacks. Kind of a tangent, but still related - I remember when I explained how memory works from the perspective of a C programmer to a friend who only ever knew Python. She then said that it was the most eye-opening programming-related conversation in her life and that she now thinks that she understands Python much better.

Except I don't have enough money to hire someone... If all programming is done by employees and I don't have to write code ever again, I might actually stop caring about tech stack. But, for now, I have to do everything on my own.

Learning a new programming language (again - a reasonable one and not something like C++) would take a week to a month. Playing around with its ecosystem, reading the source code of the main libraries, creating a few show-case projects and delving into debugging - another month or two. So up to three months it would take me to switch to a completely new stack and be around 80-90% as efficient as a person who's been in that stack for a decade. It's not a hyperbole or a hypothetical. So I don't quite get it when someone wants to stick to a particular stack just to save those 3 months.

Anyway, thanks for sharing your perspective. It's very informative.

When I got started in professional programming, I wrote COBOL and assembler. Then I joined a company where C was the primary language. Over time, my day-to-day programming shifted from C to C++ and then to Java. Then the company I was at (Macromedia) bought a company that had a web development language and my team transitioned mostly to that (ColdFusion, running on the JVM). Then I worked at a company where we chose Groovy as our primary language. At my next company, we chose Scala, then decided that didn't really work for us and switched to Clojure. Along the way, there was also some professional Pascal, Parallel C / Inmos Transputer / Occam, Prolog, Perl, ActionScript, JavaScript... So many changes have happened in IT over the decades. In amongst all of that, visual development environments, object databases, a variety of code generator tools and "higher-level languages" (although none of that "stuck" really). And just recently, LLMs have changed the landscape again.

I'd like to "personally" stick to my currently chosen tech stack for as long as possible. The time spent on context switching is wasted time. I want to minimize context switching. I learned that learning a new tech stack without a really good reason for marginal gains is not a good idea. If I am going to switch, there must be a clear reason. I want to resist shiny new objects.

I've been doing Clojure professionally for about 15 years at this point so that's relatively stable. But I still use Java knowledge (it's been about 30 years since I picked up Java). At work, I also have to work with our JS codebase (150k lines, same size as our backend Clojure codebase). There are pros and cons to everything.

It's good that you aren't trying to tear down js codebase for another language. Chasing shiny new objects is a trap.

The Pragmatic Programmer book suggests that developers can enhance their skills overall by "learning a new programming language every year". I think that's overly aggressive / ambitious but I tend to try to learn a new language every couple of years. Seven Languages in Seven Weeks is a great book for that. Learning other languages helps you see problems and solutions in a different way. As a Community Teaching Assistant on Coursera, I've learned and help teach: Ruby, Standard ML, Racket. On my own, I've learned Haskell, Elm, Rust, Kotlin, and a bunch of other niche languages, as a way of picking up new ideas that help make me a better developer.

I also learned a few other programming langauges including haskell and raku, and I decided to stick to clojure(script) for as long as possible and learn new things only for things that can't be done by clojure(script). For example, gnu guix for infrastructure as code. I ran out of time to explore. Human lifespan is so short. I am required to produce results soon. I decided to pick one stack and try not to deviate from it. I want changes to be minimal and slow. I need a stable foundation on which I can build as quickly as possible. If the foundation is shaky, I can't build fast. It's good that facebook is not trying to dismantle its PHP codebase and shopify isn't trying to abandon ruby. I want my work to be largely additive. If things keep changing, I have to re-do over and over.

I'm not trying to be the best programmer that I can be, but I need to be competent as a programmer. Once I have the basics down, I want to focus more on marketing and sales because I want to run my own web development agency.

I'd go even further and say that in this world of AI, your deep knowledge matters even more than your wide knowledge. If you can both really grok and really communicate something narrow, AI can help you apply it pretty well across multiple disciplines

I will say, it depends on your goals and what you want to build. Personally, the fundamentals of programming, computers, networks, operating systems, algorithms, data-structures, code structure, code execution, system engineering, project management, development methodology, operational management, infrastructure, etc. Those are all fundamental and once you master these, the tech stack is but a different car, but now you know how to drive, sure some cars need a bit of adjusting to them, some are larger, longer, slower, faster, etc. but if you know the fundamentals you can easily adapt. That said, the above I would say is more geared towards being a software engineer, where you can go on to build most anything, a game, a complex Desktop application, various back ends, a full stack web app or website, and so on. If you know you'll only ever want to build websites, and I don't mean a Netflix, Facebook, Uber, but simpler content publishing websites, or basic dashboards or online stores. And that's what you target, you can master a single tech stack instead. The tech stack in reality hides the real underlying system and prevents you from ever learning it. It gives you a simplified higher level set of controls, but that is more restricted to what it can do and how it can do it. If you only ever want to do what it can in the way it does, then it's awesome. Otherwise I would say the above fundamentals are better to learn first.

I intend to be a T-shaped expert. I dabbled with programming(clojure DDNS client, a haskell TUI application, raku, python, java, javascript, ...), computers, networks(I know how to manually write nft firewall rules, manage a DNS/DHCP server, manage network namespaces, ...), operating systems(debian, gentoo, gnu guix, freebsd, arch), algorithms(a few sorting algorithms), data structures(their performance characteristics), coding, and system engineering(my flavor is gnu guix) to a degree but will specialize in one unified stack for building up centralized leverages as fast as possible. If my business grows beyond my personal capability, then I can hire experts. I can do everything, but I'm not an expert at anything. I just know enough to know which tools I should use for tasks at hand. I want to be the CEO and the CTO for my agency. Perhaps, I won't have to be the CTO in the future, but if the worst scenario is I have to be the CTO for the rest of my life, that's fine. I think that's enough leverage that I can potentially pivot to a real SaaS business later in the future. In the future, I want to try SaaS on top of the safety net provided by an agency. If I start with no-code/low-code platforms, there is no way I can pivot from an agency without already having a lot of money already. I want to have options. I will have to learn project management and people management. I plan to read a few books in Robert C. Martin series. I aim to be competent in my niche. Perfection is not required. I don't have time to do everything perfectly.