jnxx

28 ms·

271.
by jnxx 6y ago
In my experience, it is much better than cmake: Apart from having good and comprehensive introductory documentation, it has a nicely ordered reference and also, it is stable, while cmake is changing, sometimes in backward-incompatible ways,
272.
by jnxx 6y ago
I just learned it three days ago, based on the tutorials I linked, and I found it quite easy to learn. In particular, it has very good introductory as well as reference documentation.
273.
by jnxx 6y ago
That is my experience as well. I have been using autotools-generated packages well over 20 years but thought it would be difficult to learn. Recently, I got the job of supporting dozens of packages in an organizational environment. The firs
274.
by jnxx 6y ago
If you want to build and install custom packages which in turn depend on libraries which are newer than system packages, this sounds like a perfect use case for GNU Guix as a package manager (e.g. on top of Debian or Arch): http:/&#x2
275.
by jnxx 6y ago
One thing that I am wondering: Why do git repos with totools build chain often include the generated files, like ./configure ? Wouldn't it just be better to provide the source files (autoconf.ac and Makefile.am) and instruct devel
276.
by jnxx 6y ago
A nice introduction how autotools work, what are the basic concepts, and what one needs to know to configure an autotools build in a standard project. Especially compared to some other build systems, it is not only solid and well thought-ou
277.
GNU Autotools: A Tutorial [pdf](elinux.org)
91 points by jnxx 6y ago|77 comments
278.
Paradox of the Plankton(en.wikipedia.org)
1 points by jnxx 6y ago|0 comments
279.
by jnxx 6y ago
ouch!
280.
by jnxx 6y ago
"man mmv" tells it all.
281.
by jnxx 6y ago
One thing I am wondering is why there apparently exists no easy to use quasi-standard for a GUI library in Common Lisp. At least none that I am aware of. And I do not see any technical reason for that - my experience is that Clojure, for ex
282.
by jnxx 6y ago
A fantastic talk by a thoughtful and calm guy. Gives an overview about common aspects and subtle but important differences, and explains a bit about the culture of Common Lisp. Together with the books from Edmund Weitz and Peter Seibel this
283.
Scicloj Meeting #19: Alan Dipert: Common Lisp for the Curious Clojurian(youtube.com)
3 points by jnxx 6y ago|4 comments
284.
by jnxx 6y ago
> On one side, there are people who are concerned with whether or not a feature is desirable. The thing is this: You can add something which, in isolation, seems desirable and positive -- but in the greater picture, is a net negative due
285.
by jnxx 6y ago
I very much want to agree with you. Only that I do not know any more what "Pythonic" is supposed to mean. One thing that Larry Hastings refers to seems often to be underestimated - readability. It seems nice to be able to do code
286.
by jnxx 6y ago
A good example why immutability by default seems to be the right thing - in Clojure, "seq" would not have been modified by the first filter expression: user=> (def seq_ (range 1 11)) user=> (filter (fn [x] (== (mod
287.
by jnxx 6y ago
What you cite appears misleading to me - the text by Greg Kroah-Hartman talks very clearly about interfaces within the Linux kernel, not interfaces between kernel and user space, such as the syscall interface, which are stable. If you
288.
by jnxx 6y ago
So, if it isn't finished, why do people not use pattern matching implemented as a macro, until things like scoping are ironed out?
289.
by jnxx 6y ago
> then you have the opposite problem - you need to do extra leg-work to communicate a value to the surrounding scope. that would be far less likely to break things in an unexpected way, as in "explicit is better than implicit&quot
290.
by jnxx 6y ago
> Let's count - 3rd-party patmatching libs for Python exists for 10-15 years. And only now some of those people who did their work as "third parties" came to do it inside mainstream Python. Well, somewhat tongue-in-cheek,
291.
by jnxx 6y ago
> Well, I also want Linux version 234536464576.3.1-final-forever, but instead run 5.4.0 currently, and install new versions from time to time. The same is essentially with Python too. Just one thing, if mainline Linux would work like Py
292.
by jnxx 6y ago
For my part, as I maintain some complex academic research software, I would be much more interested in continuing support for Python 2, and more comprehensive numerical, math and vector libraries for Racket.
293.
by jnxx 6y ago
> Python, being a multi-paradigm language with the strong functional side Coming back to that, just a reminder that lambdas in Python are still gimped, closures do not work as expected because of -- scoping, and core developers in Pytho
294.
by jnxx 6y ago
I know really little about Python except that it was heavily adopted by Google. However for C++, I think that corporatization is having a strong negative influence on the language, which leads to it being stuffed with poorly integrated feat
295.
by jnxx 6y ago
> Group b) overlaps with functional Lisps, but no more than with ML and Haskell, or even modern fundamentally-procedural languages like Kotlin(?) and Rust, so functional Lisps still aren't a great reference point. Both of them stem
296.
by jnxx 6y ago
> Python, being a multi-paradigm language with the strong functional side I would doubt that. Surely, things like Numpy are written in a functional fashion, but Python relies very much on statements, iteration, things not being an expres
297.
by jnxx 6y ago
> but a lot of what you list was taken from different languages, or is distinctly un-Lisp-like in Python, or was in Python from the start rather than absorbed over time, or is just obvious enough to put in a very high-level language to b
298.
by jnxx 6y ago
> I don't think Rust suffers from the issues that make functional languages hard to compile, so that might be a bad example. The issue is that in functional languages, the compiler has more information and can reliably rely on more
299.
by jnxx 6y ago
> C has low-level bit operations, As an unrelated fun fact, Common Lisp has more low-level bit operations than C, such as "and complement of integer a with integer b" or "exclusive nor": http://www.lispwork
300.
by jnxx 6y ago
Reading the discussion, I think the criticism is more motivated by the subtle but crucial differences to most functional programming languages.

More ›