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

121–130 of 151 posts

Re: Why we built Vade Studio in Clojure

#121

Post by lispm »

draven wrote: post #114
lispm wrote: post #75

Earlier quoted context omitted.

> not to include type declarations because they can lead to a messy middle ground? What? Type declarations in CL (which came from prior Lisp dialects) were added, so that optimizing Lisp compilers can use those to create fast machine code on typical CPUs (various CISC and RISC processors). Several optimizing compilers have been written, taking advantage of that feature. The compiler of SBCL would be an example. SBCL…

> ABCL does not exist? I've only played with Clojure (not used it professionally, I'm working with Scala) but Clojure interop with Java is way better than what I can see here: https://abcl.org/doc/abcl-user.html The way it's integrated with the host platform makes it better for most use cases IMHO.

> The way it's integrated with the host platform makes it better for most use cases IMHO.

That may be. ABCL is running on the host system and can reuse it, but it aims to be a full implementation of Common Lisp, not a blend of a subset of Lisp plus the host runtime. For example one would expect the full Common Lisp numerics.

One of its purposes is to be able to run portable Common Lisp code on the JVM. Like Maxima or like bootstrapping the SBCL system.

There is a bit more about the interop in the repository and in the manual:

https://abcl.org/releases/1.9.2/abcl-1.9.2.pdf

Re: Why we built Vade Studio in Clojure

#122

Post by baobun »

bsder wrote: post #39
baobun wrote: post #31

Earlier quoted context omitted.

...in what sense has Clojure actually won over Scala? I see way more Scala in companies last ~5y and have the impression of its ecosystem being more robust. Not uncommon for greenfields. It's longer than that I even encountered an active Clojure codebase. This is from a data-engineer perspective. Clojure may be more popular for some niche of app startups perhaps? We are in different "bubbles" I suppose. EDIT: Data di…

I can't really speak to modern stuff, and it is certainly possible my memory is faulty. Scala was a PITA in the early 2000s and you were generally better served with something else if you could move off the JVM. Clojure came in about mid 2000s and seemed to be what a bunch of people stuck on the JVM but doing data processing were desperate to find. My feeling was that a lot of Clojure folks moved on as the data proce…

And yet it sees success in an actively developed project (OP).

I think both are challenging your notion of closing opportunity windows for programming languages (:

Re: Why we built Vade Studio in Clojure

#123

Post by stefcoetzee »

askonomm wrote: post #119
pntripathi9417 wrote: post #104

Earlier quoted context omitted.

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.

Having worked with large Clojure codebases I found the Malli/Spec duct-taping of types to be a poor man's statically typed language, especially with the developer experience being quite poor. While it will runtime validate, I still have no idea what shape anything is by just hovering it - having to constantly navigate between the definitions file, and they are also more cumbersome to use and maintain. I've come to th…

Some contributions to this discussion here: https://youtu.be/vUe3slLHk20?si=57O9CdyPakxrD4Rx&t=1469

Re: Why we built Vade Studio in Clojure

#124

Post by ilrwbwrkhv »

askonomm wrote: post #120
ilrwbwrkhv wrote: post #40

Earlier quoted context omitted.

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

Yes, you would know what it is at that moment. You would not however know if what it is at that moment in time is actually correct, or what the expected shape is, without deconstructing the entire function that is the receiver of the data. That's where static types are useful - I can just hover my mouse over a function and it will show me what is the expected input, and expected output, and I do not need to read and…

Theoretically, yes. And trust me, I loved static types. I use Rust for almost everything. However, the programming loop or the iteration loop that you get into with Lisp, especially with things like Common Lisp, it's not that much of a concern. But I agree with any other language which is not a Lisp, a static type system is far superior.

Re: Why we built Vade Studio in Clojure

#125

Post by ilrwbwrkhv »

hombre_fatal wrote: post #66
ilrwbwrkhv wrote: post #40

Earlier quoted context omitted.

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.

yeah as I also commented on the sibling comment the real thing here is that the way you program a clojure application or a common Lisp application especially because I used to use Steelbank common Lisp so I can talk about that is you immediately go into the REPL and you jack in it's actually a little bit difficult in clojure to do that compared to common lisp.

But the mental model is fundamentally different. It's not like you write a bunch of code, set a breakpoint and see what things are. You essentially boot up a lisp image and then you make changes to it. It's more like carving out a statue from a piece of rock rather than building a statue layer by layer.

Re: Why we built Vade Studio in Clojure

#126

Post by igouy »

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…

> Smalltalk and Common Lisp wasted their moment by not being cheap/free to people using micros in the 1980s.

Smalltalk and Common Lisp are not individuals.

"$99 Smalltalk Announced" 1986 InfoWorld Jun 30

https://books.google.com/books?id=Wi8EAAAAMBAJ&pg=PA11&dq=Sm...

Re: Why we built Vade Studio in Clojure

#127

Post by brabel »

iLemming wrote: post #96
brabel wrote: post #94

Earlier quoted context omitted.

For a single run of your code. That's absolutely no guarantee that m will always have the type, no matter how you got to the call.

What do you mean? Clojure is strongly typed language - every value always has a definite type. It's not like Javascript. Types in Clojure are fixed and consistent during runtime, they just aren't declared in advance.

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

Re: Why we built Vade Studio in Clojure

#128

Post by iLemming »

brabel wrote: post #127
iLemming wrote: post #96

Earlier quoted context omitted.

What do you mean? Clojure is strongly typed language - every value always has a definite type. It's not like Javascript. Types in Clojure are fixed and consistent during runtime, they just aren't declared in advance.

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 types, formal verification, etc.

Sure, if your domain needs extreme level of correctness (like in aerospace or medical devices) you do need formal methods and static typing just isn't enough.

Clojure is very fine, and maybe even more than just fine for certain domains - pragmatically it's been proven to be excellent e.g., in fintech and data analysis.

> Can't you see that unless you test every path ...

Sure, thinking in types is crucial, no matter what PL you use. And, technically speaking, yes, I agree, you do need to know all paths to be 100% certain about types. But that is true even with static typing - you still need to test logical correctness of all paths. Static typing isn't some panacea - magical cure for buggy software. There's not a single paradigm, technique, design pattern, or set of ideas that guarantee excellent results. Looking at any language from a single angle of where it stands in that spectrum of correctness guaranties is simple naivety. Clojure BY DESIGN is dynamically typed, in return it gives you several other tools to help writing software.

There's an entire class of applications that requires significantly more effort and mental overhead to build using other languages. Just watch some Hyperfiddle/Electric demos and feel free to contemplate what would it take to build similar things in some other PL, statically typed or whatnot. https://www.youtube.com/watch?v=nEt06LLQaBY

Re: Why we built Vade Studio in Clojure

#129

Post by iLemming »

kimi wrote: post #118
iLemming wrote: post #99

Earlier quoted context omitted.

> But I cannot count the time wasted to spot issues where a map was actually a list of maps. Sorry, I'm having hard time believing that. I don't know when was the last time you've used the language, but today there are so many different ways to easily see and analyze the data you're dealing with in Clojure - there are tons of ways in CIDER, if you don't use Emacs - there are numerous ways of doing it in Calva (VSCode…

Maybe it's so. Or maybe you run my code in your deps. As you can see, there is at least one Clojure dev who thinks so. I found spec very useful and damn expressive (and I miss it in other languages), but again that's runtime. I know Rich says such errors are "trivial", but they waste your time (at least mine).

To each their own. Some people (not me) say that Rust's pedantic compiler feels like bureaucratized waste of time akin passing through medieval Turkish customs. For me personally, working with Clojure dialects feels extremely productive. Even writing in Fennel, which is not Clojure, but syntactically somewhat similar is much faster for me than dealing with Lua. Even when I have to write stuff in other PLs, I sometimes first build a prototype in Clojure and then rewrite it. Although it sounds like spending twice the effort, it really helps me not to waste time.

Re: Why we built Vade Studio in Clojure

#130

Post by iLemming »

IceDane wrote: post #116
iLemming wrote: post #101

Earlier quoted context omitted.

> Emacs is also objectively dogshit in a lot of ways compared to most modern editors Yet not a single modern editor can even come close to it when it comes to extensibility and customization; self-documenting; complete programmability; malleability; ability to perform virtually any computing task without leaving the editor. Modern editors excel at being user-friendly out of the box. Emacs excels at becoming exactly w…

Yes, I've wasted a considerable amount of time trying to get to the bottom of the performance problems. So have multiple other avid emacs users I know that regularly have to deal with these problems. One of them is trying to live with eglot because it feels a lot faster - now they are also trying to use a sidecar process multiplexer to support multiple language servers. This is like the emacs experience in a nutshell…

> I've wasted a considerable amount of time

Okay, I'm just trying to help. I, for one, don't experience extremely vexing problems with performance like you're describing. But of course, I'm not going to pretend that I'm unaware that Emacs needs to improve on that front, and over the years there have been numerous improvements, so it's not a completely hopeless situation.

> basic, functioning editing environment

Different priorities. For me, "basic, functioning editing environment" means stuff like indirect buffers - which not a single other modern, popular editor offers.

> Emacs is not a magic machine that can do things no other software can do.

In some cases, it literally feels exactly like that. So while not literally magical, Emacs enables workflows and capabilities that can feel transformative and, yes, almost magical to its users. The "magic" comes from its architecture and philosophy. I can easily list dozens of use cases I've adopted in my workflow that are simply impractical to even try to replicate in other editors.

One can criticize pretty much any software product. Yet Emacs still falls in the category of "successful systems that have been maintained for ages". Anyway, we're getting sidetracked. My main point in the comment wasn't about Emacs, the main point is in the last paragraph. Maybe you just didn't even get to it.

Post reply on HN