eddof13 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
euandreh has quit [Ping timeout: 260 seconds]
euandreh has joined #commonlisp
epony has joined #commonlisp
random-nick has quit [Ping timeout: 268 seconds]
eddof13 has joined #commonlisp
euandreh has quit [Remote host closed the connection]
sabra has quit [Remote host closed the connection]
Lord_of_Life has quit [Ping timeout: 246 seconds]
Lord_of_Life has joined #commonlisp
anticomputer has quit [Remote host closed the connection]
anticomputer has joined #commonlisp
euandreh has joined #commonlisp
eddof13 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
anticomputer has quit [Remote host closed the connection]
anticomputer has joined #commonlisp
eddof13 has joined #commonlisp
Oladon has quit [Quit: Leaving.]
eddof13 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
euandreh has quit [Ping timeout: 260 seconds]
euandreh has joined #commonlisp
eddof13 has joined #commonlisp
drbluefall has joined #commonlisp
Alfr has joined #commonlisp
drbluefall has quit [Remote host closed the connection]
drbluefall has joined #commonlisp
jeosol has quit [Quit: Client closed]
lagash_ has quit [Remote host closed the connection]
lagash has joined #commonlisp
eddof13 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
eddof13 has joined #commonlisp
eddof13 has quit [Client Quit]
waleee has quit [Ping timeout: 268 seconds]
rgherdt_ has joined #commonlisp
rgherdt has quit [Read error: Connection reset by peer]
tyson2` has joined #commonlisp
tyson2` has quit [Remote host closed the connection]
tyson2 has quit [Remote host closed the connection]
azimut has quit [Remote host closed the connection]
VincentVega has quit [Ping timeout: 260 seconds]
azimut has joined #commonlisp
<drbluefall>
I don't suppose anyone has a good recommendation for a websocket client library, eh?
beach` has joined #commonlisp
beach has quit [Killed (NickServ (GHOST command used by beach`!~user@2a01:cb19:150:3400:80e8:57fc:3a53:640b))]
beach` is now known as beac
beac is now known as beach
jealousmonk has quit [Remote host closed the connection]
jeffrey has quit [Quit: Client quit]
eddof13 has joined #commonlisp
eddof13 has quit [Client Quit]
<recordgroovy>
drbluefall: which language?
<recordgroovy>
oh -- my bad, I forgot which channel I was in
<recordgroovy>
:S
<drbluefall>
lol
<drbluefall>
but yeah... it's dawning on me that I either have to A) roll my own solution, or B), contend with the headache that is `websocket-driver`.
<recordgroovy>
I had to put aside a websocket-based web app, because websocket-driver's client had a terrible issue with not properly handling clients prematurely closing
<recordgroovy>
server*
<recordgroovy>
And as a server, you'd need to be able to handle basic stuff like that, if you ever want to expose the app to the wild
tychoish has quit [Remote host closed the connection]
tychoish has joined #commonlisp
<drbluefall>
I've also seen in `websocket-driver`'s issues that it *may* not interact well with `cl-async`.
<drbluefall>
So it seems to be dawning on me more and more that I'll have to roll my own solution.
<verisimilitude>
Have fun.
<verisimilitude>
I don't understand why Websockets can have such a large length value.
<verisimilitude>
Of course, Websockets also have a mangling field, because the WWW is a joke.
<hayley>
If it's a joke, then why was I not laughing when I took a stab at implementing websockets?
<drbluefall>
because as soon as more than one computer is involved, the joke is on you.
Cymew has joined #commonlisp
* drbluefall
is slamming his head into his keyboard in frustration.
<verisimilitude>
My solution, drbluefall, would be to give up and do something else at this point.
<drbluefall>
...I probably shouldn't be trying to parse documentation at 02:00.
<drbluefall>
night, lads o7
drbluefall has quit [Quit: Closing up shop]
igemnace has joined #commonlisp
_cymew_ has joined #commonlisp
recordgroovy has quit [Ping timeout: 248 seconds]
Lycurgus has joined #commonlisp
recordgroovy has joined #commonlisp
shka has joined #commonlisp
Lycurgus has quit [Quit: Exeunt juan@acm.org]
rgherdt_ is now known as rgherdt
gxt has quit [Ping timeout: 258 seconds]
gxt has joined #commonlisp
m5zs7k has quit [Ping timeout: 252 seconds]
m5zs7k has joined #commonlisp
srji has quit [Quit: leaving]
srji has joined #commonlisp
Dynom_ has joined #commonlisp
Dynom_ is now known as Guest5122
recordgroovy has quit [Ping timeout: 268 seconds]
recordgroovy has joined #commonlisp
MajorBiscuit has joined #commonlisp
Brucio-61 has quit [Ping timeout: 268 seconds]
scymtym has quit [Ping timeout: 268 seconds]
shka has quit [Ping timeout: 252 seconds]
karlosz has quit [Quit: karlosz]
Brucio-61 has joined #commonlisp
scymtym has joined #commonlisp
makomo_ has quit [Ping timeout: 265 seconds]
<Helmholtz>
Can webapps be written via CLOG ? Or is it like electron for desktop apps?
<Helmholtz>
And if yes, can the webapp be run on android like Progressive Web Apps?
<phoe>
yes, no, yes
verisimilitude has quit [Ping timeout: 260 seconds]
<neominimum>
You can create web apps w/ CLOG, but it's better suited to electron style apps atm (where the client and server are running in the same environment) as soon as you want to have a responsive client-side interface over a high latency link, then you'll be looking at shipping JavaScript to the client for that purpose. You could consider using parenscript if you don't want to touch JS.
makomo_ has joined #commonlisp
<Helmholtz>
neominimum: so at the moment, best option is writing the API-only backend with CL and frontend with something like Vue?
azimut has quit [Ping timeout: 258 seconds]
<neominimum>
I cant give you an expert opinion as don't know heaps about modern frontend dev, but from what little I've seen about CLOG though, it is supposed to (with some work) be composable w/ frontend JS frameworks but the ecosystem isn't all there yet. And I don't have the vaguest idea as how one would achieve something like that. Sorry I can't be of more help.
<neominimum>
Helmholtz: You could load something like Vue on the client and then simply send raw JS execution requests via clog (to build the app) it has functions to do so. The next step would be to create a translation layer to wrap the functionality w/ a common lisp library so that everything looks pretty again.
pve has joined #commonlisp
<neominimum>
CLOG calls them plugins. In the future there may be plugins for any popular JS framework, if someone wants to come along and build them first of course :p
xlarsx has joined #commonlisp
random-nick has joined #commonlisp
jmdaemon has quit [Ping timeout: 268 seconds]
xlarsx has quit [Remote host closed the connection]
attila_lendvai has joined #commonlisp
xlarsx has joined #commonlisp
<Helmholtz>
thanks neominimum
doyougnu has joined #commonlisp
tyson2 has joined #commonlisp
waleee has joined #commonlisp
lisp123 has joined #commonlisp
lisp123 has quit [Remote host closed the connection]
lisp123 has joined #commonlisp
attila_lendvai has quit [Ping timeout: 268 seconds]
molson has quit [Remote host closed the connection]
attila_lendvai has joined #commonlisp
xlarsx has quit [Ping timeout: 264 seconds]
rogersm has joined #commonlisp
xlarsx has joined #commonlisp
xlarsx has quit [Ping timeout: 252 seconds]
random-nick has quit [Ping timeout: 268 seconds]
attila_lendvai has quit [Ping timeout: 250 seconds]
attila_lendvai has joined #commonlisp
lisp123 has quit [Remote host closed the connection]
gateway2000 has quit [Remote host closed the connection]
gateway2000_ has joined #commonlisp
xlarsx has joined #commonlisp
xlarsx has quit [Ping timeout: 248 seconds]
notzmv has quit [Ping timeout: 246 seconds]
dilated_dinosaur has quit [Ping timeout: 252 seconds]
gateway2000_ has quit [Quit: Leaving]
gateway2000 has joined #commonlisp
attila_lendvai has quit [Remote host closed the connection]
attila_lendvai has joined #commonlisp
doyougnu has quit [Ping timeout: 264 seconds]
son0p has quit [Ping timeout: 264 seconds]
attila_lendvai has quit [Remote host closed the connection]
attila_lendvai has joined #commonlisp
<yottabyte>
what syntax highlighting package for emacs do you all recommend? I just use the default and rainbow delimiters, but it sort of leaves something to be desired for me
<yottabyte>
for example, variable highlighting
<Shinmera>
It's not generally possible to know what is or isn't a variable.
<Shinmera>
(without compiling the code in question)
<beach>
It is possible, but not with the current tools.
<beach>
Well, I guess it would require incremental compilation, but not the usual compilation by the implementation.
dilated_dinosaur has joined #commonlisp
Brucio-61 has quit [Remote host closed the connection]
Brucio-61 has joined #commonlisp
waleee has quit [Quit: WeeChat 3.6]
<yottabyte>
I see
scymtym has quit [Remote host closed the connection]
scymtym has joined #commonlisp
waleee has joined #commonlisp
gxt has quit [Ping timeout: 258 seconds]
<beach>
But we are (slowly) working on tools to make it possible.
jeffrey has joined #commonlisp
gxt has joined #commonlisp
waleee has quit [Ping timeout: 260 seconds]
xlarsx has joined #commonlisp
eddof13 has joined #commonlisp
ec has quit [Ping timeout: 258 seconds]
attila_lendvai has quit [Ping timeout: 268 seconds]
ec has joined #commonlisp
jeffrey has quit [Quit: Client quit]
attila_lendvai has joined #commonlisp
xlarsx has quit [Remote host closed the connection]
xlarsx has joined #commonlisp
epony has quit [Read error: Connection reset by peer]
xlarsx has quit [Ping timeout: 268 seconds]
causal has quit [Quit: WeeChat 3.6]
xlarsx has joined #commonlisp
epony has joined #commonlisp
xlarsx has quit [Remote host closed the connection]
shka has joined #commonlisp
Brucio-61 has quit [Remote host closed the connection]
Brucio-61 has joined #commonlisp
eddof13 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
scymtym has quit [Remote host closed the connection]
scymtym has joined #commonlisp
xlarsx has joined #commonlisp
attila_lendvai has quit [Ping timeout: 268 seconds]
doyougnu has joined #commonlisp
xlarsx has quit [Remote host closed the connection]
xlarsx has joined #commonlisp
xlarsx has quit [Ping timeout: 260 seconds]
eddof13 has joined #commonlisp
rogersm has quit [Quit: Leaving...]
waleee has joined #commonlisp
euandreh has quit [Ping timeout: 252 seconds]
euandreh has joined #commonlisp
xlarsx has joined #commonlisp
karlosz has joined #commonlisp
<kakuhen>
In the past I used rainbow-delimiters but nowadays I just use whatever syntax highlighting is present in lisp-mode and SLY
<beach>
Yeah, it seems strange to want to highlight something that is really invisible.
<beach>
I guess if your indentation is wrong, you might need it.
<phoe>
I like the colors though
xlarsx has quit [Ping timeout: 265 seconds]
Cymew has quit [Ping timeout: 265 seconds]
son0p has joined #commonlisp
xlarsx has joined #commonlisp
<phoe>
I like being able to see the depth at which a given parenthesis lies, it gives me a bit more information than indentation alone can provide
verisimilitude has joined #commonlisp
<Josh_2>
I also use rainbow parens
tyson2 has quit [Remote host closed the connection]
<Duuqnd>
Indentation also isn't much help if the part of the expression you're looking at is on one line, the rainbow colors help there
<Josh_2>
I turned it off and I dont like it
<Josh_2>
:(
<Duuqnd>
Then again, that usually isn't a problem, but rainbow parens don't hurt
attila_lendvai has joined #commonlisp
euandreh has quit [Ping timeout: 265 seconds]
Oladon has joined #commonlisp
euandreh has joined #commonlisp
MajorBiscuit has quit [Ping timeout: 265 seconds]
attila_lendvai has quit [Ping timeout: 268 seconds]
waleee has quit [Ping timeout: 268 seconds]
_cymew_ has quit [Ping timeout: 265 seconds]
Brucio-61 has quit [Ping timeout: 246 seconds]
scymtym has quit [Ping timeout: 260 seconds]
makomo_ has quit [Ping timeout: 268 seconds]
tyson2 has joined #commonlisp
Brucio-61 has joined #commonlisp
xlarsx has quit [Remote host closed the connection]
drbluefall has joined #commonlisp
xlarsx has joined #commonlisp
puhi has quit [Quit: (;´Д`)]
xlarsx has quit [Ping timeout: 248 seconds]
xlarsx has joined #commonlisp
puhi has joined #commonlisp
doyougnu has quit [Ping timeout: 252 seconds]
drbluefall has quit [Remote host closed the connection]
drbluefall has joined #commonlisp
Oladon has quit [Quit: Leaving.]
jeffrey has joined #commonlisp
igemnace has quit [Remote host closed the connection]
scymtym has joined #commonlisp
recordgroovy has quit [Ping timeout: 252 seconds]
recordgroovy has joined #commonlisp
tyson2 has quit [Remote host closed the connection]
random-nick has joined #commonlisp
_cymew_ has joined #commonlisp
simendsjo has joined #commonlisp
recordgroovy has quit [Ping timeout: 252 seconds]
recordgroovy has joined #commonlisp
_cymew_ has quit [Ping timeout: 268 seconds]
verisimilitude has quit [Ping timeout: 246 seconds]
recordgroovy has quit [Quit: leaving]
rogersm has joined #commonlisp
azimut has joined #commonlisp
azimut has quit [Remote host closed the connection]
azimut has joined #commonlisp
waleee has joined #commonlisp
jmdaemon has joined #commonlisp
jeffrey has quit [Ping timeout: 265 seconds]
cage has joined #commonlisp
lottaquestions has joined #commonlisp
zyni-moe has joined #commonlisp
drbluefall has quit [Remote host closed the connection]
verisimilitude has joined #commonlisp
rogersm has quit [Quit: Leaving...]
cage has quit [Quit: rcirc on GNU Emacs 27.1]
Everything has joined #commonlisp
zyni-moe has quit [Quit: died]
dra has joined #commonlisp
van-taffen has joined #commonlisp
pve has quit [Quit: leaving]
Oladon has joined #commonlisp
<van-taffen>
Hi Lispers! How one can decide if a CL Implementation is good enough ?
thuna` has joined #commonlisp
<van-taffen>
... to be considered an acceptable Implementation
reb has joined #commonlisp
<jackdaniel>
if it loads mcclim with a few tweaks then it is reasonably good enough (you may substitute mcclim with some other project with large codebase)
<kagevf>
van-taffen: I believe there's a test suite ... I've heard one exists, but don't know any details
<jackdaniel>
(i.e 100 tests failing is not that bad)
reb has joined #commonlisp
<kagevf>
they should define GOOD-ENOUGH-P there ;)
<jackdaniel>
as of "acceptable", this question is somewhat harder; some implementations are very fragile to invalid programs
<jackdaniel>
I remember when I was testing various implementations (like WCL), and some of these were quite frequently giving me a segmentation fault from quite innocent things
<van-taffen>
Thanks ! I will check ansi-test. What about the other libraries that uses other components outside the standard?
<Shinmera>
theoretically if it has :ansi-cl in its *features* it should be compiant ;)
xlarsx has quit [Remote host closed the connection]
<jackdaniel>
acceptability implies usefulness, so implementing components outside of the standard also makes sense (most notably [imho] - FFI, multithreading and networking ;; in this order)
xlarsx has joined #commonlisp
<jackdaniel>
perhaps the first approximation would be being able to load asdf
<aeth>
Shinmera posted it in the 4 minutes it took for me to find it
<aeth>
my bad
<Shinmera>
find it? the url couldn't be easier to remember
<van-taffen>
Tank you so much, guys
<jackdaniel>
van-taffen: why do you ask? are you writing a new implementation?
<aeth>
Shinmera: "portability" wasn't my first guess for its name, though
xlarsx has quit [Ping timeout: 268 seconds]
van-taffen has quit [Quit: Client closed]
avocadoist has quit [Remote host closed the connection]
van-taffen has joined #commonlisp
avocadoist has joined #commonlisp
<van-taffen>
jackdaniel: yes, I started to do something but idk if I will be able to complete
<van-taffen>
*it
Guest5122 has quit [Quit: WeeChat 3.6]
<van-taffen>
But it is useful to know the measures of the quality for one implementation
<jackdaniel>
historically many implementations were evolving towards ansi standard (cltl, then cltl2, finally the ansi standard)
<jackdaniel>
what is the language you are using for implementation?
<van-taffen>
Perl
<aeth>
there are a few other things that portability.cl doesn't cover... things that aren't portability libraries, really, but are more about optional features in the standard that are actually implemented.
<Shinmera>
I mean this sincerely and without any sarcasm or indictment, but best of luck. It is a monumental undertaking.
<Shinmera>
Even without any extensions.
<aeth>
actually, hmm, I don't want every because I don't want it to fail on the first
<van-taffen>
Shimmers: thanks :)
<Shinmera>
Who's that
<van-taffen>
Shimmers:
<jackdaniel>
I see, thanks; do you have a repository I could track?
<jackdaniel>
shimmers is shimmers, the guy who works on a game in common lisp colendra
<Shinmera>
Haven't heard of it, but sounds exciting
<van-taffen>
I prefer to stay in the darkness until I have something to share with the community
<van-taffen>
:)
<jackdaniel>
sure, good luck
<aeth>
(remove-if (lambda (x) (eql x t)) (mapcar (lambda (x) (let ((type (alexandria:type= x (upgraded-array-element-type x)))) (if type t x))) '(single-float double-float (unsigned-byte 8) (signed-byte 8) (unsigned-byte 16) (signed-byte 16) (unsigned-byte 32) (signed-byte 32) (unsigned-byte 64) (signed-byte 64) fixnum)))
<aeth>
assuming 64-bit... in SBCL, it's NIL. In ECL it's (fixnum) (reasonable, but it will break some library assumptions even though imo those are written poorly)
<van-taffen>
Shinmera: sorry, hate this autocorrector lol
<aeth>
There probably are a few other "one-liner" tests you could do like the one I just wrote
xlarsx has joined #commonlisp
<van-taffen>
aeth: thanks
<aeth>
but you'd have to know which optional features are ones that are common for libraries to rely on
<aeth>
A\nd no implementation is perfect, e.g. SBCL doesn't type check :type in DEFCLASS slots (but it does in DEFSTRUCT slots) at default optimization levels. Ouch. That has to break some code.
<aeth>
Usually this won't break code, but it breaks assumptions library authors make about code. An array of (signed-byte 8)s in CLISP will be a T array, so they could hold any item without erroring.
<van-taffen>
And than you for the all the answers :)
van-taffen has quit [Quit: Client closed]
van-taffen has joined #commonlisp
simendsjo has quit [Ping timeout: 252 seconds]
<aeth>
Someone probably should write a series of tests for not just minimal standards compliance but also for things that implementations are assumed to do in actual real world code (especially e.g. having (unsigned-byte 8) arrays)
<aeth>
would be nice to e.g. consistently have type checks in DEFSTRUCT and DEFCLASS slots at default optimization levels
<aeth>
It also would be nice to make sure that DECLARE doesn't *assume* the type (and either ignores it or type checks) when (safety 0) isn't true (at (safety 0) all bets are off, even though I personally don't like how SBCL handles it).
<aeth>
It would also be nice to see which implementations actually make CHAR-CODE be the Unicode code point, e.g. (char-code #\é) => 233; (char-code #\∞) => 8734
<Bike>
declare behavior would be difficult to test, because anything goes means a false declaration could crash things
<Bike>
also because there are any infinity of types and whatnot to declare and implementations can do different things with different types
xlarsx has quit [Remote host closed the connection]
tyson2 has joined #commonlisp
van-taffen16 has joined #commonlisp
van-taffen16 has quit [Client Quit]
hashfunc has joined #commonlisp
van-taffen has quit [Ping timeout: 252 seconds]
random-nick has quit [Ping timeout: 246 seconds]
justache is now known as justHaunted
euandreh has quit [Ping timeout: 246 seconds]
euandreh has joined #commonlisp
xlarsx has joined #commonlisp
reb has quit [Remote host closed the connection]
xlarsx has quit [Ping timeout: 252 seconds]
shka has quit [Ping timeout: 268 seconds]
hashfunc has quit [Ping timeout: 264 seconds]
<verisimilitude>
It's futile, aeth. People such as I use Common Lisp because its standard is set in stone and will never change in any meaningful way.
<verisimilitude>
I quite like that Common Lisp has its pathname abstraction and no requirements to support Unicode.
<aeth>
Thank you for your input and perspective on the issue. However, I think most people are interested in what can be expected to run on (nearly) every currently-in-use FOSS implementation even if it's not in the standard. That gives you things like threads, unicode, networking, graphics, FFI (at least for the OS input/windows), IEEE floating point, etc., etc.
<aeth>
The amount of useful programs that can run on the 16-bit 1980s DOS implementations of Common Lisp as well as the current ones must be small.
<aeth>
In fact, without GUI, graphics, networking, unicode, process launching, etc., support there is literally no way to communicate to the outside world. Sure, you could write a file, but what encoding does that file use?
<verisimilitude>
I've seen at least one person reach for the FFI, because he didn't know Common Lisp already had the corresponding functionality; he didn't actually know Common Lisp.
<aeth>
Don't you remember the hell that opening random text files was before everyone settled on UTF-8? There are still some files on my machine that don't load the é and å and æ, etc., properly. And this is at least assuming that the ASCII part overlaps so it's mostly acceptable. It could be EBCDIC.
<verisimilitude>
Yes, it's quite a bother in some cases.
<verisimilitude>
A character file uses the system's encoding, of course.
<verisimilitude>
UTF-8 is a cancerous scourge.
<aeth>
verisimilitude: You don't need CFFI. You don't need the ability to spawn processes. You don't need networking. You don't need unicode and the assumption that reading and writing files will be utf8 or even use configurable encodings. You don't need graphics or GUIs (which probably requires CFFI).
<aeth>
You do however need at least one of those.
<aeth>
Or you have no way to communicate with the outside world in a reliable way.
<verisimilitude>
Isn't (UNSIGNED-BYTE 8) or UNSIGNED-BYTE in general semi-standard, akin to some of the character names?
<verisimilitude>
It's, at the least, recommended.
<aeth>
But what is the octet
<aeth>
and unsigned-byte in general doesn't work because of little-endian vs big-endian
<verisimilitude>
`` element-type---a type specifier for recognizable subtype of character; or a type specifier for a finite recognizable subtype of integer; or one of the symbols signed-byte, unsigned-byte, or :default. The default is character.''
<verisimilitude>
I dislike how I can't expect (UNSIGNED-BYTE 1) to behave how I want, by allowing me to write individual bits.
<verisimilitude>
Anyway, using (UNSIGNED-BYTE 8) is a compromise with the current state, sure.
<aeth>
Anyway, SB-UNICODE has things not available in other implementations or in portable libraries afaik. And networking is a bit of a mess, too, as it currently requires a bit of FFI (via iolib) to reliably use beyond toy programs. Other than those two things, https://portability.cl/ (or alternatives) is basically mandatory for communication to the outside world, and is sufficient for "modernizing" CL.
<verisimilitude>
I wrote SHUT-IT-DOWN, yes.
<aeth>
If you make no assumptions at all beyond the standard, all you can do is read and write (unsigned-byte 8) from/to files. That's it.
<aeth>
Except
<verisimilitude>
I designed the program which uses it to cope with failure, however.
<aeth>
The standard only guarantees character and bit arrays...
<verisimilitude>
Yes, that's another bother.
<aeth>
So while you can read and write (unsigned-byte 8), you rely on all implementations going above and beyond the standard to actually shove octets into arrays (but afaik, they all do)
<verisimilitude>
The fundamental issue here is that standard Common Lisp isn't nearly as nice as people think.
<aeth>
It's fine
<aeth>
If Common Lisp actually anticipated and solved these issues, it would have used the wrong solutions... which is why Windows, Java, and JavaScript are stuck with the inferior UTF-16, for instance.
<verisimilitude>
It's agonizing trying to get guarantees about the types of things everywhere.
<verisimilitude>
Yes, and why current languages will be stuck with the inferior UTF-8 later on.
<aeth>
I mean, you have two options: You can write perfectly portable, standard CL that relies on no non-standard behavior and no portability libraries (but you better not cheat by using ASDF, which uses UIOP... put up with having no library system)
<aeth>
(ASDF is just going to encourage you to break your portability, anyway)
<verisimilitude>
That's what I do.
<aeth>
Or you can write actual programs
<verisimilitude>
The C language programmers have a similar saying, but their language is damned in far worse ways.
<aeth>
If you put yourself in the first camp, your opinion simply doesn't matter for people trying to actually write large software in Common Lisp.
<aeth>
Because you're treating Common Lisp as an intellectual exercise in esoteric scripting, rather than as an industrial language designed for writing programs people use.
<verisimilitude>
Name one large program written in Common Lisp that isn't maintained by a business.
<verisimilitude>
Is a single person here writing a ``large'' program in Common Lisp?
<aeth>
do you want more?
<verisimilitude>
Nyxt is Common Lisp nailed to the side of Google shit.
makomo has joined #commonlisp
<aeth>
There are two kinds of programs: imperfect programs and toy programs
<verisimilitude>
I'll concede the others, I suppose. I know not what pgloader is.
<verisimilitude>
Also, isn't Maxima derived from a USG program?
<verisimilitude>
I'll never accept that nonsense.
<verisimilitude>
Perfect software can and does exist.
<aeth>
TeX?
<hayley>
SICL?
<verisimilitude>
I wasn't offering any examples.
<hayley>
As to the question about large programs in Common Lisp that aren't maintained by a business.
<verisimilitude>
It's a litmus test. Someone who denies that software can be perfect has a mental disease that may be incurable.
<aeth>
To write perfect nontrivial software, one must first become perfect.
<aeth>
To become perfect, one must become a transhumanist cyborg, which will require lots of software (and hardware) which does not yet exist. This will, at least initially, likely be imperfect software.
<aeth>
Ergo, yes, it is theoretically possible to write perfect software, but it won't start that way. Even if you just refine a very small program or library over many years, it will still be refined. This implies an imperfect starting point.
skeemer__ has quit [Remote host closed the connection]
<verisimilitude>
No, that's bullshit.
<aeth>
Unfortunately, we have finite time. At the very least, you need life extension. Extreme life extension.
<aeth>
Give me 400 years instead of 40 and I can probably take the time to write perfect software. Entirely by myself.
<verisimilitude>
Can someone write a correct bounded-integer addition function, aeth?
<aeth>
> nontrivial
<verisimilitude>
Answer.
<verisimilitude>
The answer is yes.
<aeth>
Perhaps there's a sweet spot of 1000 or so lines that is perfect and not nontrivial by some standards of nontrivial, but you're not going to write anything truly useful and unique and perfect.
<verisimilitude>
Following, correct components can be composed correctly.
<aeth>
(That you can write something useful in just 1000 lines of Common Lisp is itself amazing)
<aeth>
It quickly becomes infeasible to prove or test the complete combinations of your "perfect" functions.
<pjb>
verisimilitude: (unsigned-byte 8) is not semi standard. It's perfectly conforming. You will always get values between 0 and 255 with it.
<aeth>
Even testing + is nontrivial.
<verisimilitude>
I've written a useful, unique, and novel program in something around three thousand lines of Common Lisp, including all libraries I've written for it.
<pjb>
verisimilitude: on the other hand, it's true that writing files of (unsigned-byte 8) may pose some problems on some systems, and some hardware devices.
<verisimilitude>
I sought it out and found the answer already, pjb.
<pjb>
verisimilitude: that said, you'd be hard pressed to find a CL implementation that runs on such system or hardware.
<verisimilitude>
Testing is ideally unnecessary.
<aeth>
Three options. You can test. You can formally prove. Or you can just assume that what you write is perfect and flawless and the gods' gift to mankind.
<verisimilitude>
Personally, I'd so enjoy seeing corporal punishment for flawed software. Then it would work, and the pile of dead bodies would be smaller.
<verisimilitude>
The correct choice is to formally prove, obviously.
<aeth>
What system do you use to prove the correctness of your nontrivial Common Lisp programs?
makomo has quit [Quit: later loser]
<pjb>
verisimilitude: it's not enough. You need both formally prove, test, and remotely debug. See the RAX.
<verisimilitude>
I formally prove my software manually for now.
<aeth>
And, yeah, I agree with pjb here. Tests are very useful even if not complete because that way you can be fairly confident that your changes don't break things. Especially since proving is slow, so you probably are going to go many intermediate steps between proofs, which can be quickly unit tested.
<aeth>
But the problem is that nobody has the money/time budget for even this.
<verisimilitude>
That's where corporal punishment enters, aeth.
<aeth>
Ironically, the few companies that would have such a budget are the ones that can just lobby politicians to prevent formal proofs from ever being a thing in nontrivial, non-safety-critical software
<verisimilitude>
People would find the time if they had a finger removed over it.
<aeth>
But if you were to pass such a law, then only Apple, Google, and Microsoft would be able to write software from now on
<verisimilitude>
I can't use Google, pjb.
<verisimilitude>
Well, aeth, I've thought of that.
<verisimilitude>
The simple answer is only all software for sale in any way must be correct.
<pjb>
you can use the same keywords in other search engines.
<verisimilitude>
The New York blackout killed a man whose skin grafts peeled away in the heat, all because shitty UNIX programmers feel like wizards when they write their shit.
<pjb>
deepspace 1 rax common lisp
<verisimilitude>
Alright.
<aeth>
verisimilitude: the thing is, most of the time software isn't for sale anymore
<verisimilitude>
I wrote in any way.
<aeth>
Most games are free to play. Most consumer software is just a free app or a free website. Even commercial stuff is usually a subscription rather than just selling copies of the software.
<aeth>
If you required all sold software to be correct, this transition would be completed and final. No more sold software. Not much would change.
<verisimilitude>
What a silly and defeatist attitude.
<aeth>
duh
<verisimilitude>
Consider medical hardware.
<pjb>
verisimilitude: the rax experience is very profund, because they did make a model of the system to prove it formally. But since the restrictions necessary for a consistent system were too strict, the programmers actually circumvented them, which led to a dead-lock. The kind of bug you may very well not found with tests either. If they hadn't been able to debug it remotely with a REPL, it would have cost the mission.
<verisimilitude>
Even there, the Linux kernel of all things is considered to be acceptable, for some reason.
<verisimilitude>
Oh, it's that.
<verisimilitude>
Formal proof is either total, or leads to such things, pjb.
<pjb>
A lot of bugs in medical software are of the kind of the Mars Climate Orbiter kind, ie. unit mismatch between modules (or other bounds that fail to be tested or validated at run-time).
<verisimilitude>
I can't claim to have launched anything into space, but this hardly changes things.
<verisimilitude>
Don't be a dipshit, aeth.
<pjb>
The point is that it's too hard to provide total formal proof. You'd have to start with sand!
<verisimilitude>
Oh wow, a court of law can never totally prove anything guys, wrap it up.
<verisimilitude>
I guess all of law is totes silly then.
<aeth>
Perfection over all software is impossible even if plenty of programs and libraries could be made perfect.
<verisimilitude>
Motion is impossible.
<pjb>
But lisp provides tools to compute with units instead of raw numbers, and to perform run-time checks instead of compilation-time validation that doesn't prevent to over-irradiate a patient.
<aeth>
Because of things like the inability to completely prove things (Godel's) as well as limitations in our modeling/understanding of the world (for things related to sciences, including medical devices)
<verisimilitude>
A perfect foundation can be made, aeth.
<aeth>
Sometimes you have to settle for good enough
thuna` has quit [Remote host closed the connection]
<verisimilitude>
I never will.
<verisimilitude>
Understand just how stupid that claim is, aeth.
<aeth>
For example, differential equations do not always have closed-formed solutions and sometimes require numerical approximations. Plenty of software uses differential equations. More than you think. For instance, games and other simulations.
<pjb>
acl2 too is actually based on a subset of CL. So what you'd do is to actually make a model of the core of your code in ACL2, let the theorem provers work on it, and be happy with that.
<verisimilitude>
Understand there are languages which aren't subject to that, because they're suitably restricted.
<aeth>
For some problems, you are always going to have an error, you can just prove that it's within some acceptable bounds.
<verisimilitude>
That's a different kind of error than killing someone.
<aeth>
If you think that exact perfection is always required, then you're basically lacking in understanding of so many domains.
<verisimilitude>
Code that always returns zero is correct, within some bounds of error; have useful bounds.
<verisimilitude>
It's certain one of us doesn't understand, aeth.
<aeth>
You also have performance constraints in many domains. Potentially hard real time performance constraints. This will mean that you will have to focus on performance to maintain consistent performance. This might mean compromising perfection in order to reach performance requirements that are literally impossible to reach in a more reliable way on modern hardware.
<verisimilitude>
Make no excuses for incompetence.
<verisimilitude>
That's a malformed idea, aeth.
<verisimilitude>
Incorrect software that meets the performance requirements is worse than useless.
<verisimilitude>
If it works and meets them, then it's fine.
<verisimilitude>
By the by, how many dipshits are writing such code?
<pjb>
That depends. If it includes some robotic feedback loop, it can still archieve correct control.
<verisimilitude>
Yes, it does depend.
<verisimilitude>
Notice that I'm not slinking away into incompleteness theorems and hard real-time systems to make my point.
<pjb>
Most software is used within such a feedback loop, involving also human operators. THis explain why buggy software is still useful. It's not always buggy, and it's validated by humans.
<verisimilitude>
``One reason most software can behave so reliably is by primarily experiencing its primary domain, and one reason most software can misbehave so reliably is when those vague edges of this domain are hit.''
<aeth>
verisimilitude: Anyway, correctness/perfection is just one thing to optimize for. It has a cost and so it can't always be reached. The more complicated the software, the less likely it can be done in time and on budget. Fortunately, safety-critical software is usually bordering on trivial compared to things like games, which are incredibly complicated, but don't need to not crash.
<verisimilitude>
Unfortunately, most games basically work, unlike most needed software.
<aeth>
hah
<verisimilitude>
They have flaws, but they can be very obscure.
<aeth>
no, games are usually buggy messes because they're far more ambitious than most software
skeemer has joined #commonlisp
<aeth>
we're literally to the point where a lot of popular multiplayer games literally have kernel-rootkit-spyware-level anticheat because they don't write the netcode properly... which is definitely going too far as far as incorrectness goes.
<verisimilitude>
The Manjaro GNU/Linux on this laptop is a mess that occasionally requires a hard reset; meanwhile, a single-player game basically works without issue, for every one I've played.
<aeth>
Games are the main software I can think of that still regularly crash. This isn't the '90s or early '00s anymore. Most software doesn't literally crash on you. I did get a tab crash on Firefox the other day for the first time in a long time. It makes me wonder if my RAM is failing again because usually hardware failure is the cause for crashes.
<verisimilitude>
That's an insult to hardware manufacturers.
<verisimilitude>
Anyway, I can get water from the tap, and expect to not be poisoned; I don't get botulism from random food; my car doesn't explode when I start it. This is because these things work.
tyson2 has quit [Remote host closed the connection]
<aeth>
actually
<aeth>
food regularly gets recalled... and since nobody pays attention to recalls, it's possible that their food has a known, announced issue and they don't know it
<aeth>
Cars also regularly have issues. Toyota had a serious brake malfunction issue a while back.
<verisimilitude>
The idiots behind most software would wish they could be so trustworthy, if they'd not already told themselves that computers are totally different and actually always have to be broken shit.
<aeth>
Not every area has safe drinking water. You probably live in an area with strong laws and regulations.
<verisimilitude>
Yes, hence corporal punishment for programmers.
<aeth>
I run my water through a filter just to be safe even though in theory it's unnecessary. I also usually drink boiled drinks like coffee and tea, which adds another layer of safety.
<verisimilitude>
Now, I expected exactly this silly response, aeth. Can software claim anything close to it, however?
<aeth>
Me filtering and boiling my tap water, even though it should be drinkable anyway, is defence in depth
makomo has joined #commonlisp
<aeth>
Meanwhile, you trust that non-software is somehow more reliable than software even though the same economic incentives to cut corners exists
<aeth>
(and the world is increasingly software-driven, anyway)
<verisimilitude>
It is more reliable.
<verisimilitude>
It is obviously more reliable.
<aeth>
Locally to you? Perhaps. Globally? Probably not.
<verisimilitude>
We're not talking about fucking India and Africa.
<verisimilitude>
Clearly, I'm not smart enough to challenge the wise aeth.
<verisimilitude>
Why yes, nothing works, actually, and software is just as good as the water system, somehow.
<verisimilitude>
How silly of me.
<verisimilitude>
If I wrote shitware, I'd tell myself the same thing.
<aeth>
I'm in the United States and the water in my nearest city had a one-day issue a few weeks ago. I could have easily missed this information if my parents hadn't told me because who the heck pays attention to local news in 2022? And it's not like I'm going to follow the local infrastructure websites when it might happen once in a few decades. It didn't affect my particular area, though.
<aeth>
So I literally have had more issues with tap water in the past year than software crashes (the one tab crash that I happened to see didn't crash Firefox entirely).
<aeth>
(Weeks? Months? Who knows. Time flies.)
<verisimilitude>
``it might happen once in a few decades''
<verisimilitude>
Do I need to keep explaining how software is nowhere near this reliable?
<aeth>
or it could happen every year... nobody knows the probabilities in advance
<aeth>
thus far, more tap water issues than software issues for me
<aeth>
(this year)
<verisimilitude>
``I'm forced to wonder if all wondrous technology goes through a phase such as computing currently is, in which humans create it, and idiots build a community around needlessly abusing it.
<verisimilitude>
Did operators of early printing presses forget what that tool was for, or find it fine to print illegibly given it was good enough; I know none of these incompetent programmers would enjoy it were operators of their water infrastructure behaving so carelessly, retorting that an advanced user always boils his water.''
<verisimilitude>
It's obvious to anyone not in the know that software is shit.
<aeth>
The issue I have isn't that water is necessarily unreliable, it's that if it becomes unreliable it's far more harmful for me than some random software program crashing. And it won't be obvious, either.
<verisimilitude>
Consider the lifetimes of lost work and wasted effort.
<aeth>
I am safer than most people, though, because I have a water filter and because I mostly drink boiled water in the form of coffee and tea rather than plain water. That's three layers (the infrastructure, the tap, the boiling) rather than one.
<aeth>
This is the same sort of defence in depth that computer security relies on.
<verisimilitude>
The ``field'' of ``computer security'' is a joke.
<aeth>
The early printing press was mainly used for books like the Bible, so it would have been very religiously offensive to print things poorly. That being said, have you actually opened an old book? Even one from the 19th century, after centuries of refinement. They're not printed particularly well. The pages even stick together. The printing press probably peaked somewhere in the middle of the 20th century
<aeth>
before costs kept getting cut (and now, books are largely obsolete and inflation keeps going up so things are probably dropping in quality even more)
<aeth>
And you didn't even have a good computer typesetting system until TeX in 1978. That's several decades of computing without it.
dra_ has joined #commonlisp
<aeth>
So I must ask, do you drink tap water? Have you held old books? Have you used a modern Linux distro?
<Bike>
whatever this is, it seems kind off topic
eddof13 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
dra has quit [Ping timeout: 268 seconds]
<aeth>
just a bunch of arguments by analogy where the analogies don't even hold up... ergo only write CL programs you can formally prove. Or something.
<aeth>
yes, it's basically off-topic.
<pjb>
To write CL programs that you can formally prove, you'd have first to write down a formal specification of the CL language, and then to prove that the CL implementation you're using formally implement that formal specification.
<pjb>
Until you have done that, it's useless to try to prove anything for CL programs.
<aeth>
Beyond that, you need to automate it and you need to make it really easy. Something you can add to your CI
<aeth>
Or nobody will prove it after every change because people move faster than that.
<pjb>
More precisely, the only proofs you can make are about some mathemtiatical abstraction unrelated to your program.
<Bike>
i would like to apply my fancy abstract interpretation book to proving, eventually
<aeth>
not to mention that CL has too much UB, even though it's a lot better than something like C or C++
<Bike>
unfortunately i have not yet had time
<aeth>
so you couldn't prove from the Hyperspec, you'd have to come up with a new "well-specified Common Lisp" or something
<aeth>
but verisimilitude wants the standard to stay set in stone
<pjb>
You need a formally-specified CL.
<aeth>
Increasing the reliablity would be a nice project for someone to do, but it's not the first priority
<aeth>
making SB-UNICODE portable probably should be the first priority of someone wanting to improve the CL ecosystem
<aeth>
After that, threads and networking.
<Bike>
fleshing out my threading semantics document is also on my todo list.
<Bike>
unfortunately i have learned that even the cutting edge there, the C standard, has semantics that are fulla holes. probably have to stick with java
lottaquestions has quit [Ping timeout: 268 seconds]
xlarsx has joined #commonlisp
<aeth>
Adding support for FIXNUM arrays in ECL and (SINGLE-FLOAT DOUBLE-FLOAT (SIGNED-BYTE 8) (SIGNED-BYTE 16) (SIGNED-BYTE 32) (UNSIGNED-BYTE 64) (SIGNED-BYTE 64) FIXNUM) arrays in CLISP would be a nice project for someone to do. There's real library code that assumes these. Although maybe using FIXNUM in most cases is more of a bug than a thing that should be encouraged.
<aeth>
(I didn't check for more niche things like (COMPLEX DOUBLE-FLOAT) etc.)