(2011) that article. That's like 13 years old. I very well remember 13 years ago the FANG were not filled with middle managers like they are today. Massive cultural shifts in these places since then.
This might sound crazy or stupid but I really want to know if there is some Lisp with manual memory management? I love Lisp syntax. People complain about the parentheses but for me they are a blessing. I like how extremely uniform and regular they look.
But all Lisps I've seen have garbage collectors. If I could find a Lisp with manual memory management, I could ditch C++ in favor of that Lisp. Is there one?
You can use a regular common lisp distribution like SBCL and just stick to foreign types https://www.sbcl.org/manual/#Foreign-Types this way you still have a GC for lighter tasks but with the option of manual memory management
You could do this in Common Lisp with global variables. They are not garbage collected. You'd have to decide how manual you want this to be. The ultimate manual setup would be something like
which is just a 1k bag of bytes. Then write some functions to allocate from it, keep track of it, etc. A typical Common Lisp implementation will make a "specialized array" when it does this - that is, the array is not filled with a bunch of pointers to individually-allocated bytes.
There are other ways you could do it - for example (I don't know if this would be efficient):
and there are ways you can write a FREE function to release these allocations or mark them for re-use.
These methods would not really release memory back to the OS. However, C malloc and free typically do not really free memory back to the OS either. You can easily do something in Common Lisp that's on equal footing with C in that regard.
Edi Weitz in "Common Lisp Recipes" points out that when you're doing something like this you're "pooling" memory, and in effect you're replacing automatic memory management with your own hand-rolled memory manager, and chances are it's not going to be as good as an automatic memory manager. But certainly it's doable.
I bet you could go quite far writing a straightforward compiler using an S-expr syntax.
Any by a "compiler" I'm talking doing something simply like taking Pascal, converting it to an s-expr grammar, and going to town.
Scheme can be a simple algol style language. Using s-expr syntax just made your lexer/parser much simpler. And (simple) compilation is really not that hard (just compile it to C for your first crack if you want).
Entirely unrelated to the post? Entirely? The post talks:
"To write Common Lisp code with comfort and still have the ability to interact with REPL, you can choose your favorite IDE"
And then it goes on to provide some recommendations for major editors out there. So the GP is at least a little related to the post?
I did not get the impression of any flame war in the GP. As a Emacs user myself I am well aware that everyone does not like to use Emacs. Many like Vim. I don't see the problem with recommending a Vim setup for Lisp. We need more recommendations like that for different editors to make Lisp programming more attractive to people of all types of technical background.
> Emacs' solution to switching between buffers is harder to use if you want to go between different files you have open.
Are you sure?
If I am on foo.rs and I want to go to bar.rs all I type is C-x b bar and type Enter and done! I find this way easier than hunting and pecking for my tab in VSCode.
> but having to read eighteen chapters just to get to make my own keyboard mappings is...
That's a very disingenuous way of deflecting your lack of motivation for learning Emacs on 18 chapters of documentation. I'm sure you code in some programming language, maybe multiple of them even. I'm sure each such programming language comes with tons of documentation. Do you read the whole language manuals/books before you start doing something useful with it? Or do you just learn the basics and look up what you need as you figure it out?
The basics of Emacs are easily accessible from C-h t and that's the first thing Emacs shows in its welcome screen when you launch it the first time. It takes less time to finish that C-h t tutorial than it takes to learn the basics of a new programming language.
Nobody really reads 18 chapters of documentation before making keyboard mappings. I make keyboard mappings and I read 0 chapters of the documentation. 0. Zero. How? Just like you do anything else in software these days? Looking it up, jumping directly to the documentation I needed to learn how to do key maps.
There's nothing special about doing things in Emacs. You can learn Emacs just the way you learn any programming language. What might be different about learning Rust or Python might be that most people find themselves motivated to learn it so they are motivated enough to look up what they need. But many people are not so motivated to learn what they perceive as merely an editor. If you do not have the motivation to learn Emacs the same way, that's fine. But blaming it on the large documentation does not seem fair.
> Nobody really reads 18 chapters of documentation before making keyboard mappings. I make keyboard mappings and I read 0 chapters of the documentation. 0. Zero. How? Just like you do anything else in software these days? Looking it up, jumping directly to the documentation I needed to learn how to do key maps.
Yes, and that's the approach I used multiple times, the same approach that helped me learn Vim. The learning curve is much steeper, and Vimtutor is much easier to comprehend than the C-t h tutorial.
That's what I tried to say in the first comment, and people attacked me by saying Emacs has awesome documentation. Now you're attacking me, saying that documentation doesn't matter and nobody reads it anyway...
> that documentation doesn't matter and nobody reads it anyway
Did I say that? I don't think so. I said that it is possible to create key mappings without reading 18 chapters of documentation. How? By looking up what we need.
But Emacs users do read the documentation but not necessarily in a linear manner where they must start from Chapter 1 and go all the way to Chapter 18 before they are able to do something. Some people might it read like that. But most people including myself read the parts that matter to us.
> Did I say that? I don't think so. I said that it is possible to create key mappings without reading 18 chapters of documentation. How? By looking up what we need.
And I said that approach didn't work for me. Great that it worked for you, but
I found that looking stuff up for Vim was much easier than looking up stuff for Emacs. Which is what I basically said in the first comment and explained several times in this comment thread.
This absolutely happens to me. Happy to know I'm not the only one.
> But in a physical book, I often remember that a phrase was at the top or middle or left side of a page, or that I was sitting in a particular chair when I read it.
Exactly! And for reasons I cannot explain this helps me with better recall too! Like when I remember something I read, I know roughly where in the book that stuff was physically printed and what other stuff were around it and how they relate to each other.
With ebook too I still know how things relate to each other but the clarity feels much less. I can see it much less in my mind's eye. I don't know why! And it drives me mad!
> Guess you’ve never heard of names? Or date of birth? Personal doesn’t mean unique.
Your parent commenter is contesting the "A face is a unique identifier" part. They are not contesting "A face is personal". Of course face should be PII but at the same time it is not a unique identifier, so your parent commenter is correct and you are correct too. But you are replying to an objection that was never made.
