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.
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.
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.
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...
smokel ·6 days 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.
Show replies
christophilus ·6 days ago
Show replies
jitl ·6 days 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.
Show replies
jimbokun ·6 days 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.
Show replies
e12e ·6 days 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...
Show replies