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
20:36:50
minion
jmercouris, memo from phoe_: https://github.com/brown/swank-client https://github.com/eudoxia0/swank-protocol
20:41:11
sjl
jmercouris: I don't know. My only solution so far has been to try to document the stuff I release as well as possible, to be the change I want to see in the world.
21:08:28
Shinmera
jmercouris: The line of questioning that goes along the lines of "Why is the lisp community not doing X" always irks me because it implies you'd like to force other people to do what you want. This never works. All you can bet on is what you do on your own. Thus, if you don't like the current situation, /you/ do something about it. If you don't like the (lack of) documentation on a project, go fix it.
21:08:57
|3b|
and then watch as the next bunch of people comes in and complains it doesn't look modern enough :p
21:17:28
Shinmera
Anyway, I think the perception of the state of documentation is biased against Lisp. For one, there's so few libraries that the chance of there being multiple libraries for a task is relatively slim. This in turn means the chance for a documented and tested library for a topic to exist is slim as well. Then there's the argument that writing a library in any other language incurs so much effort that
21:17:30
Shinmera
documentation at the end of it seems trivial or almost required because you already spent so much time writing the rest.
21:18:14
Shinmera
Given that, I doubt that, if we compare the state of documentation against other ecosystems and account for the numerical differences, Lisp would stand out as particularly bad.
21:19:11
Shinmera
Either way, complaining about it helps absolutely nobody, so you'd be doing everyone else a favour by doing literally anything else.
21:19:22
|3b|
well, there is probably some difference due to domain of experience, like JS or PHP dev being more likely to be (or at least know) web devs
21:19:46
aeth
Most Lisp libraries are done by one person as a hobby. The well-documented projects are usually either done by more than one person, or done by one person who uses it in their job.
21:20:41
aeth
and, yeah, web dev stuff tends to be well documented because you just put the documentation on the web
21:21:22
aeth
Look at languages that aren't very web-focused. e.g. C and C++ projects often have terrible documentation.
21:26:17
jmercouris
Shinmera: I've never told anyone what to do with their project. I understand your sentiment though.
21:27:02
jmercouris
I think something that's important in life is giving people the benefit of the doubt, and taking things at face value
21:27:54
jmercouris
At any rate, asking the question is not complaining, it is a sincere question that has a very real value
21:28:20
jmercouris
If somebody responded with information such as "because x, y, z" they could either justify it, or explain its cause, and then it might possibly be remedied
21:28:26
Shinmera
The answer to that question is easy: because people don't want to do it. It takes time and effort.
21:29:03
jmercouris
and yet, the laziness of people is probably relatively consistent across languages
21:29:20
jmercouris
That's a literal answer, but not THE answer, you have to abstract one more layer up
21:29:20
p_l
jmercouris: popular libraries in most other communities benefit from economies of scale
21:30:07
jmercouris
p_l: this is true, definitely more people power = more likely to have documentation
21:32:02
jmercouris
Documentation is one of THE most important things in a codebase, and it's probably a cylic thing
21:32:12
jmercouris
You find a library online, has poor documentation, hard to get started with, so you write your own
21:32:44
p_l
jmercouris: and yet documentation is routinely shit on whenever money is on the table, especially by managers telling to write it
21:33:16
jmercouris
p_l: Yeah, that is true, but it is very short sighted to not write good documentation
21:33:36
p_l
it's very, very rare that someone has the right inclinations to make good documentation
21:34:25
scymtym
i think a good basis for this discussion would have been stating what "good" and "bad" entails w.r.t. documentation
21:34:54
p_l
in my professional work, the reality was that documentation was a task in which managers would figuratively shit on devs with "you have 3 days, and I still expect the tasks we planned for those 3 days to be done"
21:36:21
p_l
so... if you want good documentation, either somehow find a way to involve people (opensource programming projects usually don't have lot of success there) or fund it
21:38:03
aeth
jmercouris: If you want people to use Lisp, make something people want to use. Documentation is not the key issue here.
21:38:37
p_l
I can't recall any case that wasn't crazy outlier where good docs happened without money. Getting people is outlier, too
21:39:03
Shinmera
I don't know if my docs qualify as good. I just write them because I fear the wrath of other people.
21:39:20
aeth
What gets people to use a language is that that language solves a problem hat they need solved. People do not use Ruby because of its documentation, they use Ruby because of Rails. etc.
21:39:44
aeth
Sure, Ruby probably has better documentation on average than Common Lisp, but Rails probably came first, and it probably wasn't that well-documented at first.
21:40:21
aeth
p_l: People use Python because it's either the easiest language in the world or the hardest, depending on if you mind the indentation rules or not.
21:41:13
p_l
aeth: I, and many other people I know, started Python because the bundled docs contained full language tutorial AND docs for all the batteries included
21:41:50
Shinmera
Part of what I really liked about Java, too, was that the javadocs are really extensive.
21:41:52
p_l
the language itself was ultimately irrelevant, and tbh later on with less need for crutches I dropped it
21:51:53
fiddlerwoaroof
But, I agree in general: the reason why I got into Python in the first place was that it had excellent documentation for its standard library
21:53:53
fiddlerwoaroof
Anyways, is there any way to signal a style-warning at compile time in a conforming program? Do I just check for the condition I want to enforce and then throw a signal in my macro?
21:54:39
Shinmera
You'll probably want to sub-condition style-warning, since the type does not carry a message, otherwise.
22:14:19
rumbler31
The documentation in most code I've ever run into has been wrong, or misleading, or doesn't cover the topics I know it handles but need to use it for. In lisp, I load the library and play with the functions till I get a live understanding of what's going on and then move forward. At least for CL though, most libraries that are more complicated that might warrant some documentation seem to have it already, even as doc
22:14:19
rumbler31
strings in the function which seems to be enough for me. I've often heard people say "the documentation in this community is bad" and from a sample size of one (myself) I haven't seen it
22:15:43
rumbler31
in the c++ community its almost mandatory that documentation exists, because people think there is one version of c++, when there are really easily 5 or more. You need to know how the library is implemented and what platforms or toolchains support the features it relies on. Less so here
22:17:03
rumbler31
and live exploring some code is what they call prototyping, and they need it because there doesn't exist a live image workflow. So they end up wiring up all the common parts of any program just to exercise the functionality of a library, the burden of which is experienced less so by the cl community (imho, sample size one)
22:17:44
rumbler31
so jmercouris: in good faith, what task do you which to undertake for which you've found documentation lacking?
22:18:57
jmercouris
rumbler31: Well, I didn't think of a particular instance that brought it up, I was just thinking about lisp in general
22:20:09
rumbler31
so you're asking because you've heard it said? or you've experienced it lately but don't necessarily have a specific example? Or a different question, do you think that there is an issue with poor/no documentation?
22:21:35
jmercouris
I think there is definitely an issue, lisp does that have discoverability, but a brief code example would save a lot of time when evaluating libraries