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

141–150 of 151 posts

Re: Why we built Vade Studio in Clojure

#141

Post by j45 »

iLemming wrote: post #87
j45 wrote: post #78

Earlier quoted context omitted.

If it took fewer lines of code that's something to consider too.

Yes, Clojure can be very terse without being extremely cryptic. Even simple data representation, if you compare JSON and EDN - the latter would be almost twice as compact yet remain more readable than JSON. Clojure is not as terse as e.g., Haskell, but I think it wins by being more pragmatic. Of course, some seasoned Haskelites may disagree, in some rare cases, Haskell can prove to be fantastically pragmatic, but let…

That's a nice point, it's not about the shortest or the most verbose code.. maybe where relevant, something one or more people can learn quickly and become productive in contributing value.

With many languages and frameworks having a decent amount of similar functionality and performance available, more and more is left to personal preference and interpretation of what to use.

Popularity might matter when trying to hire juniors. Given how many juniors seem to appreciate sincere mentorship when it's mutual, I'm not super sure on this anymore.

Popularity might not matter when trying to hire other types of developers, including seniors. It's less about what's popular, or the right badge to signal.

Of the polyglot folks I get to know and are humble about their smarts, it's interesting how many independently have ended up on Clojure, or a few others. Universally there's usually a joke of how long can bash scripts do what's needed until a decision has been tied in.

Re: Why we built Vade Studio in Clojure

#142

Post by iLemming »

j45 wrote: post #141
iLemming wrote: post #87

Earlier quoted context omitted.

Yes, Clojure can be very terse without being extremely cryptic. Even simple data representation, if you compare JSON and EDN - the latter would be almost twice as compact yet remain more readable than JSON. Clojure is not as terse as e.g., Haskell, but I think it wins by being more pragmatic. Of course, some seasoned Haskelites may disagree, in some rare cases, Haskell can prove to be fantastically pragmatic, but let…

That's a nice point, it's not about the shortest or the most verbose code.. maybe where relevant, something one or more people can learn quickly and become productive in contributing value. With many languages and frameworks having a decent amount of similar functionality and performance available, more and more is left to personal preference and interpretation of what to use. Popularity might matter when trying to h…

> Of the polyglot folks I get to know and are humble about their smarts, it's interesting how many independently have ended up on Clojure

Yeah, Clojure is a weird thing. I myself, after using numerous different PLs - ranging from Basic/Pascal/Delphi to .NET languages like C#/F#, then later Python and, of course, "script" options like Javascript, Typescript, Coffeescript, and many others - still never felt like ever obtaining "the polyglot" status. I just went from one language to another, and every time it felt like burning the old clothes. I was always a "Blub programmer" at any given point of my career, every time moving from one "Blub PL" to another.

Learning Clojure somehow renewed my passion for the craft and forced me into deeper understanding of core programming ideas. Ironically, long-abandoned old friends became more familiar than ever before. I don't know exactly how that happened. Either because of the hosted nature of Clojure that forced me to always be on at least two different platforms at the same time - JVM and Javascript - or maybe because it exposed me to a lot of smarter and more experienced people than ever before. Maybe because of "Lisp-weirdness", thinking how to program with "no syntax" or being forced to think in terms of "everything is a function" where you don't even need primitives, even numbers, since you can express just about anything with functions. It could be because Clojure is of sufficiently higher level, it forced me to work on more complicated problems; I really can't say. One thing I know: I was a "Blub" programmer before Clojure. After a few years of Clojure, I have become an "experienced Blub programmer" in the sense that I no longer care in what programming language I need to write, debug, troubleshoot, or build things, with maybe a few exceptions like Haskell, Prolog and Forth - they'd probably require me to put on a student hat again to become productive, even though I know some bits of each.

Sorry, I didn't mean to make this "about me." What I'm trying to say is that I am sad that it took me years of wasted time. I wish someone had truly forced me into learning something like Clojure sooner, but again, maybe learning Haskell would have had the same or even better effect. I just want to encourage young programmers to try different languages instead of obsessing with their favorite ones. "Well," you may say, "aren't you right now fetishizing Clojure?" Here's the thing - I don't really consider Clojure any different from numerous other Lisp dialects I use - for me, all Lisps feel like the same language. The mental overhead of switching between Clojure/nbb/Elisp/Common Lisp/Fennel/etc. is so small, it's not even funny. Even jumping between Typescript and Javascript (same family) is more taxing than switching between different Lisps. Perhaps, true value of Lisps (including Clojure) is not so much technological - maybe it's rather cerebral and epistemic.

Re: Why we built Vade Studio in Clojure

#143

Post by iLemming »

pntripathi9417 wrote: post #109
e12e wrote: post #44

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

> I don't think this would be possible in any other environment.

A few years ago, I worked in a small group (6 devs) for a retail business. We had all sorts of different third-party integrations - from payment processors to coupon management and Google Vision (so people wouldn't upload child porn or some other shit through our web and mobile apps). The requirements would constantly change - our management would be like: "Hey guys, we want this new program to launch, can we do it next week?", then a day later: "Turns out we can't do it in the state of Tennessee, let's add some exceptions, okay?", then some time later: "Folks, we really want to A/B test this but only for a specific class of customers..." Jesus, and it wasn't just an "occasional state of affairs" every once in a while; it was a constant, everyday, business-as-usual flow. We had to quickly adapt, and we had to deploy continuously. We had several services, multiple apps - internal, public, web and mobile, tons of unit and E2E tests, one legacy service in Ruby, we had Terraform, containers, API Gate, load balancers, etc.

I can't speak for myself, but a couple of my peers were super knowledgeable. They used all sorts of tools and languages before. I remember my team-lead showing me some Idris features (tbh, I don't even remember anymore exactly what) and asking my opinion if we should find a way to implement something like that, and I couldn't hide my confusion as I didn't know nothing about Idris.

Numerous times, we had discussions on improving our practices, minimizing tech debt, etc. And I remember distinctly - many times we have speculated how things would've turned out if we used some other stack, something that's not Clojure. We would explore various scenarios, we even had some prototypes build in Golang, Swift and Kotlin. And every single time, we found compelling and practical reasons for why Clojure indeed was the right choice for the job.

Sure, if we had a larger team, maybe we could've done it using a different stack. But it was a startup, and we had just the six of us.

Re: Why we built Vade Studio in Clojure

#144

Post by brabel »

iLemming wrote: post #128
brabel wrote: post #127

Earlier quoted context omitted.

Do you think there's only one path to your function? There could be thousands in a big system. The type of the value you'll get will depend on the path you call it from. Even if it's only one path, you could easily have code doing stuff like this: if x > 10: call_my_function 10 else: call_my_function "foo" Can't you see that unless you test every path, you won't know what type you will receive??

Your contrived example is a bad smell in ANY language. No sensible coder ever writes a function that accepts both numbers and strings - handling multiple types should be done through proper polymorphic constructs, not arbitrary conditional branches. There's a wide spectrum of correctness guaranties in programming - dynamic weak, dynamic strong, static, dependent, runtime validation & generative testing, refinement ty…

What are you on about, I didn't say anything about panaceas or what not... just said the obvious: in a language without static typing you just can't assume the type of the argument at all.

> And, technically speaking, yes, I agree, you do need to know all paths to be 100% certain about types.

Yes, thank you.

Re: Why we built Vade Studio in Clojure

#145

Post by pjmlp »

iLemming wrote: post #136
pjmlp wrote: post #132

Earlier quoted context omitted.

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.

Clojure is not only on JVM. I often use babashka for shell-scripting and nbb for tinkering on node.js. There's ClojureDart if you like Flutter. For Lua, there's Fennel which is not Clojure but has similar syntax and inspiration. There's Clojerl for Erlang, and glojure, joker and let-go for Golang. There's clj-python and clojure-rs. There's jank-lang (which is not production-ready yet, but already is very promising).

While I welcome the clarification, I ended my comment with "...the community being welcoming of the host environments where Clojure is a guest."

Re: Why we built Vade Studio in Clojure

#146

Post by uxcolumbo »

iLemming wrote: post #136
pjmlp wrote: post #132

Earlier quoted context omitted.

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.

Clojure is not only on JVM. I often use babashka for shell-scripting and nbb for tinkering on node.js. There's ClojureDart if you like Flutter. For Lua, there's Fennel which is not Clojure but has similar syntax and inspiration. There's Clojerl for Erlang, and glojure, joker and let-go for Golang. There's clj-python and clojure-rs. There's jank-lang (which is not production-ready yet, but already is very promising).

let-go doesn't seem to be maintained anymore. The page mentions it's not ready for prime time.

Re: Why we built Vade Studio in Clojure

#147

Post by bitwize »

pntripathi9417 wrote: post #112
bitwize wrote: post #47

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

It's been my personal experience. 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…

Well you were an unusual sort of developer.

Collecting knowledge of various technologies-of-the-now isn't really a point of pride in the field, unless you're aggressively doing résumé driven development, which is a short term win, long term lose strategy.

But yeah, I'm glad you've come to see that. And yes, just use Postgres. As I like to put it, unless you have a really good reason not to use an RDBMS, use an RDBMS. But we're living in an era where bootcamp grads come out knowing only JavaScript, and MongoDB lets you make queries that resemble JavaScript, so it becomes that thing of "real professionals choose technologies for which there is a large talent pool".

Re: Why we built Vade Studio in Clojure

#148

Post by pntripathi9417 »

justinl33 wrote: post #27

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.

Absolutely... That has been an epiphany for me as well.

Re: Why we built Vade Studio in Clojure

#149

Post by pntripathi9417 »

iLemming wrote: post #133
pntripathi9417 wrote: post #113

Earlier quoted context omitted.

Absolutely... whenever consulting I usually tell companies to take these into consideration. Finding people is very hard in these languages. Clojure is my personal favorite language, and I am planning to build very small team. So it would work for us.

> Finding people is very hard in these languages. Small correction: finding experienced people is difficult. There's no shortage of engineers who only briefly tried Clojure and would love to use it at their full-time gig.

That's true...

Re: Why we built Vade Studio in Clojure

#150

Post by akkad33 »

iLemming wrote: post #135
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.

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

But statically typed languages like ocaml, haskll, fsharp have repls too
Post reply on HN