Interesting story. I am not entirely convinced that all credit should go to the programming language here, though.
My theory is that communicating abstractions is hard. If you work on your own, or in a (very) small team, you can come up with powerful abstractions that allow you to build amazing systems, quickly. However, sharing the underlying ideas and philosophy with new team members can be daunting. As systems grow, and mistakes are made, it becomes more and more likely that you run into serious problems.
This may also be why Java and similar object oriented programming languages are so successful for systems that have to be maintained for ages, by large teams of developers. There are but few abstractions and patterns, and it does not allow you to shoot yourself in the foot, nor to blow your whole leg off. Conversely, this may also be why complex frameworks, such as Spring, are not always so nice, because they introduce (too?) powerful abstractions, for example through annotations. It may also clarify why more powerful languages such as Scala, Common Lisp, Smalltalk, Haskell, etc, consistently fail to pick up steam.
Another theory is that not every developer is comfortable with abstract concepts, and that it simply takes a team of smart people to handle those.
> It may also clarify why more powerful languages such as Scala, Common Lisp, Smalltalk, Haskell, etc, consistently fail to pick up steam.
Languages need a window of opportunity, and many of those squandered it.
Clojure won over Scala because at the time when people were loooking for an alternative JVM langauge, Clojure was more of a departure from Java and seemed to have better tooling (compile times and syntax support) than Scala.
Smalltalk and Common Lisp wasted their moment by not being cheap/free to people using micros in the 1980s.
Lisp, especially, very much wasted its moment with micros. The fact that no Lisper had the vision to dump a Lisp onto the bank switched micros (which makes GC really easy and useful) of the mid to late 1980s is a self-inflicted bullet wound. Lots of us hated doing assembly language programming but had no real alternative. This was a loss born of pure arrogance of Lispers who looked down on those micros as not being "real machines".
I weep for all the hours I wasted doing assembly language as a teenager that I could have been writing Lisp. How much software could have been written that would have been <100 lines of Lisp if only someone had written that tool?
Another theory is that C inspired languages are very mechanistic and easier to visualize. Same goes for OOP with the Animal->{Cat,Dog} explanation. But that's just surface level and once you get to the difficult part (memory management in C and software design in Java) where the ability to grasp abstractions is required, we're back to square one.
I believe once you've got to some point, dealing with abstractions is a way of life. It's either in the language, the technical requirements, or the software design.
Powerful abstractions tend to come back and bite you a few years later when the industry trends shift and everyone else starts using a different set of abstractions. Now that small team is stuck maintaining those custom abstractions forever and is unable to take advantage of new abstractions from vendors or open source projects. So their progress stagnates while competitors race ahead. I've been on the wrong side of that before.
> object oriented programming languages are so successful for systems that have to be maintained for ages,
ehmmm.... excuse me.... erghmm... what about Emacs? I'm sure, it absolutely can be count for a "successful system that have to be maintained for ages". For far, far longer than any Java-based project that ever existed.
Even though Elisp lacks:
- static typing
- OOP class system (until relatively recently)
- Modern package management (until ELPA/MELPA)
- Multi-threading model
- JIT compilation
Perhaps "the secret sauce" of successful software is in simplicity? Maybe some programmers just get it, and for others, it is such an obscure and mysterious entity. Some programmers write "programs to program computers", and some may have realized that they are not trying to solve purely technological problems, but they are, in fact, tackling socio-technological problems, and they write programs to communicate their ideas to fellow human beings, not machines.
Clojure is a lot of fun to tinker with, but man… I love my static types. I think I’d hate to work on a large codebase in Clojure and constantly be wondering what exactly “m” is.
As a programmer with almost exclusively statically-typed compiled language experience, I used to strongly believe this too. In the last year, though, I've seriously toyed around with a number of dynamic languages, really trying to grok the dynamic mindset, and it's been very eye-opening. I never expected quite the degree of productivity boost that I have felt in these languages, and I must admit that I've also found many of them quite joyful to work with. Dynamic languages are profoundly creative, in all the senses of creative. I've found myself thinking about my programs in a totally different way, which has been really lovely (and honestly a timely reminder of what I loved about programming in the first place).
To be fair, I will readily say that the lack of static analysis really does bite when refactoring, though I think that good design principles and the overall productivity multiplier may offset that cost (also unique, descriptive, grep-able names!). I guess I've also seen enough C++ template spaghetti to know that static typing is no panacea either.
I don't know to what extent I'll use dynamic languages going forward, though for now I'm kind of in love with opening up a window into the computer and building up my digital sandcastles. Many of these languages also have a great FFI story, which is making me dream up cool bilingual projects that play on the strengths of both approaches.
All in all, no regrets about my adventures in dynamic-land.
> Clojure is a lot of fun to tinker with, but man… I love my static types.
Static types are great, but boy... I love my REPL. I think I'd hate to actually work while writing code. REPL-driven interactivity with Clojure allows me to treat the work like I'm playing a video game.
It is my favourite language on the JVM, when not using Java.
Because of being a Lisp based language, bringing something else to the table besides "lets replace Java", and the community being welcoming of the host environments where Clojure is a guest.
For us the combination of malli and clj-kondo worked really well. Also we haven't faced that problem yet, as the codebase is fairly small. But I can totally see when types become quite useful when navigating large codebases.
Maybe this architecture approach would be challenging in Java or Go, but the style of immutable data, don’t go crazy wrapping stuff in classes is very doable in most languages. We enforce “no mutation of data you did not just instantiate” at Notion, and use TypeScript’s powerful type system with tagged union types to ensure exhaustive handling of new variants which I really miss in languages that don’t have it (go).
I guess the major advantage for Closure with this style is the “persisted” data structures end up sharing some bytes behind the scenes - it’s nice the language is explicitly situated around this style, rather than TypeScript’s chaotic Wild West kitchen sink design. What I don’t understand the advantage for “state management”. Like, you build a new state object, and then mutate some pointer from prevState to nextState… that’s what everyone else is doing too.
There are times though when it’s nice to switch gears from function-and-data to an OO approach when you need to maintain a lot of invariants, interior mutability has substantial performance advantages, or you really want to make sure callers are interpreting the data’s semantics correctly. So our style has ended up being “functional/immutable business logic and user data” w/ “zero inheritance OO for data structures”.
Whenever I read some open source TypeScript code that’s using the language like it’s Java like `class implements ISomething` ruining cmd-click go to method or an elaborate inheritance hierarchy it makes me sad.
> What I don’t understand the advantage for “state management”. Like, you build a new state object, and then mutate some pointer from prevState to nextState… that’s what everyone else is doing too.
I'm curious if Elixir could provide a similar development environment?
Seems like many similar capabilities, like a focus on immutable data structures, pure functions, being able to patch and update running systems without a restart, etc.
> Today, we're building Vade Studio with just three developers – myself and two developers who joined as interns when in college. (...) Here's what we've accomplished: (...)
In how many man-hours/days? It's hard to know if the list is long or short only knowing that calendar time should be multiplied by three for calculating people time spent...
We started working on it full time around 1.5 years ago.
2 years if you count when I exploring building it in other languages.
Alongside building Vade Studio:
I have been working as a contractor for 2 clients. Developing systems for them
Other two developers have been managing their college curriculum as well.
I am not sure how to do the math around it, but anecdotally I don't think this would be possible in any other environment.
@OP "Model our domain as a graph of attributes and relationships" and "generate resolvers". I'm curious what your model looks like so that you are able to "generate resolvers"? I had looked into using Malli as the model, but curious what route you took.
Is there a technical reason I can't sign into Studio with email? I'll really try to avoid signing in with other platforms, but I'll consider Github if there's some reason it has to be. I'll never sign into a service with Google.
Because Clojure treats data as first-class citizens, we could build our own lightweight conflict resolution system using pure functions that operate on these transactions.
What does it mean to say Clojure "treat data a first-class citizen"? I understand FP would treat function as first-class citizen, but the statement seems to mean something different.
In Clojure, treating data as a first-class citizen means that data structures (like maps, vectors, sets) can be:
1. Passed as arguments
2. Returned from functions
3. Stored in variables
4. Manipulated directly
5. Compared easily
Unlike some languages where data needs special handling or conversion, Clojure lets you work with data structures directly and consistently throughout your program.
This philosophy extends to how Clojure handles data transformations. For example, transducers are composable algorithmic transformations that can work on any data source - whether it's a collection, stream, or channel. They treat the data transformation itself as a first-class value that can be composed, stored, and reused independently of the input source.
This first-class treatment of both data and data transformations makes Clojure particularly powerful for data processing and manipulation tasks.
That's why Clojure often finds strong adoption in data analytics, fintech and similar domains. The ability to treat both data and transformations as first-class citizens makes it easier to build, for example: reliable financial systems where data integrity is crucial.
OOP generally "hides" data as internal state of class instances. Everything is private unless expressed as a method on an object.
The two sentences around the one you quoted should answer the question as well:
> With Clojure, we modeled the entire collaboration system as a stream of immutable data transformations. Each user action becomes a transaction in our system.
And
> When conflicts occur, our system can merge changes intelligently because we're working with pure data structures rather than complex objects.
Whereas OOP languages combine behavior and data into a single thing (classes with methods model behavior and hide state i.e. data) functional languages separate them: functions model behavior, and data is treated more like an input and output rather than "state".
In particular with clojure, data structures tend to be immutable and functions tend to not have side effects. This gives rise to the benefits the article talks about, though is not without its own drawbacks.
They most likely refer to homoiconicity [1], as Clojure is a dialect of Lisp. However, it's hard to say for sure, and maybe they were simply referring to the built-in syntax for maps, lists, etc.
Incredible history, I feel like Clojure makes magic. What I like about functional programming is that it brings other perspectives of how things CAN work!!
I've built similar systems using Apache Airflow and Temporal, but the complexity was overwhelming. Using simple maps with enter/leave phases for workflow steps is much cleaner than dealing with DAG frameworks.
> Each new layer of complexity fed my developer ego.
I'm unable to understand this mindset. All the time I read things like "Developers love complexity because it feeds their egos" but I've never encountered a situation in which added complexity made me more proud of the work. Just the opposite: being able to do more made me more proud of the work I put in, and complexity was the price I paid for that ability. The greatest hacks, the ones that etch people's names into history, are the ones -- like Unix and the Doom engine -- that achieve phenomenal feats with very little code and/or extreme parsimony of design. This is no more true than in that famous ego-stroking/dick-measuring contest of programming, the demoscene. My favorite example being the 4k demo Omniscent: https://www.youtube.com/watch?v=G1Q9LtnnE4w
Being able to stand up a 100-node K8s cluster to provide a basic web service, connected to a React SPA front end to provide all the functionality of a Delphi program from the 90s doesn't stroke the ego of any programmer I know of; but it might stroke their manager's ego because it gives them an opportunity to empire-build and requisition a larger budget next year.
Indeed, I often tell people that one of the “hardest” things to do in software development is actually managing complexity (on any significant sized code base that is, on smaller ones it’s probably not going to be an issue).
Big long lived code bases are all about this battle against complexity and the speed at which you can add new or update features largely comes down to how well you’re doing at management of complexity.
> When conflicts occur, our system can merge changes intelligently because we're working with pure data structures rather than complex objects. This would have been significantly more complex in an object-oriented language.
Not really, in an OO language state could have been stored in some data structure as well, with a way to serialize and deserialize. E.g. React made this very popular.
I can't find pricing on the same. Though it is no code, there must be a way for me to work with code directly if i wish to do so. No mobile apps. It would be great if you can generate both web apps and mobile apps.
Ultimately, it all comes down to build what you're comfortable with. Additionally, when you're managing large organizations and teams. Build with what you can hire quickly for and easily scale with.
Quick (and cheap?) hires are not necessarily good hires.
In my experience (and my theory) developer productivity can range from 0.5x to 5x and more, and those developers in the upper range tend to look for certain programming language which they enjoy, like Rust, Go, Elixir, Scala and Clojure. They are hard to get if you are on a "boring" stack like Java, NodeJS, PHP.
So if you might need to invest some time and money to find the right people, but at the end you make a better deal: Even if the salary is twice as much, the productiviy is even more. Additionally less people means less communication overhead, which is another advante.
In my case, it was definitely worth becoming uncomfortable for a bit to learn Clojure because I was very uncomfortable with the experience of many of the other languages. It’s also great to have endless backwards compatibility and little reliance on changing external libraries baked in.
Look these folks can do whatever the heck they want, use whatever language they want.
However my criteria for selecting a language for use in a professional context:
0: fit to task - obviously the language has to be able to do the job - to take this seriously you must define the job and what its requirements are and map those against the candidate languages
1: hiring and recruiting - there must be a mainstream sized talent pool - talent shortages are not acceptable - and I don't buy the argument that "smart people are attracted to non mainstream languages which is how we find smart people", it is simply not true that "most smart people program with Scala/Haskell/Elixir/whatever" - there's smart and smarter working on the mainstream languages.
2: size of programming community, size of knowledge base, size of open source community - don't end up with a code base stuck in an obscure corner of the Internet where few people know what is going on
3: AI - how well can AI program in this language? The size of the training set counts here - all the mainstream languages have had vast amounts of knowledge ingested and thus Claude can write decent code or at least has a shot at it. And in future this will likely get better again based on volume of training data. AI counts for a huge amount - if you are using a language that the AI knows little about then there's little productivity related benefits coming to your development team.
4: tools, IDE support, linters, compilers, build tools etc. It's a real obstacle to fire up your IDE and find that the IDE knows nothing about the language you are using, or that the language plugin was written by some guy who did it for the love and its not complete or professional or updated or something.
5: hiring and recruiting - it's the top priority and the bottom and every priority in between. If you can't find the people then you are in big trouble I have seen this play out over and over where the CTO's favorite non-mainstream language is used in a professional context and for years - maybe decades after the company suffers trying to find people. And decades after the CTO moved on to a new company and a new favorite language.
So what is a mainstream language? Arguable but personally it looks like Python, Java, JavaScript/TypeScript, C#, Golang. To a lesser extent Ruby only because Ruby developers have always been hard to find even though there is lots of community and knowledge and tools etc. Rust seems to have remained somewhat niche when its peer Golang has grown rapidly. Probably C and C++ depending on context. Maybe Kotlin? How cares what I think anyway its up to you. My main point is - in a professional context the language should be chosen to service the needs of the business. Be systematic and professional and don't bring your hobbies into it because the business needs come first.
And for home/hobbies/fun? Do whatever the heck you like.
> talent shortages are not acceptable - and I don't buy the argument that "smart people are attracted to non mainstream languages which is how we find smart people", it is simply not true that "most smart people program with Scala/Haskell/Elixir/whatever" - there's smart and smarter working on the mainstream languages.
Smart people can be trained in any language and become effective in a reasonably short period of time. I remember one company I worked at, we hired a couple of fresh grads who'd only worked with Java at school based on how promising they seemed; they were contributing meaningfully to our C++ code base within months. If you work in Lisp or Haskell or Smalltalk or maybe even Ruby, chances are pretty good you've an interesting enough code base to attract and retain this kind of programmer. Smart people paired with the right language can be effective in far smaller numbers as well.
The major drawback, however, is that programmers who are this intelligent and this interested in the work itself (rather than the money or career advancement opportunities) are likely to be prickly individualists who have cultivated within themselves Larry Wall's three programmer virtues: Laziness, Impatience, and Hubris. So either you know how to support the needs of such a programmer, or you want to hire from a slightly less intelligent and insightful, though still capable, segment of the talent pool which means no, you're not going to be targeting those powerful languages off the beaten track. (But you are going to have to do a bit more chucklehead filtering.)
> if you are using a language that the AI knows little about then there's little productivity related benefits coming to your development team.
This is vacuously true because the consequent is always true. The wheels are kind of falling off "Dissociated Press on steroids" as a massive productivity booster over the long haul. I think that by the time you have an AI capable of making decisions and crystallizing intent the way a human programmer can, then you really have to consider whether to give that AI the kind of rights we currently only afford humans.
smokel|1 year ago
My theory is that communicating abstractions is hard. If you work on your own, or in a (very) small team, you can come up with powerful abstractions that allow you to build amazing systems, quickly. However, sharing the underlying ideas and philosophy with new team members can be daunting. As systems grow, and mistakes are made, it becomes more and more likely that you run into serious problems.
This may also be why Java and similar object oriented programming languages are so successful for systems that have to be maintained for ages, by large teams of developers. There are but few abstractions and patterns, and it does not allow you to shoot yourself in the foot, nor to blow your whole leg off. Conversely, this may also be why complex frameworks, such as Spring, are not always so nice, because they introduce (too?) powerful abstractions, for example through annotations. It may also clarify why more powerful languages such as Scala, Common Lisp, Smalltalk, Haskell, etc, consistently fail to pick up steam.
Another theory is that not every developer is comfortable with abstract concepts, and that it simply takes a team of smart people to handle those.
bsder|1 year ago
Languages need a window of opportunity, and many of those squandered it.
Clojure won over Scala because at the time when people were loooking for an alternative JVM langauge, Clojure was more of a departure from Java and seemed to have better tooling (compile times and syntax support) than Scala.
Smalltalk and Common Lisp wasted their moment by not being cheap/free to people using micros in the 1980s.
Lisp, especially, very much wasted its moment with micros. The fact that no Lisper had the vision to dump a Lisp onto the bank switched micros (which makes GC really easy and useful) of the mid to late 1980s is a self-inflicted bullet wound. Lots of us hated doing assembly language programming but had no real alternative. This was a loss born of pure arrogance of Lispers who looked down on those micros as not being "real machines".
I weep for all the hours I wasted doing assembly language as a teenager that I could have been writing Lisp. How much software could have been written that would have been <100 lines of Lisp if only someone had written that tool?
j45|1 year ago
Rapid application technologies, methedologies, or frameworks are not unusual.
I know some wonderfully productive polyglot developers who by their own choice end up at Clojure. It doesn't have to be for everyone.
I wouldn't rule out that Clojure doesn't deserve credit. I wouldn't think it's a good idea to discredit Clojure from not having tried it myself.
I do hope someone with extensive Clojure experience can weigh in on the advantages.
How easy something is a codebase grows is something to really consider.
This product regardless of how it's built is pretty impressive. I'd be open to learning advantages and comparisons without denying it.
skydhash|1 year ago
I believe once you've got to some point, dealing with abstractions is a way of life. It's either in the language, the technical requirements, or the software design.
nradov|1 year ago
pntripathi9417|1 year ago
In the end it's about designing abstraction, and community's focus on designing simple abstractions drove me in designing the whole system.
Now once I have the working system, I am fairly sure it can be implemented in any language.
iLemming|1 year ago
ehmmm.... excuse me.... erghmm... what about Emacs? I'm sure, it absolutely can be count for a "successful system that have to be maintained for ages". For far, far longer than any Java-based project that ever existed.
Even though Elisp lacks:
- static typing
- OOP class system (until relatively recently)
- Modern package management (until ELPA/MELPA)
- Multi-threading model
- JIT compilation
Perhaps "the secret sauce" of successful software is in simplicity? Maybe some programmers just get it, and for others, it is such an obscure and mysterious entity. Some programmers write "programs to program computers", and some may have realized that they are not trying to solve purely technological problems, but they are, in fact, tackling socio-technological problems, and they write programs to communicate their ideas to fellow human beings, not machines.
christophilus|1 year ago
troad|1 year ago
To be fair, I will readily say that the lack of static analysis really does bite when refactoring, though I think that good design principles and the overall productivity multiplier may offset that cost (also unique, descriptive, grep-able names!). I guess I've also seen enough C++ template spaghetti to know that static typing is no panacea either.
I don't know to what extent I'll use dynamic languages going forward, though for now I'm kind of in love with opening up a window into the computer and building up my digital sandcastles. Many of these languages also have a great FFI story, which is making me dream up cool bilingual projects that play on the strengths of both approaches.
All in all, no regrets about my adventures in dynamic-land.
iLemming|1 year ago
Static types are great, but boy... I love my REPL. I think I'd hate to actually work while writing code. REPL-driven interactivity with Clojure allows me to treat the work like I'm playing a video game.
pjmlp|1 year ago
Because of being a Lisp based language, bringing something else to the table besides "lets replace Java", and the community being welcoming of the host environments where Clojure is a guest.
f1shy|1 year ago
Not that I “feel” it was no problem, but there were no bugs found that could be traces down to that.
It was not a small codebase.
pntripathi9417|1 year ago
ilrwbwrkhv|1 year ago
medo-bear|1 year ago
[deleted]
tmtvl|1 year ago
jitl|1 year ago
I guess the major advantage for Closure with this style is the “persisted” data structures end up sharing some bytes behind the scenes - it’s nice the language is explicitly situated around this style, rather than TypeScript’s chaotic Wild West kitchen sink design. What I don’t understand the advantage for “state management”. Like, you build a new state object, and then mutate some pointer from prevState to nextState… that’s what everyone else is doing too.
There are times though when it’s nice to switch gears from function-and-data to an OO approach when you need to maintain a lot of invariants, interior mutability has substantial performance advantages, or you really want to make sure callers are interpreting the data’s semantics correctly. So our style has ended up being “functional/immutable business logic and user data” w/ “zero inheritance OO for data structures”.
Whenever I read some open source TypeScript code that’s using the language like it’s Java like `class implements ISomething` ruining cmd-click go to method or an elaborate inheritance hierarchy it makes me sad.
knubie|1 year ago
Clojure's real super power is its reference type(s) (in particular the atom). Rich does an excellent job explaining them in this video: https://www.youtube.com/watch?v=wASCH_gPnDw&t=2278s
jimbokun|1 year ago
Seems like many similar capabilities, like a focus on immutable data structures, pure functions, being able to patch and update running systems without a restart, etc.
kevinmershon|1 year ago
CIDER and nREPL is better tech than IEX though. I live in both and Clojure is much more enjoyable.
e12e|1 year ago
In how many man-hours/days? It's hard to know if the list is long or short only knowing that calendar time should be multiplied by three for calculating people time spent...
pntripathi9417|1 year ago
2 years if you count when I exploring building it in other languages.
Alongside building Vade Studio: I have been working as a contractor for 2 clients. Developing systems for them Other two developers have been managing their college curriculum as well.
I am not sure how to do the math around it, but anecdotally I don't think this would be possible in any other environment.
j45|1 year ago
jolt42|1 year ago
knubie|1 year ago
https://pathom3.wsscode.com/
heypragyan|1 year ago
joeevans1000|1 year ago
j45|1 year ago
I only use google for email logins for services I don't take seriously and am willing to lose.
pntripathi9417|1 year ago
low_tech_punk|1 year ago
iLemming|1 year ago
1. Passed as arguments
2. Returned from functions
3. Stored in variables
4. Manipulated directly
5. Compared easily
Unlike some languages where data needs special handling or conversion, Clojure lets you work with data structures directly and consistently throughout your program.
This philosophy extends to how Clojure handles data transformations. For example, transducers are composable algorithmic transformations that can work on any data source - whether it's a collection, stream, or channel. They treat the data transformation itself as a first-class value that can be composed, stored, and reused independently of the input source.
This first-class treatment of both data and data transformations makes Clojure particularly powerful for data processing and manipulation tasks.
That's why Clojure often finds strong adoption in data analytics, fintech and similar domains. The ability to treat both data and transformations as first-class citizens makes it easier to build, for example: reliable financial systems where data integrity is crucial.
zdragnar|1 year ago
The two sentences around the one you quoted should answer the question as well:
And Whereas OOP languages combine behavior and data into a single thing (classes with methods model behavior and hide state i.e. data) functional languages separate them: functions model behavior, and data is treated more like an input and output rather than "state".In particular with clojure, data structures tend to be immutable and functions tend to not have side effects. This gives rise to the benefits the article talks about, though is not without its own drawbacks.
SerCe|1 year ago
[1]: https://en.wikipedia.org/wiki/Homoiconicity
pntripathi9417|1 year ago
I think having a clear example would help in understanding.
Subscribe the newsletter to know when it's live.
dalton_zk|1 year ago
Incredible history, I feel like Clojure makes magic. What I like about functional programming is that it brings other perspectives of how things CAN work!!
Congratulations by the life change
justinl33|1 year ago
pntripathi9417|1 year ago
bitwize|1 year ago
I'm unable to understand this mindset. All the time I read things like "Developers love complexity because it feeds their egos" but I've never encountered a situation in which added complexity made me more proud of the work. Just the opposite: being able to do more made me more proud of the work I put in, and complexity was the price I paid for that ability. The greatest hacks, the ones that etch people's names into history, are the ones -- like Unix and the Doom engine -- that achieve phenomenal feats with very little code and/or extreme parsimony of design. This is no more true than in that famous ego-stroking/dick-measuring contest of programming, the demoscene. My favorite example being the 4k demo Omniscent: https://www.youtube.com/watch?v=G1Q9LtnnE4w
Being able to stand up a 100-node K8s cluster to provide a basic web service, connected to a React SPA front end to provide all the functionality of a Delphi program from the 90s doesn't stroke the ego of any programmer I know of; but it might stroke their manager's ego because it gives them an opportunity to empire-build and requisition a larger budget next year.
jonathanlydall|1 year ago
Big long lived code bases are all about this battle against complexity and the speed at which you can add new or update features largely comes down to how well you’re doing at management of complexity.
pntripathi9417|1 year ago
Being able to use kubernetes for infrastructure, grafana, prometheus, etc Elasticsearch for search, Mongodb as database, redis as caching layer.
Knowing all these tech and being able to say you know these very well used to massage my developer ego...
Now I am much more like: Use one system to best of it's capability. Use Postgres. Mostly you won't need anything else.
I never resisted to urge to try out something new and shiny in production in earlier days.
Now I mostly use boring technologies and things I am comfortable with running in production.
marsavar|1 year ago
thih9|1 year ago
Not really, in an OO language state could have been stored in some data structure as well, with a way to serialize and deserialize. E.g. React made this very popular.
android521|1 year ago
Nijikokun|1 year ago
mkreis|1 year ago
joeevans1000|1 year ago
j45|1 year ago
smw|1 year ago
akashojha42|1 year ago
noshitsherlock|1 year ago
pntripathi9417|1 year ago
jokoon|1 year ago
thih9|1 year ago
It depends; exact meaning, application and personal preference play a big role.
andrewstuart|1 year ago
However my criteria for selecting a language for use in a professional context:
0: fit to task - obviously the language has to be able to do the job - to take this seriously you must define the job and what its requirements are and map those against the candidate languages
1: hiring and recruiting - there must be a mainstream sized talent pool - talent shortages are not acceptable - and I don't buy the argument that "smart people are attracted to non mainstream languages which is how we find smart people", it is simply not true that "most smart people program with Scala/Haskell/Elixir/whatever" - there's smart and smarter working on the mainstream languages.
2: size of programming community, size of knowledge base, size of open source community - don't end up with a code base stuck in an obscure corner of the Internet where few people know what is going on
3: AI - how well can AI program in this language? The size of the training set counts here - all the mainstream languages have had vast amounts of knowledge ingested and thus Claude can write decent code or at least has a shot at it. And in future this will likely get better again based on volume of training data. AI counts for a huge amount - if you are using a language that the AI knows little about then there's little productivity related benefits coming to your development team.
4: tools, IDE support, linters, compilers, build tools etc. It's a real obstacle to fire up your IDE and find that the IDE knows nothing about the language you are using, or that the language plugin was written by some guy who did it for the love and its not complete or professional or updated or something.
5: hiring and recruiting - it's the top priority and the bottom and every priority in between. If you can't find the people then you are in big trouble I have seen this play out over and over where the CTO's favorite non-mainstream language is used in a professional context and for years - maybe decades after the company suffers trying to find people. And decades after the CTO moved on to a new company and a new favorite language.
So what is a mainstream language? Arguable but personally it looks like Python, Java, JavaScript/TypeScript, C#, Golang. To a lesser extent Ruby only because Ruby developers have always been hard to find even though there is lots of community and knowledge and tools etc. Rust seems to have remained somewhat niche when its peer Golang has grown rapidly. Probably C and C++ depending on context. Maybe Kotlin? How cares what I think anyway its up to you. My main point is - in a professional context the language should be chosen to service the needs of the business. Be systematic and professional and don't bring your hobbies into it because the business needs come first.
And for home/hobbies/fun? Do whatever the heck you like.
bitwize|1 year ago
Smart people can be trained in any language and become effective in a reasonably short period of time. I remember one company I worked at, we hired a couple of fresh grads who'd only worked with Java at school based on how promising they seemed; they were contributing meaningfully to our C++ code base within months. If you work in Lisp or Haskell or Smalltalk or maybe even Ruby, chances are pretty good you've an interesting enough code base to attract and retain this kind of programmer. Smart people paired with the right language can be effective in far smaller numbers as well.
The major drawback, however, is that programmers who are this intelligent and this interested in the work itself (rather than the money or career advancement opportunities) are likely to be prickly individualists who have cultivated within themselves Larry Wall's three programmer virtues: Laziness, Impatience, and Hubris. So either you know how to support the needs of such a programmer, or you want to hire from a slightly less intelligent and insightful, though still capable, segment of the talent pool which means no, you're not going to be targeting those powerful languages off the beaten track. (But you are going to have to do a bit more chucklehead filtering.)
> if you are using a language that the AI knows little about then there's little productivity related benefits coming to your development team.
This is vacuously true because the consequent is always true. The wheels are kind of falling off "Dissociated Press on steroids" as a massive productivity booster over the long haul. I think that by the time you have an AI capable of making decisions and crystallizing intent the way a human programmer can, then you really have to consider whether to give that AI the kind of rights we currently only afford humans.
danielscrubs|1 year ago
The amount of knuckleheads that Ive had to interview just to get a single coherent developer is mind boggling (remote first).
pntripathi9417|1 year ago
Clojure is my personal favorite language, and I am planning to build very small team. So it would work for us.
j45|1 year ago
An example: When existing technology team members can run an interview and decide if someone could learn what they're working with.
oldpersonintx|1 year ago
[deleted]
linkerdoo|1 year ago
[deleted]
lincpa|1 year ago
[deleted]