freenode/lisp - IRC Chatlog
Search
20:25:32
aeth
johnjay: People procrastinated the 2->3 transition for over a decade until the deadline, early this year. Now most things are finally on Python 3, although Python probably lost a lot of language momentum
20:26:18
johnjay
you can't just fundamentally change language features decade in that break a lot of existing code and not expect resistance to that
20:27:50
aeth
"python" brings up python3, but it did so no earlier than 2019 or so. "python2" still exists because not everything has migrated.
20:29:41
Xach
Specifically, the text of the CL spec issues! Is it hidden away on the old xerox ftp site somewhere?
20:30:56
phoe
I remember that kmp assembled those on his own since these weren't a part of the formal standard
20:31:14
edgar-rft
Xach: AFAIK the code examples and the "issues" pages of CLHS are from Kent pitman private collections.
20:34:13
edgar-rft
Xach: see "Additional Disclaimers" at the bottom of -> http://clhs.lisp.se/Front/Help.htm#Legal
21:23:54
dbotton
Does anyone know of a Pascal to Lisp translator (C to lisp would also work)? something foss
21:25:24
phoe
these languages are very different and it would be hard to just translate one unto the other
21:31:58
dbotton
I saw that in Racket there was a lib for doing non-lisp DSLs, so perhaps something like that?
21:42:11
dbotton
phoe while I do not plan on using it for my code, I want to allow certain user extensions to a project (a dsl) and I want to offer a more familiar look and feel to those refusing to use a lisp like dsl
21:44:56
dbotton
not really looking to use it as a learning tool (I have already seen how wide the differences are to be useful beyond teaching someone to read a code example or two a direct translation)
23:58:29
Xach
facebook informs me that the inebriated late-night amsterdam chip-shop run that led to sharplispers was 9 years ago today
0:35:01
aeth
C compilers are (apparently; I don't speak from experience) easy to write. The hard part is optimizing. Challenge mode is supporting C++.
0:37:13
aeth
C's probably one of the easiest languages to write compilers for because people manage to write dozens of them *in C itself*. I'd hate to have to try to implement a better language in C itself. I wouldn't be surprised if you could write a non-optimizing one in CL in a few thousand lines.
0:43:21
aeth
My guess is that the hardest part would be the parser because the CL community tends to not care about parsers (at least comparatively speaking).
4:54:46
jedii
would it come down to something like postgresql SBCL postmordern hunchentoot vs postgresql+tcl+naviserver
4:56:36
jedii
Paul grahm talks of forking a lisp interpreter for each web client.......then using files on netapp and justlisp
4:56:49
no-defun-allowed
The most scalable thing would probably be to keep everything in memory, which is trivial.
4:57:14
no-defun-allowed
When that doesn't work, then you could use a SQL database or object persistence library like manardb, sure.
4:57:49
jedii
I talked to one friend one time and he simply kept clients 1-10 on box 1 and 11-20 on box 2
4:59:18
no-defun-allowed
Most Lisp web servers (well, Hunchentoot and Woo) will split up work between multiple threads.
4:59:42
no-defun-allowed
I would leave scaling between machines for later, and if you have many users or very demanding uses.
5:17:48
aeth
I don't think Paul Graham's 1999 CLISP web architecture is at all relevant for 2020 probably-SBCL-but-maybe-CCL web architecture
5:18:58
no-defun-allowed
Yeah, one does not need to fork when threads are supported by the operating system and Lisp implementation.