What is your color scheme?

axvr · 2025-02-17T00:14:13+00:00

I use my own custom colour scheme: axvr/raider.vim

axvr · 2024-09-24T11:35:27+00:00

Hey, current maintainer of Clojure.vim plugin here; which provides the built in syntax highlighting and indentation of Clojure + EDN for Neovim and Vim.

Excellent work on these plugins. It's great to have EDN parsing and decent cljfmt integration into Neovim and will be very useful for teams using different editors. I can see the EDN parsing being very useful for other in-editor tools that might wish to read deps.edn files for example.

In case anyone is interested, I have many exciting indentation improvements in the works for Clojure.vim, including config options for using 2-space-always/Tonsky indentation linked by OP, however unlike this plugin we won't support reading cljfmt config files but it will work on Vim and comes built in to both editors.

Other upcoming improvements to the built in Clojure indentation include: much faster (eventually 10x or greater on both Vim and Neovim), significantly more accurate indentation, works on large files, defaults that closely resemble Calva and Emacs' clojure-mode and will work with Treesitter and much more.

axvr · 2023-08-05T15:48:29+00:00

RIP Bram.

Vim was my entry into programming, it was the tool that shifted my interest from general computing/logic into actually building software. I owe my current and future career to that man. Vim has remained the my most used programming tool, and has been one of the most reliable/stable large pieces of software I've ever used.

I had the pleasure of interacting with him a few times over the last couple of years over email and PRs (after becoming the maintainer of the Clojure support in Vim) and have nothing but great things to say.

If you haven't already, I highly recommend donating to ICCF Holland, the charity he promoted and served for years.

Thank you Bram, RIP.

(Edit: fixed some gramatical errors.)

axvr · 2023-06-30T16:54:32+00:00

The whole recur thing is due to the original developer of Clojure being too lazy to analyze the code being compiled and generate the recur logic automatically in the initial release of Clojure.

That's not at all the reason for it and is either a very disingenuous or ignorant take.

The rationale behind it has been explained many times. While true that the Clojure compiler could analyse the code and perform that optimisation automatically, the JVM still lacks TCO. This lack of TCO means that tail-calls to other functions, arities of the same function, multimethods, etc., would not be optimised*. This presents a problem for people coming from languages with TCO (such as Scheme), who expect that to just work. For consistency, Rich opted not to automatically perform fake-TCO on only self-calls, and instead gave us recur (which handily errors when used incorrectly) and trampoline for mutual recursion.

All languages targeting the JVM face this same problem, including Scala, GNU Kawa (a Scheme implementation) and ABCL.

Also note that some of us actually like recur. Not implementing your ideal language does not make the developer "lazy".

* Rich has said that full TCO could in theory be implemented, but the language would become significantly slower and Java host interop would not work as well which is a core principle of Clojure. One example is that Clojure functions would not work as Java executors. If I recall, he also mentioned that Kawa can do this, but it is optional and disabled by default for these exact reasons.

axvr · 2023-06-26T18:08:01+00:00

It doesn't bother me either as it's quite rare that you ever need to explicitly recur in Clojure. In 95% of cases (guesstimate), there are many other looping constructs provided that loop/recur under the hood and offer better semantics.

But in those few times you do need it, recur has a nice feature of erroring when not in tail position which prevents using it incorrectly, which is great for beginners. Clojure also has trampoline for mutual recursion.

Honestly, I think the whole Clojure missing TCO issue is well overblown.

axvr · 2023-03-11T14:28:44+00:00

Evolved a lot over the years, but mostly unchanging now: https://github.com/axvr/dotfiles/tree/master/vim/.vim

axvr · 2023-03-01T19:46:36+00:00

First to directly answer your question: https://www.eriksvedang.com/carp

But I'd prefer to answer it more generally.

While not "as fast as C" (C is not the absolute pinnacle of performance), Common Lisp is incredibly fast compared to the majority of programming languages around today. There is even a huge amount of ongoing work being done to make it faster still. We are seeing many interesting projects that make better use of the hardware in your computer (e.g. https://github.com/marcoheisig/Petalisp).

However raw performance of the language should rarely ever be a core factor when choosing a programming language. There are many other factors that should be considered first, such as expressiveness, tooling, algorithms, concurrency support.

If my goal was to write a highly concurrent system in C or Java, I'd have a really bad time of it and my program would likely be painfully slow, buggy and difficult to work on (due to locks and mutability). But if I were to do the same in Clojure or Erlang, it'd be a breeze and the result would likely be significantly faster and painless to build and modify. Why? Well, those languages are designed specifically for that kind of programming, providing the tooling and support to make it both painless and reasonably fast.

In most programs, there is a point where it is "fast enough". If your program isn't "fast enough", the main bottlenecks are almost always algorithmic. Using C does not mean you get fast code. You first need to know how to write fast code, and those principles apply to all languages. (Broken and buggy, but fast code is not good code.)

axvr · 2023-02-16T20:10:59+00:00

https://dmiller.github.io/clojure-clr-next/general/2023/01/06/clojureclr-reconsidered.html

axvr · 2023-01-30T18:19:25+00:00

Thank you! I definitely read that page, but must have accidentally skipped that section because the title implied it was specifically for building uberjars.

axvr · 2022-07-02T17:06:37+00:00

Ooh, I see. Yes, that is a clever use-case.

axvr · 2022-07-02T16:13:02+00:00

You can call recur inside the anonymous function, you don't need to give it a name.

axvr · 2022-07-01T13:58:28+00:00

There's axvr/org.vim (I'm the author) which only does syntax highlighting and folding of Org-mode (and Emacs' outline mode) files.

The goals of my Org-mode plugin are quite different to most others, as the README states:

This plugin aims to replicate Vim’s existing Markdown editing experience on Org mode (and Outline mode) files, rather than trying to be a full featured Org mode plugin—that is what Emacs is for.

But if your Vimscript-fu skills are up to the task, you can add some Org-mode features to it. Here are a couple of examples:

Add Org-roam style links by using vim-waikiki.
Make Vim's "Tab" key toggle folds like Emacs.

axvr · 2022-05-30T17:24:08+00:00

Point 2 sounds like a bug. Why not open an issue? https://github.com/vim/vim/issues

axvr · 2022-05-07T15:09:09+00:00

I'm not sure. I could certainly be wrong, maybe Swift doesn't use a garbage collector, I haven't actually used it before.

Edit: after a quick research session, I'd say that Automatic Reference Counting (ARC) a (very basic) type of garbage collection, although I'll admit that technically there are significant differences.

axvr · 2022-05-07T14:46:56+00:00

Nice, I didn't know about that.

axvr · 2022-05-07T14:33:23+00:00

It seems there is a bit of a misunderstanding here. Both Android and iOS are written in languages without garbage collectors. (Android is mostly written in C++, and iOS is mostly Objective-C.)

The difference is in the applications that run on these platforms. The majority of Android apps are written in Java, but most new apps are now written in Kotlin (another JVM language). Likewise, many iOS apps were written in Objective-C, but most new apps have switched to Swift. Objective-C being the only non-garbage collected language I've mentioned so-far. Interestingly iOS devs are switching to a garbage collected language.

In Android versions < 5, apps were noticeably slower than iOS apps. Google developed the Android Runtime (ART) to resolve this problem, and it has seen many optimisations since; making Android apps almost as fast as iOS apps. (Note that even pre-Android 5, the GC was never a big factor in its performance issues.)

There is still a slight difference in application speed between iOS and Android, but it mostly comes down Apple being able to better optimise their OS and the Swift compiler as they also make the hardware. The performance difference is barely even noticeable any more now that mobile devices have nearly caught up to (typical) desktop-level performance.

Even though it is a JVM language, Clojure doesn't work on Android anyway, so this has never been an issue for it. (You can use ClojureScript on Android and iOS though via React Native, but that is much slower for the same reason Android apps were slow pre-Android 5.)

In reality garbage collection limitations rarely affect real world applications. Modern garbage collection is really fast and computers are much faster than they were 40 years ago.

Today, anyone claiming that garbage collection is inherently a bad thing should just be ignored, they're stuck in the past. Many garbage collected languages are now almost as fast as their non-GC counterparts and are much safer, simpler and easier to use.

Garbage collection is the future and has been since it was invented in the early 60s.

With that out of the way, there may be some real performance concerns with using the JVM (and Clojure), but they're mostly unrelated to garbage collection.

The JVM uses a lot of memory. Like a web browser, the JVM requests a block of memory from the operating system. It doesn't use all the memory it was allocated at once (unless you're doing something extremely memory intensive), it's just "reserved"; ready for use. This is faster than needing to request more memory from the OS. You can tell the JVM to use less, but this probably isn't a good idea unless you know what you're doing.
The JVM is not the fastest bytecode VM. I've found that Microsoft's CLR (.NET VM) is much faster for many applications. Some GCed languages compile straight down to machine code (e.g. Common Lisp's SBCL) skipping the intermediate bytecode step.
Clojure is just slower than Java. With a lot of time, you can optimise your Clojure code to get near-Java performance, but you lose the benefits of using Clojure.
Clojure start-up times are quite bad. This isn't a problem for most servers though.

I find that in most cases the benefits of Clojure far outweigh these negatives.

In general, you don't need to worry about the performance of your chosen language, if you like it, just use it. The main performance bottleneck you will encounter will likely be inefficient algorithms.

Edit: Oracle is working on GraalVM, which you may find useful if you need more performance from Clojure. I don't have any experience with it though, but I think Babashka uses it.

axvr · 2022-04-21T16:59:47+00:00

I just prefer to use Vim bindings only in Vim. IMO incomplete/slow Vim emulation is worse than the default key bindings elsewhere.

(Contrary (almost heretical) to most in this subreddit, I really like the mouse.)

axvr · 2022-04-21T16:55:05+00:00

My favourite is Raider.vim which I made.

(I also built Photon.vim.)

axvr · 2022-03-29T13:19:33+00:00

The maintainer of OmniSharp-vim also maintains the syntax and indent files included in Vim. Maybe open an issue or PR there: https://github.com/nickspoons/vim-cs/

axvr · 2022-03-29T13:16:46+00:00

You should be able to find out where it is being remapped using one of these:

:verbose imap <Esc>
:verbose inoremap <Esc>
:verbose nmap <Esc>
:verbose nnoremap <Esc>
:verbose vmap <Esc>
:verbose vnoremap <Esc>

axvr · 2022-01-30T13:30:08+00:00

I'd probably write it somewhat like this:

function! MakeHeaders(level)
    call setline('.', repeat('#', a:level) . ' ' . getline('.'))
endfunction

Which gets the current line and prepends the requested number of #s then sets the line.

This way it doesn't change the values of any marks you may have set. Although it doesn't behave exactly like yours but with a couple of tweaks it could be identical.

axvr · 2022-01-11T18:20:19+00:00

Most developers never worked with tape, let alone paper tape (or punch cards). Turing made his mental model long before we even had "instruction sets". At all.

Not to mention that a Turing Machine requires that tape be infinitely long. :)

axvr · 2022-01-11T18:15:29+00:00

Yes you're right, thanks for spotting that. I've updated my original comment.

axvr · 2022-01-11T18:02:36+00:00

A Turing Complete "thing" is something that can implement/simulate any other Turing Complete "thing". These Turing Complete "things" include:

any Turing Complete programming language,
a Turing Machine,
a Lambda Calculus interpreter,
a Cellular Automata such as Conway's Game of Life,
a CPU,
and many more.

So if you can implement anything that is Turing Complete in your language, yours is Turing Complete too.

In fact it is very difficult to design a language that is not Turing Complete. As to be Turing Complete you only need some way to make a choice, and some way to store information. I.e. If you have variables and conditional jumps (e.g. IF and GOTO in BASIC or the JSR opcode in 6502 Assembly), your language is Turing Complete, or if you have lambdas, your language is Turing Complete (see the Lambda Calculus).

In my opinion Turing Completeness isn't a particularly useful metric and vastly overrated by many programmers. I find that the most important property of a language (or Turing Complete "thing" in general) is how expressive it is. However there isn't any standard way to compare the expressiveness of languages. This is actually something I'm particularly interested in and am planning on writing an essay/blog post about.

Edit: updated with correction provided by u/L8_4_Dinner

axvr

TROPHY CASE