freenode/#lisp - IRC Chatlog
Search
15:34:37
scymtym_
could sbcl users who are annoyed with ironclad compile times try compiling ironclad with https://github.com/scymtym/sbcl/tree/pack-iterative-hopefully-final and report whether/how much times improve? thanks in advance
15:41:53
trafaret1
I just newbie in programming and I have question. I find emacs very suitable for programming and I see how powerfull it might be. But need I learn elisp to handle with it properly?
15:44:22
jackdaniel
I use emacs for years and I know elisp only briefly (and didn't know it at all at first)
15:48:39
trafaret1
what is the diffrence between lisp and mathematica languages. I just know it is functional programming languages. Are they interchangable?
15:50:36
jackdaniel
mathematics are more declarative than functional. Common Lisp is multi-paradigm programming language and the most dominant approach atm is OOP
15:51:01
minion
trafaret1: please look at gentle: "Common Lisp: A Gentle Introduction to Symbolic Computation" is a smoother introduction to lisp programming. http://www.cs.cmu.edu/~dst/LispBook/
15:51:20
Fare
mathematica is based on some generalized rewrite logic, whereas Common Lisp is based on the more narrowly defined rewrites of the lambda calculus
15:52:19
Fare
Common Lisp also has older roots with lots of low-level side-effects and quirks, and a low-level namespacing mechanism.
15:52:43
Fare
mathematica usually works without namespacing; they do have some namespacing mechanism, but I've never seen or used it.
15:53:30
Fare
has the mathematica core language been open sourced yet? wolfram said he was working on it and it should be complete this year
16:08:21
Annatar
I have a question regarding the getopt lisp module... I am just at the beginning of learning LISP, and could not find any documentation or examples on how to use it. I use Clozure LISP (CCL).
16:08:50
Fare
I recommend didier verna's clon instead, for full feature, or my command-line-arguments for a simple solution
16:08:57
Annatar
Tried understanding the code, but as I do not know enough LISP yet, reverse-engineering has proven... challenging.
16:09:50
Annatar
Some context would probably help here... I am well versed with getopts(3C) in C and getopts in shell.
16:10:59
jackdaniel
here you can find documentation and reference manual: https://www.lrde.epita.fr/~didier/software/lisp/clon.php
16:15:18
Annatar
Thank you for the clues and the link, I will give clon another look. You ladies and gentlemen don't mind if I pop in from time to time to ask what could probably be described trivial questions under the best of circumstances?
16:18:13
kilimanjaro
I've heard clojure described as "not feeling lispy" (rough paraphrase). For any of you who share (or disagree) with this sentiment, would you care to comment?
16:19:16
sjl
Clojure doesn't feel like Common Lisp. As to whether it feels "Lispy", that depends on what the person means by Lispy I guess.
16:19:43
sjl
To me "Lispy" has become a word like "roguelike". Is Nethack a roguelike? Yes. Is FtL a roguelike? eh... maybe?
16:20:38
sjl
##lisp is probably a better topic if you're just interested in how Clojure compares to other lisps in general, as opposed to specifically Common Lisp
16:21:43
kilimanjaro
I guess I imagine common lisp as being sort of the "cream of the crop" of dynamic languages, between clos, the condition system, SLIME, etc, and have the impression that for many people who worked with CL a lot and moved to clojure that there was something lost in that transition
16:22:30
kilimanjaro
But I'm not that experienced with either and I can't tell if it would be more of an issue of the JVM being a frustrating place to live, or other aspects of the language design, etc
16:22:40
sjl
They're different languages. You lose some things and gain others no matter which direction you go. Asking in here you'll probably find people predisposed to liking CL more.
16:23:35
kilimanjaro
I'm not trying to start a flame war, I'm just curious about what CL-lovers think, if they have experience with both
16:23:45
sjl
Coming to CL from Clojure, it was refreshing to have mutability embraced when I want to use it, and it is a bit frustrating that the immutable side of things is fragmented into various libraries with different interfaces/documentation/etc.
16:24:44
sjl
like, if I want immutable persistent data structures, do I use cl-hamt? fset? sycamore?
16:25:04
sjl
some cocktail of all of them? no matter what I pick, it's not gonna fit in with the core language super well.
16:32:48
Fare
hated: overall poor object oriented features / integration, very poor backtraces, slow startup and slow compile, quirks with AOT compilation and discrepancies vs interpreted code
16:34:00
Fare
with Clojure I felt both like there was something liberating at a concrete level (especially compared to other JVM languages) and yet a relatively low abstraction ceiling (compared to CL, not to talk about Haskell & al.)
16:35:32
kilimanjaro
I use a combo of python & scala for work, so once I got a whiff of clojure I started drooling
16:36:10
Fare
expect a port of lil to gerbil rather than more development on the CL side on my part --- but I will take patches and help new maintainers
16:36:43
sjl
I feel like I've looked at LIL before and tried to understand it, but was too dumb to do so
16:37:11
Fare
if I were to work in that space, I'd probably develop the linear lisp that lil suggests will make mutable and immutable styles isomorphic.
16:38:26
Fare
sjl: I admit I never spent enough time to make it usable to newbies. It was a 20% project, the 80% project ended up being cancelled before lil proved useful, etc.
16:38:49
sjl
maybe I'll print out the PDF linked there and read it while I update this laptop, which is now two OS versions behind
16:39:31
sjl
Fare: it just seems like there's a layer of abstraction on top of it that goes beyond what most other libraries provide, and without understanding that it's hard to grok the entire system
16:39:34
Fare
once you get the idea of interface-passing style, it's quite easy; then there's how the library is organized, that is a bit under-documented.
16:40:14
sjl
"What is interface-passing style" is probably something I need to learn before understanding LIL.
16:40:43
sjl
is https://common-lisp.net/~frideau/lil-ilc2012/lil-ilc2012.html the place to learn that?
16:47:16
kilimanjaro
Fare: can you elaborate just a bit re: your comment on clojure having a low abstraction ceiling?
17:01:50
Fare
kilimanjaro, between complexity of protocols or user-defined types, limitations of the macro system, the fiasco of not offering the proper hooks for typed clojure, etc., I feel like Clojure is not offering a good environment for the kind of higher abstractions you can do with e.g. haskell typeclasses.
17:10:06
Fare
also, things like multiple arities with very different types make for a very nice "practical" feeling, but a very hard to abstract away interface.
17:10:34
kilimanjaro
well, like I said, I don't have much experience with either, but the most resonating thing for me is your comment about SLIME making type errors more bearable
17:11:28
kilimanjaro
the penalty for some dumb mistake in code running on the jvm seems much higher, both in terms of the time needed to figure out what is going on (e.g. the enormous stack trace) as well as making corrections and reloading code
17:29:18
kilimanjaro
anyways, the gist of it is that from my experience the penalty for dumb mistakes in a dynamic language is proportional to both how easy it is to diagnose them and how easy it is to correct them without disrupting the rest of the session or computation
17:30:02
kilimanjaro
working with jvm stack traces (as you mentioned) is pretty unpleasant and already starts to penalize dynamic languages in that sense
17:30:42
kilimanjaro
at my work we end up doing a lot with spark and this adds an extra level of unpleasantness, to the point where I think something like scala (which we use), despite being very heavy, is probably the right choice
18:26:25
Fare
kilimanjaro, I have ideas on how to make debugging uniformly more bearable including on the JVM
18:29:17
jackdaniel
\o/ ECL has implemented virtual streams handled by ext:run-program (that means, that gray stream may be used as :output argument) – cleaning up code now
18:32:28
jackdaniel
either way, it is not a trivial problem because gray streams doesn't have file descriptors which could be attached to process
18:32:47
Shinmera
Wait, actually, I did know. That's why I wrote a library that does copying in the background to allow using other kinds of streams.
19:02:10
jackdaniel
rumbler31: you may for instance do (with-output-to-string (s) (ext:run-program "ls" nil :output s)) what wasn't possible before
19:02:37
jackdaniel
some badly written libraries depend on that, so they can gather system information etc
19:10:15
rumbler31
jackdaniel: so what made the stream activity in ext:run-program special in that it *wouldn't* work with the stream created by w-o-t-s, that is now different and made to work the way you expect?
19:11:26
jackdaniel
so you have nothing to attach to a newly created process and magic doesn't happen
19:13:21
rumbler31
I know you said that virtual streams don't have a descriptor above, but if using a stream created by w-o-t-s wouldn't work with the run-program call, what kinds of streams were expected to work?
19:20:09
rumbler31
thanks for the explanation, I don't usually find myself working in those layers and I'd like to learn more. I'd be interested in reading your commit