Yes, but then you would end up with, well, Confluence.
1,604 karma · joined March 1, 2017
The author focuses on metaprogramming (something like hygienic macros that are more efficient) as the only real needed extra feature over C. He says that with this other stuff can be built at need using libraries.
The upside is that new language features are just libraries that gain or lose popularity as time goes on, allowing the core language to be more or less the same as it was at its inception while still staying alive. This advantage is shared by Common Lisp for the same reasons.
The disadvantage is that since anybody can make a new sublanguage simply by writing a library, you're left with a fight between libraries on what language features are important for the whole group, splintering the group into different sub language dialect camps. This is part of the curse of lisp. The upside might be that it's still probably pretty difficult to write meta programming in Pliant relative to lisp because of its focus on efficiency. Perhaps this will save it from most of the curse. Time will tell.
I have never yet seen a "C++ Replacement" language's more carefully argued or justified using simpler arguments than this language. That the core language will probably endure easily is very exciting to me, especially after seeing the evolution that C and C++ has gone through over the years and how hard changing the language is nowadays. In the language overview the author makes some very good points about why he chose what he chose in his design decisions.
Other replacement languages try to simply make design decisions based on taste. This is not a bad thing; some language designers have excellent taste. But it is nice to have a plain explanation as to why specific features were included in a language.
One last thought I did have was that if language features are libraries, there had better be a very good dependency manager and packaging solution for this language from day one if it is to be usable.
Storing changesets can handle very very large sets of files much more easily, but you pay the price with having to compute what file is stored whem which lengthens check out time even in the small. It is not a good trade off if you have to check out the entire thing anyways. This is why get is more popular with the open source community which is more like a bazaar than a cathedral
That was my experience when looking at Matrix and Mastodon. So I am skeptical of projects like this.
That said the UI looks very nice and the idea very promising.
It happens in my family and I'm sure everyone else's, it's why there's always drama when someone dies. Who gets Grandpa's estate, who gets Grandma's money, Grandpa loved me more but he's not here to defend himself so I can just say whatever I want about Grandpa and you just have to believe it. Using their legacy to improve our status in the family, or their money.
A great deal of heartache has come from how this has happened in my family when my grandpa passed some 20 years ago. It's all behind me now but only recently, it took a long time to settle the affairs of his prior belongings.
1. Various interactions I frequently have:
- `va(C-cC-c`. Select the current parentheses text object (s-expression) and send it to the repl.
-`C-aC-a`, switch to repl to view output, interact with debugger, etc.
- `ggVGC-cC-c`, select the entire file and send it to the repl.
- I've never done this one but since you mentioned it as useful to you: `?^(<CR>va(C-cC-c`, evaluate a top level form. Not perfect, but probably good enough especially if a line formatter is used to enforce sane indenting like this one for Clojure[6]. If a line formatter does not exist, the usual `ggVG=` built-in vim indenting works just fine.
- `:set makeprg=<command to run unit tests with line numbers>:make`. Batch error reporting and fixing, very useful[1]. In Clojure, e.g. `lein test` with some additions to set error format might be the `make` program.
vim-slime does not have an understanding of s expressions but vim itself does, using the parentheses object. See `:help text-objects`. I like that vim-slime does not have this understanding because what if I'm using it with Ruby or something. But vim support of text objects is good enough that it's never a problem. While I'm on the subject, `])` and `[(` searching for parens in vim is awesome.
Vim operates using an entirely different set of values than emacs. Selecting and searching for text should not be the purview of a plug-in, it should be built into the editor. Compiling code should be delegated to compilers. Vim does a great job of this kind of separation of concerns, it is the Zen of vim, its core philosophy. Emacs is great and it works fantastically, it just operates using a different philosophy.
2. I work more in Clojure but I'm trying to get more into common lisp. Clojure has suggestions in neovim via language server protocol[2]. The suggestions are very good[3]. This is not as developed for the common lisp story[4] but I'll try it out and see how good it is.
I've never had much patience for autocompletion. I don't even like it when the editor puts in pairs of parentheses when I've only typed the first left parentheses. Vim does have autocomplete through the language server protocol, but I don't use it.
Regarding suggestions as I type, there's ale[5], but I think I would find suggestions as I type a little too distracting and might slow me down. I find the normal LSP stuff to be good enough.
1: https://vim.fandom.com/wiki/Errorformat_and_makeprg
2: https://blog.inkdrop.app/how-to-set-up-neovim-0-5-modern-plu...
3: https://github.com/clojure-lsp/clojure-lsp
4: https://github.com/cxxxr/cl-lsp
Transcript: http://backreaction.blogspot.com/2022/08/no-sun-no-wind-now-...
On the one hand, solar panels will not fix this problem. Sun and wind both die down in the UK in the winter. You need hydrocarbons.
Honestly, if it were me, I'd ask them to turn my gas off and just heat a few rooms with electric heaters, and buy lots of blankets. It's not very convenient, but wearing a coat indoors is free. That feels more honest than stealing their gas and then not paying for it. Sure, they're probably ripping me off. Doesn't mean I should do the same.
> If someone can't understand what your product does, then it can't fail! If someone critiques your product, you can always say to yourself that "they just don't understand". Which is true! They don't!
Which you can use from the commandline inside of the multiplexor. Like I said it's fully featured because it's just you firing up Steel Bank. The debugger and inspector are still there.
> Since there is no versioning dependency management for Quicklisp to leverage, all it can do is try to build your software in isolation, not check compatibility with dependencies, and certainly not runtime compatibility.
The lack of versioning and dependency management is pretty dumb I'm not going to lie. I didn't expect that from a package manager.
> It's not that software is released too far apart, it's that the release of software is out of the hands of developers, and packaged by a third party with dependencies that may not even be API compatible with the developer's software.
Perhaps there are some cases where this is a problem, but in general, I firmly believe that having separate packagers is a good thing[1]. It can be annoying at times, but much more comfortable for the end user.
1: https://drewdevault.com/2019/12/09/Developers-shouldnt-distr...
1. Editor support. The original poster bemoans that the only fully supported editor is emacs and that there is not sufficient support for neovim. I have used emacs and slime, but I had to stop because of the ulnar tunnel syndrome it was causing. But I knew vim before I learned emacs and I am a neovimmer myself. I have used jpalardy's plugin[1] for many years and couldn't be happier with it. There's a visible repl built in, so by definition it's fully featured. The reason emacs is the only editor for lispers is that it tries to be the whole operating system. It turns out using a terminal multiplexer along with an editor gives you everything you need. I like GNU screen on Linux and ConEmu on windows.
2. Community. The original poster speaks of toxicity and a community full of people who are not welcoming to newcomers who ask simple questions. I'm just barely starting my Common Lisp journey so I can't speak to that. But I don't know if I'm discouraged by a community that values members who are capable of doing their own research and not needing their hands held. I'm often surprised by developers who need YouTube videos to explain to them how to do their job as if they can't read their own code. Maybe that's why the documentation is so poor in the Common Lisp community: the expectation is that you can read their code and figure out what it does. The original poster says that the community is full of people who do not wish to work with others. That makes me feel like if I write in this language I'll be able to be productive even if no one else wants to work with me. I'm not hugely popular and don't have a ton of stars on my GitHub pages, so the idea of a language that allows me to be productive even if no one else wants to help sounds pretty good to me.
3. Packaging. The original poster speaks against packagers who take responsibility for the cleanliness of code before it gets packaged up for the quicklisp dist. He complains that packages are released on a monthly basis and that this is not fast enough for him. As a DevOps engineer, I think this is fantastic. I hate it when developers release code too frequently because the new releases often break things even when they are not intended to, and reacting to those changes takes time. A little bit of time before each release is easier on your consumers. I feel like the best sweet spot is 90 days. I'm getting killed at work right now because of the breakneck speed of helm chart packages and how fast they release completely breaking changes. I also consider that the absolute best packaging community on this planet is Fedora and Debian operating system packages. The idea of having a separate packager from the actual software making sure that the software lands well and plays nice with its neighbors is a huge feature of those communities. Those operating systems wouldn't be possible without them. The original poster also complains that there is not any versioning. If this is the case it is very sad to me and I hope that somebody can refute this claim.
1: https://www.google.com/url?q=https://www.eia.gov/state/analy...
Peppers make it much easier to keep things clear up there. It gets to the point where I start to crave peppers.
I rarely eat a meal without some kind of hot sauce. I've been leaning more towards Sriracha until this year's shortage, then reverted to Tabasco.