_______ __ _______
| | |.---.-..----.| |--..-----..----. | | |.-----..--.--.--..-----.
| || _ || __|| < | -__|| _| | || -__|| | | ||__ --|
|___|___||___._||____||__|__||_____||__| |__|____||_____||________||_____|
on Gopher (inofficial)
HTML Visit Hacker News on the Web
COMMENT PAGE FOR:
HTML Extensibility: The "100% Lisp" Fallacy
frou_dh wrote 34 min ago:
What I got from this is that the author doesn't like the term
Extensible being used for situations that don't follow good software
engineering practices. Maybe the term Hackable is less offensive and
implies dirtiness being okay.
codeflo wrote 3 hours 29 min ago:
The author mentions in the article text (and re-emphasizes in a
footnote) that you will want to use platform-specific APIs for improved
accessibility even when this limits extensibility:
> you will want to support font fallback, input methods and screen
readers, all of which require interacting with platform specific APIs
and are thus much less customizable
May I ask the heretical question why of these two situations:
(a) you have one editor that makes compromises between extensibility
and accessibility
(b) you have one non-accessible editor that goes all-in on
extensibility, and one not-fully customizable editor that goes all-in
on accessibility
one would prefer (a) over (b)? Situation (a) sounds like strictly more
total effort for a worse outcome, as you have one much more complex
system that tries to navigate both purposes.
xvilka wrote 6 hours 0 min ago:
Common Lisp standard (and its implementations) really needs an uplift
to shine. There are so many shortcomings and missing features in it
that listing them here would take a lot of space. Instead, I will point
to some proposals like Common Lisp 3[1] and Compact Lisp[2]. Meanwhile
proper typing should be introduced out of the box, like in Coalton[3],
for example. Also, pattern matching should be the part of the language,
not some external library [4]. Even something basic but foundational is
not yet standardized - Unicode support! [1] [2] [3] [4]
HTML [1]: https://github.com/blakemcbride/common-lisp-3
HTML [2]: https://github.com/lassik/compact-lisp
HTML [3]: https://coalton-lang.github.io/
HTML [4]: https://lispcookbook.github.io/cl-cookbook/pattern_matching.ht...
vindarel wrote 5 min ago:
> so many shortcomings and missing features
I suggest to have a look at CIEL: [1] -> CL, with batteries out of
the box: http, json, csv, DB, functional data structures, regexp,
pattern matching, missing docstrings, missing functions, easy script
runnerâ¦
and to Epsilon: [2] > Epsilon is a Lisp programming environment built
using SBCL that provides functional data structures and some
encoding, cryptographic hashing and network programming capabilities.
HTML [1]: https://github.com/ciel-lang/CIEL/
HTML [2]: https://github.com/jbouwman/epsilon/
kscarlet wrote 5 hours 13 min ago:
I don't find any good idea in [1].
> 1. The function and variable namespaces have been collapsed into a
single namespace.
Lisp-N, package system and homoiconic macro is a local optimum (IMO
practically much better than Scheme, but I digress) for variable
capture issue in metaprogramming. Now it's saying let's bring back
the footguns and also you have to write lst instead of list. Please,
no.
> 2. ...adds a layer on top of CLOS
How about a library? Why a new standard?
> 3. Common Lisp 3 supports case-sensitive symbols.
This I can relate.
> 4. Common Lisp 3 supports native threads.
> 5. Common Lisp 3 supports tail recursion elimination.
Practically not a problem for today's CL. There's nothing to fix.
> Meanwhile proper typing should be introduced out of the box, like
in Coalton[3], for example.
Are you saying Coalton as an embedded language should be introduced
out of the box? I'm afraid it may quickly earn similar reputation as
LOOP and FORMAT. Or are you saying the whole language should adopt
Coalton-like typed semantics? Then I don't think it's even possible
for large part of the language, especially when you take
interactivity into account. What happens when a function gets
redefined with different type? Worse, how about CHANGE-CLASS and
UPDATE-INSTANCE-FOR-REDEFINED-CLASS?
> Also, pattern matching should be the part of the language, not some
external library [4].
Why not? Common Lisp as a living and extensible language now evolves
by adopting de-facto standard (trivia for pattern matching, bt for
native threads, usocket for network, ASDF for build system, etc). Why
need a committee or other form of authority to prescribe what
everyone gets to use when we have a maximally democratic process?
xvilka wrote 5 hours 7 min ago:
> Are you saying Coalton as an embedded language should be
introduced out of the box?
Not the whole language as is but proper algebraic types at least.
Just like most modern languages do.
> Why not? Common Lisp as a living and extensible language now
evolves by adopting de-facto standard (trivia for pattern matching,
bt for native threads, usocket for network, ASDF for build system,
etc). Why need a committee or other form of authority to prescribe
what everyone gets to use when we have a maximally democratic
process?
Totally a valid point but then something like Compact Lisp proposal
to strip the language to the bare minimum and extract everything
out in libraries would make way more sense than the huge and only
half-used CL standard we have now.
remexre wrote 1 hour 20 min ago:
How would algebraic types work with SLIME? If I remove a
constructor from my algebraic type, what happens to values of
that type that are built with that constructor that're stored in
globals?
In the same way that non-hygienic macros in a Lisp-2 with a
CL-style package system are a local optimum, many non-obvious
design choices in the Common Lisp type system and CLOS make SLIME
"just work" in almost every case.
kscarlet wrote 39 min ago:
I guess this case is workable similar to struct redefintion.
There can be a condition and a CONTINUE restart, which makes
instances of the removed constructor obsolete.
metroholografix wrote 4 hours 16 min ago:
If you want Scheme, go use Scheme because these are not arguments
for Common Lisp. There is tons of value in the CL specification
being this big and I'm happy I can still run code I wrote more
than 25 years ago (or third party code written more than 50 years
ago) without any issues.
Generally, contemporary folks that propose improvements to the CL
spec tend to be misinformed / misguided and/or lacking experience
to realize why their proposed improvements are bad ideas.
acuozzo wrote 7 hours 11 min ago:
Interesting that there was no mention of Symbolics Lisp machines.
vindarel wrote 8 hours 35 min ago:
Recently added in Lem: tree-sitter for JSON, YAML, Nix, Markdown, WAT;
new language modes: Clojure, Perl, Kotlin, Zig (with LSP); git-gutter
mode.
Lem has a (quite simple still) Git/hg/fossil interactive mode
(interactive rebase is there but no reword for instance) and org-mode
support is coming ( [1] ).
Lem now is ncurses + webview (+ the non-longer maintained SDL2 backend)
and it has daily multi-platform binaries. Try it out!
HTML [1]: https://github.com/mahmoodsh36/organ-mode
HTML [2]: https://lem-project.github.io/
xedrac wrote 7 hours 23 min ago:
I tried the latest nightly release AppImage on Fedora 43 and got a
nice undefined symbol error:
/usr/lib64/gio/modules/libdconfsettings.so: undefined symbol:
g_assertion_message_cmpint
Failed to load module: /usr/lib64/gio/modules/libdconfsettings.so
/usr/lib64/gvfs/libgvfscommon.so: undefined symbol:
g_task_set_static_name
Failed to load module: /usr/lib64/gio/modules/libgvfsdbus.so
So I tried out the container version with podman and that worked. I
am familiar with Emacs, so some things were natural to me. I like Lem
quite a bit. But to really drive with it, I need:
- Solid LSP support
- Project scoped buffer switching/searching
- Great vim keybinding support (this seems to have improved since
last I tried lem years ago)
- Tree-sitter support for the languages I care about.
According to the website, LSP support is still a WIP. I didn't want
to go through the hassle of testing it out in the docker container.
From what I can tell, there is no project scoping for buffers, but I
might be wrong.
All in all, a big improvement from a few years ago when I last tried
it!
vindarel wrote 13 min ago:
Hello, yes there's project scoping: [1] (added by yours truly,
which was easy thanks to Lem's quality code base). I find the vim
layer excellent, you can open an issue if you find obvious things
missing.
HTML [1]: https://lem-project.github.io/usage/usage/#project-command...
jibal wrote 8 hours 54 min ago:
> Itâs not wrong
Glad we settled that.
DIR <- back to front page