Live data from Hacker News

Why we built Vade Studio in Clojure

bytes.vadelabs.com

91–100 of 151 posts

Re: Why we built Vade Studio in Clojure

#91
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…

I didn't say "type declarations can lead to a messy middle ground in Common Lisp" - obviously they exist there for a reason, but, maybe they DON'T exist in Clojure, also for good reasons, no? ABCL does exist, sure, and there's also LCL for Lua. Yet, 8 out of 10 developers today, for whatever reasons would probably use Fennel to write Lispy-code to target Lua and probably more devs would choose Clojure (not ABCL) to t…

> I didn't say "type declarations can lead to a messy middle ground in Common Lisp" - obviously they exist there for a reason, but, maybe they DON'T exist in Clojure, also for good reasons, no?

What were those reasons?

> ABCL does exist, sure,

Would that count as a hosted implementation?

Re: Why we built Vade Studio in Clojure

#92
post #89

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…

Enlightenment. I trod the same path. The solution to refactoring is tests, but having simpler code greatly improves this anyway.

Re: Why we built Vade Studio in Clojure

#93
post #76

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.

I seem to be the only one in HN and maybe the world, who worked with decent enough codebases where dynamic typing was no problem at all. 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.

It's not just that. Static types do help, yet dismissing an entire language because of a single aspect of it is extremely short-sighted. It's like rejecting Russian or Turkish, only because they have no concept of definite or indefinite articles.

Sure, Clojure is dynamically typed, but it is also strongly typed. That in practice means that for example Clojurescript when compiling to Javascript enforces those type guarantees, sometimes emitting safer code than even statically typed Typescript cannot.

Re: Why we built Vade Studio in Clojure

#94

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.

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.

Re: Why we built Vade Studio in Clojure

#95
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…

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

It's embarassing to have to even say this , but a counterexample, or even a few, does not invalidate the argument. You would need some sort of representative sample of successful projects, and then figure out which paradigm was used for each one and see if there's any statistically significant pattern. Good luck doing that reliably though.

Re: Why we built Vade Studio in Clojure

#96
post #94

Earlier quoted context omitted.

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

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.

Re: Why we built Vade Studio in Clojure

#98
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…

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

I've been using emacs for over 10 years. Maybe close to 15. I can't get rid of it, because even for all its faults, I love it. I'm hopelessly stuck with it.

However, emacs is a fucking mess, and there is a reason "init.el bankruptcy" is a thing and why the most popular way to use emacs is through various frameworks such as doom or spacemacs.

In emacs, nearly everything can(and often does) mess with everything else. It is serious integration hell to actually get things to work together, and the work that goes into e.g. doom is basically all about managing that complexity through good abstractions and more rigid ways to configure and install things.

Emacs is also objectively dogshit in a lot of ways compared to most modern editors. LSP is ridiculously slow and a constant source of performance issues, many of which are probably directly related to emacs internals. Eglot seems to do better but it's a lot more limited(you can't use multiple language servers together, for example). Then there's things like the buffer being the data-structure for everything, which is sort of like modeling nearly everything as one long string. Things that would be trivial to do in most other languages or contexts are difficult and error-prone in emacs.

Re: Why we built Vade Studio in Clojure

#99

Earlier quoted context omitted.

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

The compiler should know it for you, so you cannot get it wrong no matter what. The REPL here is a band-aid not a solution. I mean, I love Clojure, and used it for personal and work projects for 10+ years, some of which have hundreds of stars on github. But I cannot count the time wasted to spot issues where a map was actually a list of maps. Here Elixir is doing the right thing - adding gradual typing.

> 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) and Cursive (IntelliJ), even Sublime. There are tools Like Portal, immensely capable debuggers like Flowstorm, etc. You can visualize the data, slice it, dice it, group it and sort it - all interactively, with extreme ease.

I'm glad you've found great fondness for Elixir, it is, indeed a great language - hugely inspired by Clojure btw.

You still don't need to bash other tools for no good reason. It really does sound fake - not a single Clojure developer, after using it for more than a decade, would call a Lisp REPL "a band-aid and not a solution". It smells more like someone with no idea of how the tool actually works.

Re: Why we built Vade Studio in Clojure

#100
post #76

Earlier quoted context omitted.

I seem to be the only one in HN and maybe the world, who worked with decent enough codebases where dynamic typing was no problem at all. 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.

It's not just that. Static types do help, yet dismissing an entire language because of a single aspect of it is extremely short-sighted. It's like rejecting Russian or Turkish, only because they have no concept of definite or indefinite articles. Sure, Clojure is dynamically typed, but it is also strongly typed. That in practice means that for example Clojurescript when compiling to Javascript enforces those type gua…

That is exactly my feeling, like lately everything must be “safe” and statically typed. While I do see some (big, sure) pros I see also some cons that I feel are systematically ignored or neglected. For me it seems to be a kind of fade/hype… but maybe I’m just connected to the wrong news feeds.
Post reply on HN