freenode/#lisp - IRC Chatlog
Search
7:28:49
pjb
beach: you are wrong: IF and ASSERT DO NOT EXPECT a BOOLEAN! They expect a generalized boolean. POSITION returns a generalized boolean. It's perfectly compatible with IF or ASSERT.
7:29:46
pjb
Of course, you are entitled to write your programs in a subset of CL, and nobody will reproach it to you. But people can use the full CL language.
7:31:11
aeth
it's funny that the three of us have different opinions here because I'd still say write a trivial function (inline it if performance is a concern, since its so trivial its implementation will never change) that is self-documenting in its name
7:47:20
beach
pjb: You must have read only part of the exchange. I explicitly said that it has nothing to do with semantics, and everything to do with communication with the person reading the code.
7:49:17
pjb
Still my point. (if (not (null (position …))) …) is a heavier cognitive load, to somebody who knows CL. When I see it, I start to wonder what's happening so special, why don't we just test (if (position …) …). And it's not even a double negation such as (not (not …)). You have to think hard to realize that it meant nothing.
7:50:01
pjb
beach: I realize that one can expect from smart and even not so smart compilers to optimize (not (null …)) out.
7:53:59
beach
I find it amusing that my arguments about conventions are nearly always met with individual opinions. Let me give a parallel concerning English prose.
7:54:06
beach
*I* might think it is fine to write text that has dangling participles, because after all *I* wrote it so *I* know what I meant. But that's not the point.
7:54:22
beach
The point is that even though *I* don't mind writing and reading such prose, I still don't write like that when it is meant for other people to read.
7:54:30
beach
When I write for other people to read, I can't ask each individual reader what they want, because I probably don't even know them. So I have to follow CONVENTIONS, whether I like those conventions or not.
7:54:32
beach
This aspect seems to be lost on many people here, very likely because they have little or no experience with working in teams, or with writing code that might some day be maintained by others.
7:55:11
pjb
beach: you are assuming what other people expect. I'm telling you that for me, it's harder to read (if (not (null (position …))) …) than (if (position …) …).
7:56:27
beach
I am not assuming what other people expect. I am posing that we should all adopt the same conventions, thereby getting used to what others expect. Of course, the way the community is made up right not, this is impossible.
7:58:06
pjb
When you call a function, you have to know what type of argument it expects, and what type of results it returns. If you write in a subset of the language that don't assume all the possible values, you are both limiting yourself and risking serious problems.
7:58:49
pjb
We see the problems all the time in C, because a lot of people don't know C, but assume some higher level language with C syntax…
7:58:50
MichaelRaskin
If you use English as analogy, let's consider the amazing convention of never splitting an infinitive and how it used to phrases that look tortured (and are still no easier to read)
7:59:02
fengshaun
is it possible to have the local copy of hyperspec be searchable (short of grep'ing the directory)?
7:59:39
pjb
fengshaun: there's a version of it in info format (it was distributed once with gcl IIRC).
7:59:47
beach
MichaelRaskin: That is not a convention. It is a stupid idea proposed by besservissers who have no training. Check Pinker for a more informed opinion.
8:00:38
beach
MichaelRaskin: I am quoting Norvig and Pitman for a reason. I consider them the analogue of Pinker.
8:01:07
MichaelRaskin
beach: it _is_ literally a convention. A Convention produced by people who didn't understand what they are doing, but now (unfortunately) widespread enough to become a convention in many places.
8:01:45
MichaelRaskin
I know that a lot of conventions proposed make code harder to read for me whenever they are literally followed
8:02:59
beach
MichaelRaskin: They only make it harder to read for people who stubbornly refuse to follow conventions established by smart, experienced, and knowledgeable people like Norvig and Pitman.
8:03:29
aeth
I personally follow a version of WP:IAR (ignore all [the] rules) in my projects. https://en.wikipedia.org/wiki/WP:IAR
8:03:45
aeth
e.g. my line length limit is 100 lines, but I go over that in a few places, because sometimes it makes things less readable to put a fake break in
8:04:20
beach
I think I totally fail to get this idea across, and I shouldn't be surprised. I will stop trying now.
8:04:29
MichaelRaskin
beach: when people who actually follow the specific authority are not easier to find than people who think this authority is harmful...
8:04:51
pjb
beach: and there is old code that you still have to be able to read. This is why I think my approach is better: stick to the CLHS.
8:05:12
beach
pjb: Yeah, and the other day we saw someone saying that "Norvig is a traitor", so we shouldn't listen to him either. Sheesh!
8:06:17
aeth
Speaking of Python, I think Python's a bit too dogmatic on the side of having one true style that must never be violated. CL generally seems to be a nice middle ground, keeping important conventions like parentheses, comments, and indentation (unlike C and C++, where indentation and bracket management is a bit of a nightmare)
8:06:18
MichaelRaskin
The idea that following a convention that doesn't fit one's way of thinking about things (and of writing in other languages) will make this convention feel natural is pretty optimisitic
8:07:12
aeth
In some languages, I have to use CamelCase libraries in my underscore_case project and, well, it's a bit ugly
8:07:36
MichaelRaskin
Which means that my mind will adapt to the entirety of what I do, not just to a specific style of Lisp
8:08:31
MichaelRaskin
(and of course if writing style conflicts with the mindset used for planning out the algorithms, either the latter wins out, or I become worse at making code correct)
8:12:53
pjb
Also, the question of style in Lisp cannot be resolved globally, because you can use different programming styles (and worse, mix them!) when you use embedded DSLs, or merely a new macro. Each program, each function can have its own style!
8:15:42
aeth
Imo... Programming is like art, as a special case of writing. You need conventions. You need to know the conventions. You need to mostly follow the conventions. But once you're good enough, you can break conventions in certain places.
8:16:00
aeth
Dogmatic linters to enforce 100% usage of conventions are too easy for programmers to write, but they're not necessarily the right thing to do.
8:16:03
pjb
A lot of programming team try to enforce a uniform style to depersonalize the code (and then use git history to find out who wrote what), but I like it when each programmer has a personal style and this can be seen in the code.
8:16:39
pjb
(By the way, recently AI algorithms determined that Molière wrote his pieces alone, and that Shakespear had help…).
8:26:55
no-defun-allowed
MichaelRaskin: Sticking to one convention for all languages is probably very, very bad. The closest to writing "Lisp" layout in C could be the GNU standard, and the reverse is the stuff you get on #clschool on a very bad day.
8:27:05
aeth
pjb: That sounds impractical. The Google Common Lisp Style Guide seems more pragmatic because a lot of the time when more than one convention exists, it says to use the existing convention in an area, which helps keep things somewhat locally uniform.
8:29:18
aeth
Well, I guess it's kind of vague there, too. e.g. "Choose wisely, but above all, consistently with yourself and other developers, within a same file, package, system, project, etc."
8:31:30
MichaelRaskin
no-defun-allowed: it's never the same convention, but some consistency of approaching semantically the same things
8:32:33
no-defun-allowed
Perhaps C and Lisp are a worse pair than average, but I don't think I would expect to write things with similar semantics in those, either.
8:33:14
aeth
MichaelRaskin: The problem is that Lisp's expression-oriented nature leads to very different idioms than in most languages. There's no need to set an intermediate variable in a COND, or even return to an intermediate variable in a COND, or even use a COND where an IF will do even if it would look too ugly/complicated with a "? ... : ..." ternary in most languages
8:36:20
aeth
The thing is, in CL nearly everything has a return value (only (values) doesn't, unless someone wrote code that returns (values), which is very unidiomatic and almost always implicitly inserts a NIL, anyway)... and almost all of those return values are meaningful (although it's kind of 50/50 with NIL)
8:37:23
aeth
CL for some reason is even more consistent and ideologically pure here than Scheme (very surprising), which often returns #<unspecified> or some other incredibly literal interpretation of its specification... which can mean different code even betwen CL and Scheme, two very close languages.
8:37:36
easye
I know someone who uses that to indicated that they have thought about the return at that point in the function and declare that it should return without values on purpose.
8:41:21
easye
(VALUES) Is actually preferable than RETURN-FROM 'cuz it makes changing function naming more difficult which often leads to mistakes.
8:44:27
easye
Still, I am probably happy to have RETURN-FROM require one to name the function that one is returning from, as I get a warning at compile time rather than have the program misbehave.
8:45:20
pjb
(defun foo () (block this-function (return-from this-function 'foo))) s/foo/bar/g (bar) still works.
8:46:33
pjb
(defmacro mydefun (name arglist &body doc-decls-and-body) `(defun ,name ,arglist ,@(doc-and-decls doc-decls-and-body) (block this-function ,@(body doc-decls-and-body))))
10:05:25
smokeink
How to tell asdf / sbcl to use the :system-cache ? :system-cache uses the contents of variable asdf::*system-cache* which by default is the same as using ("/var/cache/common-lisp" :uid :implementation-type) http://soc.if.usp.br/manual/cl-asdf/asdf/Controlling-where-ASDF-saves-compiled-files.html#Controlling-where-ASDF-saves-compiled-files
10:06:39
smokeink
I'm reading that doc page but I don't really grasp it. What to write in .sbclrc in order for it to use the system cache
10:10:14
jackdaniel
smokeink: I'm not aware of *system-cache* in asdf, maybe try setting *user-cache* instead?
10:11:23
smokeink
https://www.reddit.com/r/lisp/comments/23azqf/need_help_setting_asdf_cache_output_directory/
13:10:16
Xach
Yes, sorry, just missed the window. But I hope not to wait until the end of december for the december update.
13:10:42
Xach
This month's problems were caused by two libraries not working well together, compounded by my build hardware crashing sporadically
13:14:36
Lycurgus
so that, in your place, if debian is to be the reference, i'd wait a year from realease
13:20:02
jackdaniel
I imagine that testing just on one platform vs one implementation vs all libraries is demanding task
13:22:44
jackdaniel
Lycurgus: could you set such CI for current ql distributions? I think it would be useful for package and implementation maintainers regardless (I could use some reports for ecl i.e)
13:24:27
jackdaniel
Lycurgus: that was directed to you, because you seem to have some expeirence with CI and you are interested in that (justifully so!)
13:25:24
Lycurgus
misperception, I personally am not interested in CI, it doesn't fit in my resource profile for the things I want to do
13:26:37
Lycurgus
i am suggesting that it would be good and doable, not necessarily that anyone do it
13:26:43
MichaelRaskin
I think the only claim was that keeping a CI up is not harder than the work currently done
13:28:03
Lycurgus
in practice I know that there is a rats nest of incompatiblities, strengths and weaknesses in the major implementations, and I color within those lines
13:28:13
Xach
I guess that keeping a CI up would not be (much) harder, but setting it up initially seems like a big task.
13:32:52
Lycurgus
if the resources weren't a problem it might save effort in the end if you used it just as a filter, empirical backing for the not just sbcl criterion
13:58:34
MichaelRaskin
(decided to use my already-there code to check iolib compilation on ECL; ouch it does take time)
14:24:50
MichaelRaskin
But yeah, I kind of have most of the code needed to compute portability matrix for Linux+(SBCL/CCL/ECL/ABCL/CLISP), but I am not patient enough to wait until it builds
14:26:40
jackdaniel
it even makes it easy to construct pivot tables for different versions of the implementation/software
14:28:22
jackdaniel
seems that they are decently up to date; i.e https://common-lisp.net/project/cl-test-grid/library/adw-charting.html
15:15:39
phoe
a perfect situation would be having access to proper hardware where we can spin up virtualized mac/win/lin boxes on demand, and run our CI on those
16:18:31
Demosthenex
ok, so i've in the past used R for simple graphing and stats. i recall seeing (but cant find) a post on reddit that said CL could do all the same stuff with some library. does anyone have a recommendation?
17:07:40
edgar-rft
Demosthenex: if I know this right then XLISP-STAT was one of the predecessors of R and there had been several attempts to port XLISP-STAT to Common Lisp, for example https://github.com/blindglobe/common-lisp-stat
17:08:50
edgar-rft
if that's not what you're looking for see here for alternatives https://www.cliki.net/site/search?query=statistics
17:28:51
Josh_2
How do I convert a string like this https://plaster.tymoon.eu/view/1580#1580 to a list?
17:34:34
pfdietz
Also, use jsown. It's much faster than cl-json, even if you have to intern some of the names yourself.
17:34:37
phoe
and if you want to be super paranoid, set *PRINT-READABLY* to T in case you get an unreadable object
18:11:11
Demosthenex
edgar-rft: yeah, in R i use more the plotting library ... i don't do deep statistics.