freenode/#lisp - IRC Chatlog
Search
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.
18:00:54
dim
I'm not sure why buildapp / Quicklisp are giving me a hard time these days ;; loading system "pgloader" Fatal MISSING-DEPENDENCY: Component #:CL-LOG not found, required by #<SYSTEM "pgloader">
18:05:01
dim
it's like my Makefile arrangements are not loading/downloading QL systems from/to the right place, actually
18:07:27
dim
was there a change recently in Quicklisp in where to look for systems? it looks like my used-to-be self-contained quicklisp installation is happy to find systems in my user's quicklisp directory
18:19:15
glv
The problem came from the fact that the systems.txt file of the quicklisp distribution was missing some systems/packages/dependencies
18:21:26
glv
I don't know if this file is generated locally or if it is shipped as-is with the quicklisp distribution...