Ah clojure. It's all fun and games until five years down the line, you've had 100% dev churn, and you have a 100kloc codebase that nobody understands, full of functions that don't give the slightest hint of the shape of the data they're processing (it's all lists!) yet down the bottom of the callstack there's some function that'll explode if the map doesn't have whatever magical key it expects. If you're really lucky…
OK but that's a 500k LOC codebase in javascript/python that nobody understands, maybe the project doesn't even get there everybody hates their language when they have 100k LOC of tech debt from 8 years ago You're right that Clojure's sequence soup problem is painful at that scale (really any scale) but have you ever debugged Java? It's barely even possible, the project needs to drive $10M+/yr revenue to just not coll…
Building a Startup on Clojure
101–110 of 215 posts
Re: Building a Startup on Clojure
#102Earlier quoted context omitted.
This is my experience exactly. I love the language and ecosystem in a lot of ways. I also believe that REPL-driven-development is a ridiculously productive way to work. But I absolutely hate maintaining an old Clojure codebase (unless it's tiny). The REPL helps a lot with discovering what the proper way is to call any random function you have in your code, but this is still really super annoying. I really hate to get…
i'm starting to feel that REPL driven development can be bad for maintenance, when you have a REPL, you can write ridiculously compact and abstract code that is hard to understand just by reading it.
Re: Building a Startup on Clojure
#103For me, the killer feature of Clojure is "REPL driven development". The ability to get rapid feedback as you build things up is incredible. I'll make a comment form and evaluate expressions within it to try things out as I go. By the time I've written any reasonably complex function, all of the pieces have been tested on various examples. Once I'm done, the comment form leaves a helpful record of my thought process.…
Re: Building a Startup on Clojure
#104Ah clojure. It's all fun and games until five years down the line, you've had 100% dev churn, and you have a 100kloc codebase that nobody understands, full of functions that don't give the slightest hint of the shape of the data they're processing (it's all lists!) yet down the bottom of the callstack there's some function that'll explode if the map doesn't have whatever magical key it expects. If you're really lucky…
OK but that's a 500k LOC codebase in javascript/python that nobody understands, maybe the project doesn't even get there everybody hates their language when they have 100k LOC of tech debt from 8 years ago You're right that Clojure's sequence soup problem is painful at that scale (really any scale) but have you ever debugged Java? It's barely even possible, the project needs to drive $10M+/yr revenue to just not coll…
And let's be frank, XML, other than for Maven (where it can make sense), is not really a thing in modern Java.
Re: Building a Startup on Clojure
#105Earlier quoted context omitted.
Building a company in Python feels like a bet against yourself ie the company/codebase will never get big enough that using Python (lack of static typing etc) will ever be a problem
If you use Python and you aren't aware of its tradeoffs, yes it is going to bite you. Dynamic typing and the lack of a formal compilation step are great for productivity, but they come at a cost. You need a proper CI pipeline to run linters (granted, you need that in statically typed languages too) and, most importantly, you need to write tests. Sure, you need to write tests for any language, but not having them for…
Re: Building a Startup on Clojure
#106Ah clojure. It's all fun and games until five years down the line, you've had 100% dev churn, and you have a 100kloc codebase that nobody understands, full of functions that don't give the slightest hint of the shape of the data they're processing (it's all lists!) yet down the bottom of the callstack there's some function that'll explode if the map doesn't have whatever magical key it expects. If you're really lucky…
This is my experience exactly. I love the language and ecosystem in a lot of ways. I also believe that REPL-driven-development is a ridiculously productive way to work. But I absolutely hate maintaining an old Clojure codebase (unless it's tiny). The REPL helps a lot with discovering what the proper way is to call any random function you have in your code, but this is still really super annoying. I really hate to get…
However, I find myself running Ruby/Rails (console) in debug mode in RubyMine (Jetbrains IDE). The REPL-like experience seems quite close to that of Clojure, with the added benefit of being able to easily enable and disable breakpoints and see my local data (and snapshots of all previous local data up the call stack).
And honestly, the Clojure thing that always stops me from actually getting a full anything built is the lack of frameworks and approaches which have critical mass. It's always the same answer, "We like to choose our own libraries." That's lovely once you know what you're doing, but the ramp-up time is just SO much slower than with other languages.
Considering the time to working proof of concept is critical quite often, few beginners have time to figure out all the libraries and tooling and integrations to build something in Clojure.
I think despite still wishing I had a Clojure backend with Clojurescript/React frontend, I'll step from my Rails PoC to a Phoenix/Elixir product and be successful and happy (and have a lot of people doing something similar, with similar tools and libraries).
Re: Building a Startup on Clojure
#107Earlier quoted context omitted.
This is my experience exactly. I love the language and ecosystem in a lot of ways. I also believe that REPL-driven-development is a ridiculously productive way to work. But I absolutely hate maintaining an old Clojure codebase (unless it's tiny). The REPL helps a lot with discovering what the proper way is to call any random function you have in your code, but this is still really super annoying. I really hate to get…
i'm starting to feel that REPL driven development can be bad for maintenance, when you have a REPL, you can write ridiculously compact and abstract code that is hard to understand just by reading it.
When using the REPL you can quickly experiment until it does what you want, but you need the discipline to distill something maintainable from it afterwards.
Re: Building a Startup on Clojure
#108Ah clojure. It's all fun and games until five years down the line, you've had 100% dev churn, and you have a 100kloc codebase that nobody understands, full of functions that don't give the slightest hint of the shape of the data they're processing (it's all lists!) yet down the bottom of the callstack there's some function that'll explode if the map doesn't have whatever magical key it expects. If you're really lucky…
OK but that's a 500k LOC codebase in javascript/python that nobody understands, maybe the project doesn't even get there everybody hates their language when they have 100k LOC of tech debt from 8 years ago You're right that Clojure's sequence soup problem is painful at that scale (really any scale) but have you ever debugged Java? It's barely even possible, the project needs to drive $10M+/yr revenue to just not coll…
Re: Building a Startup on Clojure
#109Ah clojure. It's all fun and games until five years down the line, you've had 100% dev churn, and you have a 100kloc codebase that nobody understands, full of functions that don't give the slightest hint of the shape of the data they're processing (it's all lists!) yet down the bottom of the callstack there's some function that'll explode if the map doesn't have whatever magical key it expects. If you're really lucky…
Re: Building a Startup on Clojure
#110Earlier quoted context omitted.
This is my experience exactly. I love the language and ecosystem in a lot of ways. I also believe that REPL-driven-development is a ridiculously productive way to work. But I absolutely hate maintaining an old Clojure codebase (unless it's tiny). The REPL helps a lot with discovering what the proper way is to call any random function you have in your code, but this is still really super annoying. I really hate to get…
i'm starting to feel that REPL driven development can be bad for maintenance, when you have a REPL, you can write ridiculously compact and abstract code that is hard to understand just by reading it.
That is a slightly shallow take though because its not really symmetrical like that. You can use a REPL as a way to arrive at the most easily understood rendition of something. But that is very prone to subjective bias as lots of things seem obvious in retrospect that are not at the start.
To the extent that the answer you eventually arrived at is a result of learning a mental model of the data and functions surround it, it will leave a significant residual gap for the next person who comes a long to bridge.