Anyone else unable to login with github to studio?
Looking into the problem. Apologies.
Why we built Vade Studio in Clojure
111–120 of 151 posts
Re: Why we built Vade Studio in Clojure
#112> 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 to urge to try out something new and shiny in production in earlier days.
Now I mostly use boring technologies and things I am comfortable with running in production.
Re: Why we built Vade Studio in Clojure
#113Look these folks can do whatever the heck they want, use whatever language they want. However my criteria for selecting a language for use in a professional context : 0: fit to task - obviously the language has to be able to do the job - to take this seriously you must define the job and what its requirements are and map those against the candidate languages 1: hiring and recruiting - there must be a mainstream sized…
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.
Re: Why we built Vade Studio in Clojure
#114Earlier quoted context omitted.
> myriad reasons why Common Lisp is far superior to Clojure Some narrow view. Have you tried thinking that maybe Clojure intentionally chose not to include type declarations because they can lead to a messy middle ground? After all, maybe not every feature from Common Lisp needs to be replicated in every Lisp dialect? Besides, Clojure's Spec and Malli can be far more powerful for validation as they can define complex…
> 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.
Re: Why we built Vade Studio in Clojure
#115Earlier 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.
There's the way we think about the problem and it's solution and there's the way that the machine can execute these solutions. More often there's no direct mapping other than a tower of abstractions. The issue is that the problem and our model are too fluid and it's best not to rely that much on a certain paradigm.
Re: Why we built Vade Studio in Clojure
#116Earlier quoted context omitted.
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 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.
My conclusion is basically: some language servers are slow, which doesn't help, and some are also very noisy. Both scenarios are handled extremely poorly by emacs, i.e. locked ui when parsing or waiting sometimes, stuff like that.
You really have to be a special kind of oblivious to argue so vehemently while literally suggesting I run a separate program on the side to get what most would consider to be a basic, functioning editing environment.
Re the org-mode argument: I really think you mistake lack of interest for insurmountable complexity. Emacs is not a magic machine that can do things no other software can do. You can probably count the number of people who genuinely care about org-mode in the world on 10 sets of hands.
Re: Why we built Vade Studio in Clojure
#117@OP "Model our domain as a graph of attributes and relationships" and "generate resolvers". I'm curious what your model looks like so that you are able to "generate resolvers"? I had looked into using Malli as the model, but curious what route you took.
We use malli to define domain model. And generate pathom resolvers and mutations based on those.
Re: Why we built Vade Studio in Clojure
#118Earlier quoted context omitted.
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…
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).
Re: Why we built Vade Studio in Clojure
#119Clojure 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.
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 the conclusion that it is just a better experience using a language that already has static types for large projects, than trying to make a dynamic language have similar things. Having to wrap every function in a error boundary to get somewhat of a meaningful debug experience is just .. awful.
Re: Why we built Vade Studio in Clojure
#120Clojure 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.
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 understand the contents of the function to know if the data is correct, because it would throw an exception if it is not, like if a string suddenly becomes a number or is missing a piece of information, etc.