Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why we built Vade Studio in Clojure

bytes.vadelabs.com

Post reply on HN
Print view View original

61–70 of 151 posts

Re: Why we built Vade Studio in Clojure

#61

Post by shrubble »

bsder wrote: post #26
smokel wrote: post #18

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 gro…

> 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 supp…

Lisps really only come into their own above a certain size/amount of resources. For early Lisp the PDP-11 with 2-4 MB RAM was considered to be nice. There were some Lisp implementations for the PCs but they suffered from the need for compatibility with older hardware.

Re: Why we built Vade Studio in Clojure

#62

Post by bcrosby95 »

skydhash wrote: post #25
smokel wrote: post #18

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 gro…

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…

"Objects are the way we think" is one of the largest design traps ever laid in software development. Because if you design your program like it, unless in certain special circumstances, it will be shit.

Re: Why we built Vade Studio in Clojure

#63

Post by jitl »

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.

Re: Why we built Vade Studio in Clojure

#64

Post by knubie »

jitl wrote: post #63

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).…

> 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.

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

Re: Why we built Vade Studio in Clojure

#65

Post by joshlemer »

Zak wrote: post #51
tmtvl wrote: post #46

Earlier quoted context omitted.

One of the myriad reasons why Common Lisp is far superior to Clojure is the ability to (declare (type Integer m))

Typed Clojure is available as a library.

But just about nobody uses it right? Probably a reason for that.

Re: Why we built Vade Studio in Clojure

#66

Post by hombre_fatal »

ilrwbwrkhv wrote: post #40
christophilus wrote: post #37

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.

You wouldn't because of the repl. You would jack in and no exactly what m is.

As nice as nrepl/cider are, doing what amounts to setting a breakpoint in the middle of a function to see what `m` looks like isn't a replacement for knowing the type without executing code. It's just something we put up with.

Re: Why we built Vade Studio in Clojure

#67

Post by mstipetic »

bcrosby95 wrote: post #62
skydhash wrote: post #25

Earlier quoted context omitted.

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…

"Objects are the way we think" is one of the largest design traps ever laid in software development. Because if you design your program like it, unless in certain special circumstances, it will be shit.

I don’t think I’m terms of objects at all, I think it terms of how the data flows. That’s why I like Elixir so much

Re: Why we built Vade Studio in Clojure

#69

Post by knubie »

joshlemer wrote: post #65
Zak wrote: post #51

Earlier quoted context omitted.

Typed Clojure is available as a library.

But just about nobody uses it right? Probably a reason for that.

I think the consensus is that it is not really mature enough for general adoption. Also, most people prefer to use one of the specification libraries that are available (spec, schema, malli). These allow you to do a sort of design-by-contract style of programming.

Re: Why we built Vade Studio in Clojure

#70

Post by koito17 »

joshlemer wrote: post #65
Zak wrote: post #51

Earlier quoted context omitted.

Typed Clojure is available as a library.

But just about nobody uses it right? Probably a reason for that.

Until recently (2023), the type inference was very weak and did not work with higher-order functions (map, filter, reduce, etc.).

As a result, Typed Clojure was practically unusable for most applications. That has changed as of last year. For instance, the type checker can now handle the following kinds of expressions.

  (let [f (comp (fn [y] y)
                (fn [x] x))]
    (f 1))
This expression was a type error before early 2023, but now it is inferred as a value of type (Val 1).

Unfortunately, many Clojure users think types are somehow a bad thing and will usually repeat something from Rich Hickey's "Maybe Not" talk.

I've worked with Clojure professionally. The codebases I've seen work around dynamic types by aggressively spec'ing functions and enabling spec instrumentation in development builds. Of course, this instrumentation had to be disabled in production because spec validation has measurable overhead.

Although Typed Clojure has made remarkable progress, the most editor tooling I recall for Typed Clojure is an extension to CIDER that hasn't been maintained for several years. (The common excuse given in the Clojure community is that some software is "complete" thus doesn't need updates, but I have regularly found bugs in "complete" Clojure libraries, so I don't have much confidence here).

Overall, if one wants static typing, then Clojure will disappoint. I still use Clojure for small, personal-use tools. Having maintained large Clojure codebases, however, I no longer think the DX (and fearless refactoring) in languages like Rust and TypeScript is worth trading off.

Post reply on HN