freenode/#lisp - IRC Chatlog
Search
19:42:32
jasom
clintm: functions, on the other hand, are translated to js names, which are namespace-free
19:43:56
jasom
so the parenscript form (foo bar baz) will be expanded to foo(bar baz) if the symbol FOO is not bound to a PS macro.
20:02:08
drunk_foxx[m]
Are there any good places to practice using common lisp except books and websites with some usual (mostly stupid) excercises? Like, libraries that may need routine work, which can be handled by a person who has just started Lisp a couple of months ago or something like that? Any active projects to work on?
20:02:58
pmetzger
drunk_foxx[m]: There probably are a bunch of such things, but you may have to learn a bit more about the community to find them.
20:09:29
Shinmera
Adding a test suite for Plump would be good since that's something people actually do use.
20:14:45
pmetzger
I disagree. I think anything people use and plan to use for more than a trivial amount of time needs tests. Otherwise fixing bugs and refactoring code is too dangerous and unpleasant.
20:15:34
pmetzger
Earlier today I merged a bunch of changes from someone else's branch of some code I've been hacking on into mine and pushed out the merge, and the only reason it worked right was there was a test suite I could run to shake out any issues.
20:15:56
pmetzger
Any code that never needs to be changed ever again doesn't need tests. When you find me such code, let me know. :)
20:17:32
drunk_foxx[m]
Even if it is bug free, there may exist plenty of reasons fot changing the code in the future
20:19:16
jackdaniel
on the other hand, even if it has bugs it doesn't necessarily mean they must be fixed
20:26:00
verisimilitude
Look at any working implementation of basic mathematical functions, pmetzger.
20:27:01
verisimilitude
Now, it's clear that code can and is perfectly bug free or else we wouldn't be able to do much of anything.
20:27:07
pmetzger
verisimilitude: Famously, Xavier Leroy had the implementation of basic math functions in OCaml broken for the first six months it was in use. Tests would have caught that.
20:28:31
Shinmera
writing useful tests is a lot of effort. Effort and time I usually don't have to offer.
20:28:39
pmetzger
Anyway, these days I prefer for things to be more than simply tested but actually formally verified, but tests are at least required. I fire programmers who don't want to put tests in their code and who don't want to document their code. OTOH, one doesn't need to operate to please _me_ unless you work for me.
20:30:07
verisimilitude
I'm also inclined to believe the way tests are done nowadays is a fad, like so many other things in programming nowadays.
20:30:31
pmetzger
verisimilitude: But again, you don't need to do as I suggest. That said, I fire people for refusing, and won't collaborate with people who refuse to. I have no tolerance for cowboys. But your milage may vary. Live as you wish, not to please me.
20:32:05
fouric
is someone really a "cowboy" if they would rather not write tests at all than write flawed tests
20:33:19
pmetzger
TDD has you test the tests by first running the test without having the feature implemented. It's crude but works.
20:33:25
jackdaniel
invalid tests happen sometimes and they waste time, but in general it pays off well
20:34:04
pmetzger
it gives you such pleasant agility. you aren't scared to make big changes any more because you can check if your changes worked.
20:35:58
drunk_foxx[m]
> Anyway, these days I prefer for things to be more than simply tested but actually formally verified, but tests are at least required. I fire programmers who don't want to put tests in their code and who don't want to document their code.
20:35:59
drunk_foxx[m]
Somewhat related to the discussion: what do you think about literate programming compared to the standard process of documenting/commenting the code?
20:36:03
pmetzger
Anyone who thinks they will always write the correct code the first time out isn't to be trusted.
20:36:34
pmetzger
Literate programming is really great for manuals and teaching. It seems to not work for writing real software though.
20:36:49
pmetzger
Knuth did well with it for writing TeX but it doesn't seem to work really well in practice.
20:37:05
pmetzger
That said, solid comments are also useful, but one needs to know what one is commenting.
20:37:27
pmetzger
I have seen amazing examples of the use of literate programming for creating textbooks and manuals though.
20:39:01
verisimilitude
I always write documentation strings, drunk_foxx[m], which I believe is roughly halfway to full literate programming.
20:39:48
pmetzger
I agree. Docstrings are documentation for users of an interface, not documentation of code itself.
20:39:56
verisimilitude
I'm inclined to believe the interactivity of Lisp trumps literate programming.
20:40:28
Shinmera
pmetzger: It's not just that, it's that literate programming is a description of how to organise documentation whereas docstrings are a way of attaching documentation to definitions.
20:40:44
verisimilitude
So, literate programming is effectively preparing to make the program as if a book.
20:41:55
verisimilitude
Greater documentation, such as the reason for the overall structure of the system, isn't encompassed by this, however.
20:42:05
pmetzger
jackdaniel: A real manual is better, but these days the equivalent of docstrings in other languages (like javadoc and the like) are often all you get. :(
20:42:39
jasom
jackdaniel: docstrings are just strings; you could put an entire man page in a doc string, and it would be API documentation. You could put the text for the wikipedia page for a mongoose, and it's not documentation.
20:42:45
drunk_foxx[m]
In my humble opinion, it's quite essential what the concept of literate programming whas inspired by - Knuth was a user of such languages like Pascal, Java, C and C++, and they lack in readability a lot, unlike Lisp with its AST structure, for instance; that basically means LP is much less useful for Lispers just due to the features of the language itself
20:43:48
jackdaniel
jasom: sure, but are we talking about theoretical possibilities or what people usually mean by doscstrings?
20:43:51
jasom
fwiw, Here's an example of what CWEB looks like (a C literate programming tool) https://www.imperialviolet.org/binary/critbit.pdf
20:44:04
Shinmera
I hate literate programming just as much as docstrings next to the definitions. It's distracting me from the code. Put the documentation elsewhere.
20:45:48
drunk_foxx[m]
Wikipedia disagrees on that, but I didn't dive into much detail about the history of CWEB, so not sure
20:46:05
pmetzger
I like having docstrings in code. Before such things existed, comments before functions explaining their interfaces were common. They're still common in other languages.
20:46:33
pmetzger
WEB and TANGLE were built by Knuth. TeX was ported to C after TeX's initial completion.
20:46:49
drunk_foxx[m]
That's undoubtable, I just think some are more "naturally readable" than others. Again, biased
20:47:57
verisimilitude
It makes me think of how C programmers go ``gee wiz'' with their grep and their lint and their memory leak detectors, where all of that is terrible and also effectively useless with a decent programming language.
20:48:05
jasom
pmetzger: the question Shinmera is raising (I think) isn't docstrings v. no docstrings, but docstrings next to the function definition vs. docstrings elsewhere. Without some way of attaching comments to a function, you must put them in the source adjacent to the function. With a lisp system, you can query the function's documentation through your IDE.
20:49:11
Shinmera
Yes. I put the docstrings in a separate file because I hate lots of vertical space that's spent on stuff other than code.
20:49:21
jasom
verisimilitude: linting tools are useful in most programming language; they are particularly useful in untyped language like lisp (style warnings are a type of linter, for example).
20:49:26
pmetzger
You can always manipulate docstrings in lisp away from the definition, but I think it's bad style. While reading the code you want to read the same information.
20:50:29
pmetzger
C and Lisp are at different parts of the stack. The fact that even (say) SBCL has C code in the implementation kind of tells you something there.
20:50:33
verisimilitude
Something else that separates a Lisp style warning and UNIX lint is how the system already has the code; it doesn't need to parse the code separately.
20:51:00
verisimilitude
This entirely eliminates idiocy like C++ syntax being understood differently by different compilers, because it only has to be understood once and then disregarded.
20:51:16
pmetzger
C is, as it happens, pretty bad at what it does, but part of that was what was possible in 1970 vs what you can do now (see Rust for example.)
20:52:50
pmetzger
verisimilitude: I think I read the Unix Haters Handbook stuff before it was published (it mostly came from posts to a mailing list) but I haven't looked at it since. A lot of it was bitter comments from random ITS types etc.
20:54:10
pmetzger
verisimilitude: so you think there's something wrong with being effeminate? are you a homophobe?
20:55:36
pmetzger
verisimilitude: you do get that if you said that IRL it might not be physically safe for you, yes?
20:56:17
verisimilitude
I've noticed that's a common response, an implied threat; of course, Shinmera.
20:57:07
theemacsshibe[m]
> verisimilitude: so you think there's something wrong with being effeminate? are you a homophobe?
20:58:22
theemacsshibe[m]
That's quite rude to gay people. My datefriend is much better than any Rust user.
21:05:28
theemacsshibe[m]
I like LP, it's like reading a maths textbook where the author walks you through the problem very verbosely.
21:08:14
theemacsshibe[m]
I'm pretty sure most LP programs have splitting functions which isolate the code and the documentation so you can just use either.
21:11:58
verisimilitude
Yes, Josh_2; say, has anyone else had issues with CCL being unable to find its queer little database it uses; I've been unable to do some work under it and, using GuixSD, am reluctant to directly modify anything related to it.
21:13:11
verisimilitude
I'm also having issues conditionally loading this code, because CLISP whines about the #$ reader macro.
21:15:05
phoe
Yes, it is over - though people are staying for longer since Marbella is just that pretty
21:15:53
jcowan
Am I right to think that whereas block names have both lexical scope and dynamic extent, catch tags have indefinite scope and dynamic extent?
21:16:32
rme
ccl expects to find the interface db (darwin-x86-headers64/ or whatever) in the #p"ccl:" directory. By default, that's the same directory as the heap image file. You should be able to set the environment variable CCL_DEFAULT_DIRECTORY if that is not right.
21:17:13
jackdaniel
trying to call return-from from to non-existing block (i.e from escaped function) signals a condition
21:19:09
Xof
and I didn't even manage to tell didier that I have a fix for all his method-combination issues
21:20:19
theemacsshibe[m]
Are there any interesting lisp shows in Melbourne Australia? Not the Florida one.
21:26:35
verisimilitude
There's a /lib/ there, but no x86-headers/, no libc/, and not a single cdb file.
2:25:13
verisimilitude
The test is separate; sure, it only runs once, but then you're caught in the idea that you can write perfect tests to test imperfect code.
2:25:45
verisimilitude
That recursion needs to be broken somewhere and the easiest place is before it starts.
2:26:55
verisimilitude
It seems strange to talk about performance like that for several reasons; firstly, it's clearly more important that the program is correct; secondly, this is Lisp and, if only performance mattered, Lisp wouldn't be chosen.
2:27:35
verisimilitude
With the ASSERT, you can even use restarts and continue; you can't do that with a test, but what if your test is wrong and fails to cover something that would only show up during actual execution over a long period of time?
3:05:28
pfdietz
Absent formal verification, testing is indispensible. And you might as well package up the tests so anyone can run them.
3:09:49
pfdietz
Delivering software of any complexity that works is very hard, and testing is not an optional part of that process.
3:13:02
verisimilitude
There's a difference between using a program to see if it works and writing however many test cases that check if something continues performing identically according to the test.
3:13:18
verisimilitude
Using a program to truly see if it works is necessary, but not this testing fad.
3:15:18
pfdietz
Casual execution of a program to "see if it works" will do f-all in a program of any complexity.
3:16:59
verisimilitude
``Beware of bugs in the above code; I have only proved it correct, not tried it.''
3:17:41
verisimilitude
Now, the funny aspect of all of these things that supposedly aren't optional is that they really are optional.
3:18:45
verisimilitude
Give a man a test and he'll know his program works. Give a man many tests and he'll never be quite certain.
3:19:16
pfdietz
Give me your code that you haven't tested, and I can be quite certain it will be shit.
3:19:59
verisimilitude
I tested this by actually running it and making sure it produced proper output in a few different cases.
3:20:14
verisimilitude
I don't need some fancy test suite to make certain a macro compiles a description correctly.
3:20:24
smokeink
check this out guys: https://www.youtube.com/watch?v=iavSKtqjVNA IOHK | Runtime Verification; Prof. Grigore Roșu CEO.
3:21:35
smokeink
"The 50 years of research and development work on K made possible what many thought couldn't be done. We can automatically generate a correct-by-structure virtual machine from it's formal specification, which is fast enough to run real programs." this is the tool in action https://www.youtube.com/watch?v=eSaIKHQOo4c
3:31:55
smokeink
Semantics-based Program Verifiers for All Languages https://www.youtube.com/watch?v=cxdPjbpn95s
3:36:15
verisimilitude
Also, pfdietz, if you actually are inspecting that code, even a tad, know that I purposefully wrote the macros to attempt to generate invalid lambda lists if my rules weren't followed.
4:08:05
White_Flame
verisimilitude: yeah, it's great that we can use runtime checks at compiletime in lisp
4:08:25
White_Flame
as opposed to having the runtime burden, or running separate sanity testing code not included in the runtime
4:10:34
pillton
verisimilitude: The unit tests aren't for you today, they are for you in six to twelve months time and they are there for your contributors to ensure they don't make the same mistakes as you did.
4:11:14
pillton
verisimilitude: Unit tests are also valuable when you are developing across multiple lisp implementations and on different platforms.
4:11:30
White_Flame
the biggest problem with unit testing is that people have no idea what a "unit" should be, and end up meaninglessly fine-grained
4:12:24
White_Flame
that, and complected design makes separating out & configuring units for testing incredibly difficult
4:15:16
White_Flame
I've always done coarser grained testing, and never once lamented not spending the time to meticulously unit test
4:15:44
aeth
Lisp is actually a good choice for if performance matters. It's not competing against fast languages like C or C++ or Java or C# (although it can be about as fast as the latter two)
4:15:58
aeth
It's competing against Ruby, Python, etc. Slow, interpreted languages for the most part.
4:16:50
aeth
White_Flame: I mostly REPL-test and run example programs. REPL-testing is perfectly fine... until you refactor. Oh well, I hope I don't introduce new bugs.
4:19:14
White_Flame
but even so, you choose when to call your testing functions. Startup your code environment, then call test functions
4:20:39
aeth
Not everything I do is currently dynamic. Some things were trivial, like for any higher ordered function using 'foo instead of #'foo
4:21:51
aeth
With the exception of an entirely CLX graphical application (which would be 2D-only?), that's basically impossible for graphical applications, although C can be minimized.
4:29:54
verisimilitude
As you can imagine, I don't have any contributors, pillton; note that in CL-ECMA-48, there is a single check to determine if the Lisp implementation meets the one nonstandard quality needed (support for a seven-bit character set) and one additional check if ASCII is supported for optimizations. Asides from this, there's no nonstandard dependencies, but checking on multiple implementations is still valuable and what I do.
4:30:53
verisimilitude
While I can understand how tests are comparable to a seatbelt, I disagree with the analogy. A seatbelt isn't going to protect you if you drive recklessly into an eighteen wheeler; you will still be destroyed, with or without the seatbelt.
4:35:34
verisimilitude
I'd think tests, at least as commonly used, are more comparable to wearing a helmet constantly.
4:36:25
verisimilitude
A helmet will protect you from a subset of truly oblivious and stupid mistakes, such as walking near a building with debris falling, so long as the debris isn't so strong to break the neck or strikes a part of the body not protected by the helmet.
4:37:05
verisimilitude
Well, you have some people writing that tests are mandatory; I'm simply challenging such an assertion.
4:39:26
verisimilitude
In closing, wearing a helmet while wearing a seatbelt is an even safer way to drive, so people should clearly do that.
4:39:46
verisimilitude
If you're going to be a professional trucker, a helmet should be mandatory; I'd fire any truck driver of mine who refused to wear a helmet.
4:44:10
pfdietz
V, out of curiosity: what's the size of the largest program you've been involved in the development and maintenance of?
4:46:56
jcowan_
I have a little plugin for the Chibi Scheme REPL; if you type @OK, it writes the previous expression and its result into a file of tests.
4:47:39
jcowan_
Also, there is a counterexample to the correctness-ueber-alles assumption, I think due to Ken Thompson but I'm not sure.
4:48:10
jcowan_
See [a large, long-running program with many bugs]? Which would prefer, eliminating 100 bugs, or making it run 100 times as fast?
4:49:59
pfdietz
The reason I ask is that a lesson you have taken from a toy example of a few hundred lines will not apply to development of a system of many thousands or millions of lines.
4:50:11
verisimilitude
Well, I try very hard to not let any of my programs get larger than one thousand lines, if I can help it; one way I do this is by looking for functionality I can split off.
4:50:40
pfdietz
In large systems, testing is vital to prevent the system from regressing as it evolves.
4:50:47
verisimilitude
I'd be inclined to believe a project encompassing millions of lines is already doomed, one way or the other.
4:51:57
verisimilitude
That sentence reminds me of the ending to ``AKIRA'', pfdietz, the idea of a system so grossly large evolving without regressions.