Interesting to see a few posts on HN recently advocating for 'dumb' or 'boring' tech as I'd been writing an article on 'dumb technology' along the same lines. Comments welcome. https://www.researchgate.net/publication/358248465_Dumb_Tech...
Boring Technology Checklist
91–100 of 119 posts
Re: Boring Technology Checklist
#92This is fine insofar as it provides a checklist to evaluate if technology is boring, but it rests entirely on "Choose Boring Technologies", which I've never found particularly compelling.
It's less "Choose Boring Technologies" and more "Don't introduce something new just because it's new". Have a compelling reason. And both this article, and the original Choose Boring Technologies, kinda miss that.
I'd be much more interested in guidelines of when to choose something new; a prior job prior to my joining chose Erlang for a mid-sized project, despite no one on the team knowing it, and it was a success. So we chose it (after I joined) for a large project, and it was, to quote the executive of a business unit it was for "the biggest success to come out of (our department)".
Both of these projects -could- have been done in one of the existing house languages...they would not have been done as quickly, resulted in nearly as good an outcome (predominantly amongst resiliency, which is why we chose Erlang), nor have given the team as much enjoyment (itself being part of the reason for the results, as a knock on effect).
Re: Boring Technology Checklist
#93Weirdly enough I do believe Clojure ticks the boxes from that checklist. It's familiar in that it both "supports popular language runtimes" (runs on top of the JVM or transpiles to JavaScript) and it's a Lisp dialect (or close enough) and Lisps have been around since a very long time. It's incredibly stable: so stable some libraries commonly used haven't been updated in years . There's also very little code churn ins…
I like Clojure, but it's really the exact opposite of the sort of "boring technology" that this post advocates. If MongoDB costs you 2 innovation tokens, Clojure costs at least 2, perhaps all 3. The cost of innovation is not so much in the core of Clojure itself, but that once your company gets larger, you will want to integrate with more and more things that have not put effort into Clojure compatibility, just becau…
What is this 'Clojure compatibility' of which you speak? Seriously though, Clojure runs on the JVM so the entire Java ecosystem is available. There are ways to run an external process too of course. I can't really think of an example where 'Clojure compatibility' is something we would require people to have thought about.
Re: Boring Technology Checklist
#94Hey OP or mods, could you please update this link Dunno where the staging server came from https://blog.begin.com/posts/2022-01-27-the-boring-technolog...
I'm years out of date on this stuff, but I note the staging URL has found its way into Google as well, you might be able to fix that up by adjusting the https://blog.staging.begin.com/..." /> to point to the authoritative URL even when the page is on the staging server.
Re: Boring Technology Checklist
#95Weirdly enough I do believe Clojure ticks the boxes from that checklist. It's familiar in that it both "supports popular language runtimes" (runs on top of the JVM or transpiles to JavaScript) and it's a Lisp dialect (or close enough) and Lisps have been around since a very long time. It's incredibly stable: so stable some libraries commonly used haven't been updated in years . There's also very little code churn ins…
Nope, boring technology is using the platform system language, Java. Nothing extra to install, everything works out of the box, no need for FFI or incomprehensible stack traces.
Clojure doesn't need FFI, neither does it need anything to run but the JVM, you package your application in a jar and run it the same as always, and you only write Java using your system editor and the JDK in introductory compsci courses.
Re: Boring Technology Checklist
#96Node.js seems boring at this point
Not the 350+ libraries you need to pick to build anything useful with it.
Re: Boring Technology Checklist
#97Earlier quoted context omitted.
Nope, boring technology is using the platform system language, Java. Nothing extra to install, everything works out of the box, no need for FFI or incomprehensible stack traces.
Clojure doesn't need FFI, neither does it need anything to run but the JVM, you package your application in a jar and run it the same as always, and you only write Java using your system editor and the JDK in introductory compsci courses.
It surely does, calls go both ways, and Closure doesn't understand everything introduced on the JVM since Java 8.
Poor students, at least Blue/J.
By the way, I already used Clojure in projects.
Usually I only critic stuff I actually know.
Re: Boring Technology Checklist
#98Earlier quoted context omitted.
What is everyone gyrating around at the moment? I haven’t touched front end for about a decade. It was jquery back then.
I'd say React has reached boring by JS standards.
Except for React introduces major changes with every new version causing thrash.
Re: Boring Technology Checklist
#99Earlier quoted context omitted.
I like Clojure, but it's really the exact opposite of the sort of "boring technology" that this post advocates. If MongoDB costs you 2 innovation tokens, Clojure costs at least 2, perhaps all 3. The cost of innovation is not so much in the core of Clojure itself, but that once your company gets larger, you will want to integrate with more and more things that have not put effort into Clojure compatibility, just becau…
What is this 'Clojure compatibility' of which you speak? Seriously though, Clojure runs on the JVM so the entire Java ecosystem is available. There are ways to run an external process too of course. I can't really think of an example where 'Clojure compatibility' is something we would require people to have thought about.
A simple example is, let's say you're making a small web service. Are you going to use a Clojure framework or a Java framework via JVM compatibility? If you pick a Clojure framework, then all the subsequent choices you have to make, you'll run into the "non boring tech" issues. Has someone already built a GraphQL plugin, a plugin that integrates with the Twitter preview API, etc etc it depends on your project but you'll run into things. If you pick a Java framework, you'll end up running into a bunch of cases where you can't use the "normal solution" for that framework because you're running Clojure.
It's not the end of the world or anything, and for a smaller project Clojure might be the perfect solution. But if it's something that you're trying to scale into a startup with dozens of engineers then you're probably going to pay a higher incompatibility cost for using Clojure.
Re: Boring Technology Checklist
#100Earlier quoted context omitted.
How about hiring though? If you have a vacancy for a Clojure developer, how many applicants could you expect? When it comes to programming languages, I'd stick to the top 10 languages if your company isn't hip enough to attract a certain kind of developer on its own.
When hiring / recruiting Clojure devs, there are quite a few second-order effects which are quite unintuitive. Clojure devs are much more senior - they've typically been burnt by at least one tech stack, often more (Java, JS + React, Fortran, Cobol, punching tape, etc.). Clojure devs also tend to be really passionate about, you guessed it, Clojure, which commonly turns out to be a good thing. People passionate about…
All the points you're saying here are the usual arguments for choosing non-boring technology (I think I've seen this argument essentially verbatim for CL, Haskell, Clojure, Elixir, etc.), which is fine in isolation, but doesn't really fit in a thread about Clojure as boring technology.