3 ms·

As you sort of imply, it doesn't help that each implementation is half-baked, incomplete, and unmaintained after 16 months. I've seen similar libraries that do

As you sort of imply, it doesn't help that each implementation is half-baked, incomplete, and unmaintained after 16 months. I've seen similar libraries that do the following, for example: * Serialization and deserialization * Promises * Generators * CPS Somehow none of these "100 line wonders" make it into idiomatic usage, despite their purported utility. These channels as presented don't solve many problems well. They will be very slow and contentious, they will be expensive to make, and they will not guard against memory ownership issues because you're just passing pointers to objects around, which message passing is supposed to solve. But, it'll become another library on Quicklisp that 3 people use and that people's applications will inadvertently depend on. Lisp is a fantastic language for many things, including a plethora of production applications, but it being a local optimum for exploratory programming means we get lots of very incomplete, scratch-an-itch code that is pawned off as a library intended for mass consumption. In fact, the author links to his GitHub repository, where you find exactly this random assortment of disparate utilities. If I had my way, the rhetoric of this post would be closer to a pedagogical exposition of channels, how they're used, what their benefits are, a proof-of-concept implementation, and a non-trivial example application. I would vehemently stay away from having the thesis be anything about Lisp or the ease of implementing small POCs in Lisp.

codr4life 10y ago
This implementation is yours to maintain, that's why it's simple enough to make that possible. There is plenty of room for simple. They allow building networks of cooperating threads, which is the purpose. Erlang isolates, Go doesn't, in the end I like the choice.
- reikonomusha 10y ago
  Copy-pastable blog post code is the antithesis of good software engineering practices. DRY, encapsulation, reusability, broadly applicable abstractions, and so on should ideally be heralded as the thing to strive for.
  - codr4life 10y ago
    I don't agree. As long as you understand the code and it solves your problem, owning is an advantage. Why is it so important to you that no one steps out of line and tries to use their brain as more than an answering machine?
    - reikonomusha 10y ago
      The less I have to maintain fundamental abstractions, the more energy I can spend building on top of these abstractions. There's a name for this: NIH [0]. While there are some folks [1] that have the time, energy, and brilliance to build things from the ground up all themselves, I unfortunately do not. Moreover, in a collegial work environment, this means the burden is on me to test, document, communicate, and educate on this library. There's enormous additional complexity and risk that comes with building from scratch things like these which change the whole programming paradigm of your application—again, especially in a coworking environment. [0] https://en.m.wikipedia.org/wiki/Not_invented_here https://en.m.wikipedia.org/wiki/Not_invented_here [1] Donald Knuth and Fabrice Bellard, to name a few.
      - taeric 10y ago
        It is a fallacy that you are not maintaining something with your dependencies. It is the hope that you get nothing but benefits from depending on someone else to build strong dependencies. It is as true of a reality that they are pursuing goals that are not yours. It is odd, because the "micro library" world ostensibly fixes this by greatly limiting the scope of a dependency. However, it also encourages chaining yourself to many other entities. And it is always the mistakes that people remember, such that anyone that has been burned will remember how it was enabled by micro libraries.
        reikonomusha 10y ago
        You are maintaining the API boundary between your application and your dependencies. I certainly do not maintain (in the most common sense of the word) my operating system source code, my compiler source code, my server source code, etc. I have no problem with micro-libraries. In fact, I developed on the notion of the micro-est of libraries: a library generator that gets down to function-level dependencies [0]. [0] http://web.archive.org/web/20140711172208/http://symbo1ics.com/blog/?p=1936 http://web.archive.org/web/20140711172208/http://symbo1ics.c...
jonathanstrange 10y ago
it doesn't help that each implementation is half-baked, incomplete, and unmaintained after 16 months I couldn't agree more, that's the real problem with CL and the reason why I keep using scheme and Racket. (Well, that and the antiquated package/unit systems with multiple options and caveats.) Just take a look at cross-platform user interface library bindings, there are seemingly plenty of options, but in the end they are all some sort of unmaintained hacks that may or may not work on some implementation/platform combo. Threading itself is another example, by the way. Almost any addition to the outdated standard is a mess that sometimes works, sometimes doesn't work. It's a pity, since CL implementations are of such a high quality (e.g. SBCL) and it offers everything a programmer can dream of.

codr4life 10y ago

This implementation is yours to maintain, that's why it's simple enough to make that possible. There is plenty of room for simple. They allow building networks of cooperating threads, which is the purpose. Erlang isolates, Go doesn't, in the end I like the choice.

reikonomusha 10y ago
Copy-pastable blog post code is the antithesis of good software engineering practices. DRY, encapsulation, reusability, broadly applicable abstractions, and so on should ideally be heralded as the thing to strive for.
- codr4life 10y ago
  I don't agree. As long as you understand the code and it solves your problem, owning is an advantage. Why is it so important to you that no one steps out of line and tries to use their brain as more than an answering machine?
  - reikonomusha 10y ago
    The less I have to maintain fundamental abstractions, the more energy I can spend building on top of these abstractions. There's a name for this: NIH [0]. While there are some folks [1] that have the time, energy, and brilliance to build things from the ground up all themselves, I unfortunately do not. Moreover, in a collegial work environment, this means the burden is on me to test, document, communicate, and educate on this library. There's enormous additional complexity and risk that comes with building from scratch things like these which change the whole programming paradigm of your application—again, especially in a coworking environment. [0] https://en.m.wikipedia.org/wiki/Not_invented_here https://en.m.wikipedia.org/wiki/Not_invented_here [1] Donald Knuth and Fabrice Bellard, to name a few.
    - taeric 10y ago
      It is a fallacy that you are not maintaining something with your dependencies. It is the hope that you get nothing but benefits from depending on someone else to build strong dependencies. It is as true of a reality that they are pursuing goals that are not yours. It is odd, because the "micro library" world ostensibly fixes this by greatly limiting the scope of a dependency. However, it also encourages chaining yourself to many other entities. And it is always the mistakes that people remember, such that anyone that has been burned will remember how it was enabled by micro libraries.
      - reikonomusha 10y ago
        You are maintaining the API boundary between your application and your dependencies. I certainly do not maintain (in the most common sense of the word) my operating system source code, my compiler source code, my server source code, etc. I have no problem with micro-libraries. In fact, I developed on the notion of the micro-est of libraries: a library generator that gets down to function-level dependencies [0]. [0] http://web.archive.org/web/20140711172208/http://symbo1ics.com/blog/?p=1936 http://web.archive.org/web/20140711172208/http://symbo1ics.c...

jonathanstrange 10y ago

it doesn't help that each implementation is half-baked, incomplete, and unmaintained after 16 months I couldn't agree more, that's the real problem with CL and the reason why I keep using scheme and Racket. (Well, that and the antiquated package/unit systems with multiple options and caveats.) Just take a look at cross-platform user interface library bindings, there are seemingly plenty of options, but in the end they are all some sort of unmaintained hacks that may or may not work on some implementation/platform combo. Threading itself is another example, by the way. Almost any addition to the outdated standard is a mess that sometimes works, sometimes doesn't work. It's a pity, since CL implementations are of such a high quality (e.g. SBCL) and it offers everything a programmer can dream of.