freenode/#lisp - IRC Chatlog
Search
18:48:56
skidd0
so like (let* ((maybe-id ([stuff])) (for-sure-id (if (numberp maybe-id) maybe-id nil))))
18:53:23
sjl
it's almost certainly LESS expensive to LET the stuff into a variable, rather than computing it twice.
18:54:17
shka_
skidd0: if you are considering let to be expensive you probably should not be try to optimize your programs
18:55:53
skidd0
right, because i could be wasting time optimizing something when the bottleneck is elsewhere
18:57:12
Josh_2
skidd0: just write the code how feel is right, when you are complete and have something that works how you want, then you can optimize :) computers are plenty fast
18:59:43
shka_
pretty code is easier to profile anyway, and profiling is critical part of optimization
19:01:33
skidd0
my pitch is that i'm faster and more expressive in lisp (even tho i barely know it, clearly)
19:03:08
stylewarning
They care (IME) about whether other software devs buy into it, whether they can hire people, and whether you’ll just be a bus factor nightmare
19:03:16
skidd0
like last week, i'm building up this database table and importing a ton of data from an API that's paging the records. half way through, (20 mins in) i get a warning that a record in the API didn't have a number for it's ID. So, i redefnied the way the import function handles those IDs to check for a number, live, without breaking the import
19:03:53
skidd0
and yeah, that's exactly the worry i have. They're trying really hard to push and solidify all future dev inot meteor, react, mongo
19:04:29
stylewarning
Lisp is sufficiently odd that it is taken as a bad smell by folks who aren’t deep in the trenches of development. If you’re going to use something non-standard, you have to pull a lot of political weight
19:06:04
stylewarning
(Even at a company where our most advanced software is in Lisp, there’s still pushback. There’s always this lingering desire to “quarantine” it and not let it grow.)
19:07:42
stylewarning
It seems the best way to have Lisp at a company is to be in a leadership position where you call the shots AND you really have convinced yourself Lisp will be more productive than throwing up a Flask server with MySQL.
19:08:55
stylewarning
But leadership is responsible for the maintenance and outlook of the company, and “reducing risk”
19:09:28
skidd0
but in my head, the risk of the code/lang should be measured, reported, and decided on by those that work with it
19:09:34
stylewarning
(FWIW I don’t think Lisp is a very risky choice if you’re ok with training somebody for 1-2 weeks)
19:10:58
skidd0
that they have me fixing up. so, this co. has me simultaneously learning classic ASP and that meteor stack
23:26:08
phoe
"but all of the databases we use nowadays will be passé in 10 or 20 years, we'll need to rewrite anyway to make use of the newest MassiveDB and ImmutableJS or whatever current fad is the shit"
23:40:39
verisimilitude
I'm fortunate to have written only a single line of JavaScript in my life and not for something I personally cared about.
23:41:38
verisimilitude
What I think, ebrasca, is that a language many decades old still being at least near the top of things is a sign of stagnation.
23:42:01
verisimilitude
It's not necessarily that Lisp is great, but more that most other things are just pathetic.
23:51:17
_death
verisimilitude: not bad, all things considered. I think Lisp has something intrinsic in it that draws me to it, so I don't care if everything else is at stasis
0:15:04
stylewarning
Still a ways to go, but strongly typed parametric polymorphism in otherwise bog standard Lisp code is a dream
0:27:30
makomo
does the issue appear when you have all three of those constraints: constant time, constant memory, respects the lexical environment?
0:29:57
stylewarning
I don’t think you can feasibly do the first and last because it’s O(n) time to build the memory
0:46:15
jasom
ACTION has always thought it would be fun to make a thin wrapper for algebraic data types on lisp, but it's a significant project
0:48:06
jasom
something that would actually be smart about inserting type declarations that are revealed (e.g. emit something like (let ((x (cadr y)) (declare (type foo x)) ...) when y is known to be of type (list foo))
0:49:17
aeth
Interesting. I just found out about another historic Lisp that's pretty obscure and with comparatively very little information (not even a Wikipedia article). "Cambridge Lisp" for the Amiga. This 1987 review complains about how different from CL it is. https://www.atarimagazines.com/startv1n4/cambridgelisp.html
0:53:19
jasom
googling tells me that there was a "combridge lisp" implemented in bcpl shortly after lisp/370
0:53:22
aeth
The manual for the Acorn version (if it's even the same Lisp dialect, this one is apparently published by Acorn, not Metacomco) is online. http://chrisacorns.computinghistory.org.uk/docs/Acorn/Sci/AcornScientific_CambridgeLISPRM.pdf
0:55:13
aeth
Incompatible 16-bit Lisp that wasn't used by many and probably didn't have interesting features compared to the big lispms, so I'm not surprised that it's very obscure.
0:57:36
aeth
jasom: I think you can get pattern matching in vanilla Lisp through a sufficiently advanced macro (perhaps requiring CLtL2, idk... I think you could just expand it into nested typecases)
1:00:14
jasom
aeth: optima does pattern matching, including type based matching and destructuring, but see also the lack of an algebraic type-system in lisp
1:01:12
jasom
also I think there is no portable way to get information about enclosing lexical bindings in a macro, so you can't enforce completeness of pattern matches in a meaningful way.
1:10:56
aeth
jasom: Something a lot of pattern matching languages would have, translated into Common Lisp, is afaik something along the lines of: if you define a member type, then you can ensure that every branch (i.e. every member of the member type) is handled in the cases... so if you redefine (deftype colors () `(member :red :green :blue)) to now be (member :red :green :blue :yellow) you should get compilation errors
1:11:44
aeth
jasom: But I think you can still get that in CL if you just replace directly using the DEFTYPE to define member types like that to using some custom macro.
1:12:55
jasom
aeth: right, but ML will infer the type you are matching on, and that's just not possible in CL, even if one line above your match macro you declared the type of the variable you are matching on!
1:15:21
aeth
stylewarning: I'm not sure I agree. There's MEMBER, there's OR, and there's DEFSTRUCT/DEFCLASS.
1:20:16
aeth
stylewarning: The way you'd do that is defstruct with slots with :type. I've done that for typed linked lists. Trees would be just a bit trickier. Of course, you're looking at a 30% performance loss on SBCL, and not every implementation will respect :type in defstruct slots. (defclass will be even worse here)
1:20:45
aeth
(Actually using conses and type checking there would have to walk through the whole list afaik)
1:24:59
aeth
You'd also probably want a true way to say (maybe foo) because (or null foo) won't work on symbols, lists, or booleans.
1:39:19
stylewarning
Yes what you said about “maybe” gets to the root of the problem, algebraic parametric polymorphism
2:57:24
loli
it seems this library gives pattern matching exhaustion which is neat https://github.com/stylewarning/cl-algebraic-data-type
3:08:08
verisimilitude
It's been a time since I've taken a look, but are you perhaps thinking of (VECTOR *), hellcode?
3:13:15
hellcode
mmm idk, isn't t a supertype of everything? so that (vector t) ought to include (vector char) and so on?
3:55:36
aeth
since T will be (mostly) pointers but some specialized vectors can remove pointers for e.g. ub64 or double-float
5:08:34
pjb
And then, if you really need ot know, you should refer to the documentation of sbcl and of clisp, and it probably won't be the same thing.
5:10:48
pjb
LdBeth: otherwise, you can always try (documentation 'system::*driver* 'variable) or (describe 'system::*driver*)
5:11:01
pjb
LdBeth: Third, it's not documented in clisp, so DUH! https://clisp.sourceforge.io/impnotes/idx.html