freenode/lisp - IRC Chatlog
Search
21:10:51
aeth
I think Lisp code looks better than code in most languages, but if you're in it for the money, no one's going to see your code's elegance/inelegance amd you can always pay someone to clean up your technical debt later.
22:24:10
no-defun-allowed
With PG's case, he had a better chance working in Lisp since it was better for prototyping and live development. I'd argue that you have a better chance with Lisp but PG is pretty biased since he didn't fail.
22:42:29
aeth
if you're building software to last 20 years, I suspect pg's experience here is irrelevant
22:44:02
aeth
You want a language where you can make sure something is (integer 2 #.(isqrt most-positive-fixnum))
23:23:14
aeth
I'm using a 16 year old web browser, a 19 year old IRC client, a (probably) 12 year old terminal, a 38 year old compiler (if you count the original branch), a 33 year old editor, etc.
23:24:02
aeth
All the software I'm using except maybe the terminal (it's lxterminal and LXDE is moving everything to Qt) has a very good chance to make it past 20 if it's not already past 20
23:25:29
jasom
we are using different definitions of "last" then since I suspect most of that software has changes made in the past year or two.
23:26:45
aeth
jasom: My point is, if something's going to be around for decades anyway, you should optimize for the multi-decade maintenance period, not the first few years of rapid development
23:27:12
aeth
And a lot of website code is probably already at or approaching this 20 year point now in 2018.
23:27:57
aeth
Of course, a language that's mostly compatible with things written 59 years ago is a good choice to write multi-decade software in.
23:28:35
jasom
a core argument was that if you didn't optimize for being successful now, you will be starved of resources by those that do
23:35:38
aeth
jasom: on the other hand, that essay was refuted a few years later in Worse is Better is Worse by Richard P Gabriel
23:40:22
jasom
"And in preparation for this panel, the organizer, Martine Devos, asked me to write a position paper, which I did, called "Back to the Future: Is Worse (Still) Better?" In this short paper, I came out against worse is better. But a month or so later, I wrote a second one, called "Back to the Future: Worse (Still) is Better!" which was in favor of it. I still can’t decide."
1:01:36
definite
Blackbeard: I was considering installing GuixSD, but everything is difficult with free drivers. I suppose I could use the package manager alone (I've heard that suggestion before, more commonly for Nix + Haskell).
1:02:40
definite
Speaking of Guix, why is there a Scheme distro and no Common Lisp one (AFAIK, I'd be happy to be corrected) if CL is always advertised as the "full-featured systems language" of the two?
1:04:06
aeth
definite: What really makes a distro is the package manager and its software respositories... So I guess the only thing is that people haven't written a Unix package manager in CL (or at least not one that has any major adoption)
1:04:29
aeth
A modern package manager would need encryption, probably through https://github.com/sharplispers/ironclad if that's mature enough
1:04:32
definite
aeth: No, my Thinkpad has a whitelist of available WiFi cards and the one that I got to replace the old one isn't on it. I'm looking into bypassing it, but the only guide I've found which promises not to brick my computer is really old. Blackbeard: More of a question for the CL people.
1:07:19
definite
no-defun-allowed: Which Thinkpad is that? I got a T400 just to Libreboot it, but apparently you have to take apart the entire thing. I'm considering getting an X200 (only have to take off casing next to keyboard to access flashchip) and relegating this one to server duty.
7:01:59
Demosthenex
i was just reading https://stackoverflow.com/questions/1403717/how-do-i-iterate-through-a-directory-in-common-lisp where someone says cl-fad doesn't handle symlinks, but the cl-fad docs i was browsing says it can optionally follow them...
7:07:34
jackdaniel
osicat is another solution (it is also ffi based, but it doesn't libfixposix) which behaves thesame on all implementations
7:30:52
jackdaniel
ffi gives you uniform behavior, because you aim directly at your operating system interfaces
7:31:19
jackdaniel
so there are divergencies on how these chapters are interpreted by different CL vendors
7:32:36
jackdaniel
iolib uses library called libfixposix which fixes some inconsistencies between POSIX implementations (hah!)
7:33:39
Demosthenex
i'd have used the default or cl-fad, but i don't do much with files atm, still learning
7:33:56
Demosthenex
it only came up because i was discussing finding files in a dir via wildcard with Blackbeard
7:34:48
Demosthenex
cheap plug: i'm loving stumpwm. its so cool to be able to connect slime to my WM and update it live
7:36:49
Demosthenex
and being able to port over several pages of lua code for awesomewm for my window management into a single function was enlightening
7:51:06
|3b|
trying to make a large file smaller, currently saves ~50MB with normal *print-circle* on individual forms, but still lots of repeated keywords
7:53:57
heisig
Just for fun, have you tried converting the data to a single quoted literal in a file and compile it to a fasl? Then the compiler would coalesce the shared structure for you :)
7:54:09
|3b|
maybe i should just leave it as 108MB of readable source instead of 50MB of line noise :p
7:54:34
|3b|
fasl isn't really suitable for checking into git repo though, particularly if i ever want to upgrade my lisp :)
7:55:52
|3b|
ACTION could also try to combine circularity between forms, but that would probably require writing it out and reading back in, which would lose formatting
7:56:46
Shinmera
|3b|: Still not as big as the fasl qtools generates if you precompile all qt method wrappers
7:57:10
|3b|
something like 4.5k defpackage forms + same # of forms to specify how to call the methods named by the packages
7:59:18
|3b|
ggole: i'm writing a cl-like compiler targeting dalvik bytecode, and this is the FFI definitions for the android APIs
7:59:48
|3b|
Shinmera: maybe i should just generate the .fasl directly from the .jar file and check that in instead
8:01:01
|3b|
though probably a bit slower to load jar, parse it and generate package defs than to read and compile the generated lisp file
8:02:54
|3b|
compiler has exactly enough to compile calls to a superclass, or to methods of arbitrary class, passing either arguments to the method being defined or literal integers, assuming all have type declarations :p
8:04:01
|3b|
which is enough to define an onCreate method that sets the view to a hello world screen defined as a resource
8:05:56
Shinmera
what's your ultimate end-goal? The Android API is so unbearable that I don't know if even writing Lisp could fix that
8:08:29
|3b|
few small utilities, like scanning a barcode and sending to a web server, and also playing with the android AR stuff
8:12:11
|3b|
don't really /need/ the barcode thing, and the AR stuff is as much for fun as anything, so if i'm having similar fun writing compilers i might as well :)
8:12:49
|3b|
hmm, parsing the .jar file is only ~2sec if it doesn't spam debug prints, that isn't too bad
8:13:05
Shinmera
I was just having horror flashbacks to writing Ocelot, an Android client for the Lichat protocol
8:13:28
|3b|
ACTION wonders how hard it would be to build the defpackage and ffi info directly from it instead of printing it to a file
8:14:39
|3b|
not sure how hard it would be to get a monitor running on android that i could send chunks of code to for interactive dev from slime
8:16:24
|3b|
ACTION things it has an API for runtime loading from memory, but not sure how it interacts with attempts at redefinition. might need a dev mode where stuff calls stubs i can redefine or something