Live data from Hacker News

Why we built Vade Studio in Clojure

bytes.vadelabs.com

101–110 of 151 posts

Re: Why we built Vade Studio in Clojure

#101
post #98

Earlier quoted context omitted.

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

> 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 what each user needs it to be. While you find yours to be "objectively dogshit" in comparison, I can probably easily demonstrate to you how mine eats their "modern" shit without even chocking.

> LSP is ridiculously slow

Have you tried to get to the bottom of it? Sometimes it just the lsp-server implementation that is slow. Have you tried https://github.com/blahgeek/emacs-lsp-booster? Did you build Emacs --with-native-comp flag? Have you tried using plists for deserialization https://emacs-lsp.github.io/lsp-mode/page/performance/#use-p...? Have you used Emacs' built-in profiler? Sometimes the issue might be somewhere else, e.g., some fancy modeline settings.

> Things that would be trivial to do in most other languages or contexts

Sure, that's why we see so many "Emacs killers" built in Java, because replicating Org-mode is so trivial in it. /s

Re: Why we built Vade Studio in Clojure

#103
post #23

Is there a technical reason I can't sign into Studio with email? I'll really try to avoid signing in with other platforms, but I'll consider Github if there's some reason it has to be. I'll never sign into a service with Google.

Agreed. If a google account goes away, so does the access to all your google authenticated stuff. I only use google for email logins for services I don't take seriously and am willing to lose.

We wanted to get the users on the Dashboard, building apps in as fewer clicks as possible while keeping the accounts secure. Google being the most widely used auth and GitHub, the developers' favorite, they have been our first choice.

Your concern makes sense though and we'll be considering it in the next feature rollout.

Re: Why we built Vade Studio in Clojure

#104

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.

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.

Re: Why we built Vade Studio in Clojure

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

I agree. There's was one more section I planned to write about the community members. I decided to write as a separate post itself.

In the end it's about designing abstraction, and community's focus on designing simple abstractions drove me in designing the whole system.

Now once I have the working system, I am fairly sure it can be implemented in any language.

Re: Why we built Vade Studio in Clojure

#106
post #24
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…

Clojure has some interesting advantages - which doesn't mean others might not. Rapid application technologies, methedologies, or frameworks are not unusual. I know some wonderfully productive polyglot developers who by their own choice end up at Clojure. It doesn't have to be for everyone. I wouldn't rule out that Clojure doesn't deserve credit. I wouldn't think it's a good idea to discredit Clojure from not having t…

This has actually been my experience. When I started with Clojure I was writing it badly. I came from NodeJS world. It even took me a week's time just to setup the working environment.

With time you get to understand the power of simplicity. How to break the problem and compose the solutions to achieve your intended result..

That's where the power of Clojure came in for us.

Re: Why we built Vade Studio in Clojure

#107

Because Clojure treats data as first-class citizens, we could build our own lightweight conflict resolution system using pure functions that operate on these transactions. What does it mean to say Clojure "treat data a first-class citizen"? I understand FP would treat function as first-class citizen, but the statement seems to mean something different.

I am planning on writing how we have built the real time collaboration engine with conflict resolution.

I think having a clear example would help in understanding.

Subscribe the newsletter to know when it's live.

Re: Why we built Vade Studio in Clojure

#108

Because Clojure treats data as first-class citizens, we could build our own lightweight conflict resolution system using pure functions that operate on these transactions. What does it mean to say Clojure "treat data a first-class citizen"? I understand FP would treat function as first-class citizen, but the statement seems to mean something different.

In Clojure, treating data as a first-class citizen means that data structures (like maps, vectors, sets) can be: 1. Passed as arguments 2. Returned from functions 3. Stored in variables 4. Manipulated directly 5. Compared easily Unlike some languages where data needs special handling or conversion, Clojure lets you work with data structures directly and consistently throughout your program. This philosophy extends to…

This is a great explanation for "data as first class citizen"

Re: Why we built Vade Studio in Clojure

#109
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 other environment.

Re: Why we built Vade Studio in Clojure

#110

Is there a technical reason I can't sign into Studio with email? I'll really try to avoid signing in with other platforms, but I'll consider Github if there's some reason it has to be. I'll never sign into a service with Google.

No specific reason. Will be rolling it out soon.
Post reply on HN