freenode/#lisp - IRC Chatlog
Search
5:50:30
krwq
so I'm not sure I'll be able to repro right now, when i don't touch *standard-output* everything works fine
5:51:25
krwq
thrig: but when i do with-output-to-string it technically is not using the same *standard-output*
5:53:39
krwq
without clearing .cache/common-lisp no repro, after clearing (that's when it happened the first time) i got repro
6:00:08
krwq
hopefully beach comes back from his break soon and explains that to or at least say that's a bug in sbcl or something - it bothers me since weekend and can't find the answer :P
6:01:38
edgar-rft
krwq: *standard-output* might be buffered. Try FORCE-OUTPUT and/or FINISH-OUTPUT before and after printing to *standard-output*
6:07:49
krwq
and also even if that is in fact buffering issue it technically should buffer different stream, shouldn't it?
6:10:29
krwq
the extra '.' seems to be before my output so i presume putting it after won't make a difference
6:33:37
buffergn0me
FINISH-OUTPUT is supposed to wait until buffered output is flushed before returning. FORCE-OUTPUT can issue an async flush and return right away
13:39:33
margaritamike
Any python people here know if Python's macropy is about as good as Common Lisp's macro system? https://github.com/lihaoyi/macropy
13:41:02
beach
margaritamike: If the answer is yes, what would you do with it? Leave #lisp and go program in Python instead?
13:41:47
margaritamike
Well just wondering about python's ability to make programs that write programs in python
13:45:17
dlowe
This is a good topic for ##lisp which is more about the lisp family and lispy languages
13:47:04
margaritamike
Because I want to use Common Lisp to experiement with some things from some cool papers that use lisp from back in the day, but only if the meta abstraction properties lisp provides can't be found elsewhere
13:48:01
schweers
margaritamike: why would you only want to use lisp if you can’t find these things in lesser^Wother languages?
13:50:20
White_Flame
any language can do anything, with unlimited hoops to jump through as a tradeoff
13:51:18
White_Flame
lisp macros are basically the easiest-to-accomplish full macro system in popular use
13:51:55
White_Flame
the python docs for that look quite involved, with restrictions on when it can run (not in the main class), dealing with AST nodes, and a ton of tools to try to help
13:58:22
margaritamike
White_Flame: so if python can do that, what the heck is left for it to be on par with lisp
13:59:23
White_Flame
("any language can do that" obviously assuming infinite tolerance for verbosity, multiple build layers, etc)
14:00:07
beach
margaritamike: Those don't have precise definitions, which is why it is futile to try to compare languages.
14:00:31
beach
margaritamike: And that is probably also why people can get away with suboptimal choices of languages for important projects.
14:01:34
White_Flame
then you really don't have any context to know what options are "better" than another, so simply learn stuff
14:02:01
White_Flame
once you know how to do something, then you can compare it to other languages and see if it looks better and addresses pain points you had along the way
14:02:25
White_Flame
but without knowing either, "which is better?" "is it good enough?" etc has no context to answer into
14:03:43
White_Flame
"better integrated" however probably is more precise, as lisp uses its natural data structures and list operations to deal with macro transforms, while python needs ast node classes and its whole set of methods on those
14:04:32
White_Flame
plus, I'm not sure that Python has well-defined boundaries of compile-/load-/run-time and what is defined when, for situations like this where python code runs during compilation time
14:32:45
schweers
Why this question whether or not it is on par with lisp? I understand if you want to know it in order to have better mental context. But otherwise ... just use lisp?
14:35:21
jackdaniel
I agree with schweers. Putting aside communities, ecosystem, performance, verbosity and personal taste lisp is as good/bad as python or practically any other programming language because there is not much more space for comparison
14:41:53
schweers
Sorry if I sounded mean. I get that one wants to compare how different approaches are, and maybe find out whether these weird lisp people really have valid claims.
14:42:24
schweers
I just wonder why some languages supposedly evolve closer and closer to lisp. If lisp is what you want, just use it.
15:04:21
dansa
I've been `processing' the literature (since the 80s and 90s to present time) on DSL and trying to understand the state-of-the-art of building and applying DLS to problems-in-general and I'm surprised to see how little Lisp languages are mentioned. I haven't found yet a single mention of PLT Scheme and more interestingly no mention of Racket at all. (I have read various papers from the first
15:04:21
dansa
decade of the current century.) In contrast, Haskell is mentioned all the time and I find that very surprising. Are even researchers ignoring Lisp?
15:07:42
dansa
I think any DSL research today should always be compared to the way Lisp deals with the problem because Lisp seems to be *the* language for DSL --- along with Haskell, I could concede. Racket seems the forefront of DSL today. I'm not aware of any well-known DSL-building problem that's not properly solved by Racket.
15:08:27
schweers
I’m not in academia, but I do get the impression that static typing is still all the rage in some circles. So lisp may be ignored on those grounds alone.
15:08:33
dlowe
If the discussion is going to involve cross-lisp comparison, we should take it to ##lisp
15:12:18
White_Flame
however, I think DSLs have more to do with language design and representing problem-space abstractions well
17:40:13
verisimilitude
I recall reading some email archive from around thirty years ago on how Guido van Rossum was unwilling to make some changes to Python that would make it quality as equivalent to Scheme, I suppose because he wanted to maintain more control over his pathetic and horribly-designed language.