mclehman

I was very pro-Atom for a while. I've since packed up and moved to Vim and then on to Emacs with evil-mode.

I never had any performance complaints while I was actually using Atom, but a while back I made a mistake when generating a text file that turned out to be ~1.5GB. Luckily, it was just one mistake in the footer, so I could take care of it without regenerating the entire thing.

Without even thinking about it, I opened it up with Emacs, went to the bottom, made my changes, and got back out. About a minute later, I saw how large of a file it was and was suddenly even more impressed with Emacs than I had been.

Just for fun, I then tried to edit it with Atom. Nope.

Oh, awesome, thank you. I hadn't looked on CPAN directly yet and general searches apparently weren't coming up with relevant CPAN results. CljPerl[1] is right along the lines of the sort of project I was thinking of doing.

I didn't specify, but I'm actually thinking of target Perl 6, so this is a great sort of halfway point where clearly other people have found it a worthwhile idea but not done exactly what I was thinking. Plus, P6 slangs could make it nice and easy to interleave regular Perl 6 and Perl 5 code with whatever monstrosity I come up with. I guess I have some decisions to make. Thanks again!

1: https://metacpan.org/pod/CljPerl

I think they meant that function parameters are vectors when defining a function:

  (defn foo [arg1 arg2 & rest] ...)

As for data-structure literals, it's nice to be able to write

  [1 2 3] vs (vec '(1 2 3))

  {:key1 "val1", :key2 "val2"} vs (hash-map :key1 "val1" :key2 "val2")

Agreed, all pretty minor points, but all nice to have. Function arguments are easily distinguishable and creating maps/vectors is simplified.

I thought the same as you did when I first saw it and got a bit sad. I'm actually considering trying to implement something like Lisp Flavored Perl a la Lisp Flavoured Erlang as my senior thesis/project this year.

I'm kind of torn though, as it's my second real idea and my director already likes my first idea. While that one will probably end up being too much work, this one might be overcompensating for that (although I could just be overly optimistic about how easily I can write a new lisp).

Returning a result and modifying a data structure you've decided to use as an accumulator are two different things. Modifying the original structure is even more different.

Most of the traditionally non-functional languages don't support loops as expressions.

I think their aim was to highlight the distinction between a language and an implementation of that language and possibly argue that only a particular implementation should be referred to as compiled/interpreted.

At least personally, I make recurring payments in euros rather than US dollars and it can be a hassle to see what the actual exchange rate used will be. I also have the option to pay with Bitcoin (and even receive a small discount for it) and it's very easy to see the USD value of the payment in that case. And while I am now in the passport holding minority, that's a recent development and I was previously part of that small overlap with no passport and frequent international payments.

My parents are also moving abroad in the next few months and I'll be very surprised if we don't end up struggling to move money around at some point, even if it's only a minor issue.

My guess is going to be the sound quality.

Personally, I'm a fan of the Perl philosophy: make the easy things easy and the hard things possible.