1. 2

    Surprisingly, to replace the giant Google Analytics, the article introduces two very new software, and doesn’t mention comparable ones like Matomo (https://matomo.org/). These new ones are worth a look though.

    1. 2

      Yeah, we’ll be covering “heavier” tools like Matomo next week. This article was “lightweight” ones (though even then there are others, but we chose the two open source ones that seemed to rise to the top).

    1. 2

      I use a slightly similar tool for toy projects: https://pressly.github.io/sup/

      1. 1

        t reads Supfile, a YAML configuration file,

        then it’s not the same!

        1. 1

          Oh okay. What’s the difference?

          1. 2

            the config isn’t yaml, it’s python

      1. 3

        This is one of my favorite Lisp features that is not often replicated (as well) in other languages / environments (and definitely not 20 years ago). It also makes it easy to diagnose and debug issues.

        However it also makes it easy to screw up one’s production environment and it takes discipline to make sure the changes one does in the live environment are also reflected in the source code.

        1. 2

          it takes discipline to make sure the changes one does in the live environment are also reflected in the source code.

          this is actually easy to do by not developing in the live environment.

          I’d like to add that there is no “dive in or reject” choice here. One can use this when it makes sense, like to reload a user’s settings in my case, and in doubt, safely restart the app.

        1. 1

          Is Qt4 still viable for new development? Qt 5 shipped 2012-ish, if memory serves, and last time I tried to build a Qt 4 app (not for CL… for C++) on a relatively modern system (2018-ish) it was terribly painful. Maybe CL hides the pain but that doesn’t feel like something I’d like to rely on.

          1. 1

            Indeed CL hides the pain (it’s straightforward to install, develop and build the app), but I see what you mean… there’s some work ongoing for CL and Qt5 with CFFI and gobject-introspection, we’ll see if the attempts succeed…

          1. 2

            The Common Lisp Qt4 bindings (along with QTools) was my favorite GUI toolkit for any language, and I miss it. Once Qt was installed, it “just worked” on both Linux and OSX, and it made GUI apps very easy to write.

            Unfortunately, Qt4 is a hassle to work with nowadays, and there’s no plans (that I know of) to support Qt5 any time soon. I’ve looked into porting the libraries over myself a couple of times, but it’s pretty complicated and there were some changes on the Qt side that made it even more so.

            1. 1

              This probably isn’t the best time to get invested in Qt4, since KDE is doing a bunch of work on getting ready for a Qt6 migration (!!).

              1. 1

                Yes, I know. That’s why it was my favorite. LIke I said, Qt4 is difficult to use now so it’s not an option until the wrappers support a newer version of Qt.

                I’m not using KDE, though, so I don’t care which one they move to.

              2. 1

                Thanks for the feedback. A difficulty I have with Qtools is that it seems to not be very well discoverable: when I try to code-complete widget names, like (q+:label<TAB>), I get weird results. Maybe I missed something here.

                1. 1

                  I don’t remember that, but it’s been a while since I’ve used it.

                  Unfortunately, trying to load the package just now on FreeBSD is giving “Error opening shared object “…qtlibs!smokebase.so: program header too large.”

                  I’ll boot up my Linux system this evening and see if I get the same problem.

              1. 6

                I think there are some native toolkits as well like McCLIM.

                1. 2

                  There are, such as McCLIM and Garnet. McCLIM got an experiment working in the browser with Gtk’s Broadway protocol, and Garnet has an ongoing interface on Gtk.

                  And there’s a new one in the works, Alloy, which can already be used in a game engine.

                  (this is present in the introduction)

                1. 1

                  Multiple results: this bugs me, it’s just returning a tuple (like in Python, it’s an implicit tuple). There’s another kind in Lisp. Here we have:

                  swap :: proc(x, y: int) -> (int, int) {
                      return y, x;
                  }
                  a, b := swap(1, 2);
                  fmt.println(a, b); // 2 1
                  

                  What if you refactor your code and swap now returns y, x, z? You must update all swap callers to receive three values.

                  In Lisp, say you return two results:

                  (defun swap (x y) (values y x))
                  

                  by using the usual let and set macros, you get the first value, only y:

                  (setf val (swap x y)) ;; val -> y
                  

                  if you want to catch the second return value, you explicitely ask for it. In CL:

                  (multiple-value-bind (val-y val-x) (swap x y)
                     …)
                  

                  or (nth-value 2 (swap…)).

                  We can imagine the following to be equivalent:

                  a := swap(1, 2) // works

                  and

                  a, b := swap(1, 2) // still works

                  that’s all :)

                  1. 1

                    An early observation and good news is that the respondents are pretty young (25-35 and 35-45 each 30%)

                    1. 4

                      About editors: Atom with the SLIMA extension is nearly as good as Slime. It has the most importants bits: interactive debugger, good REPL interaction, etc.

                      1. 2

                        Does Atom have something like paredit/smartparens/lispy for structural editing of S-expressions?

                        1. 1

                          IUP is a good option: https://www.tecgraf.puc-rio.br/iup/ It wraps over Gtk+/Qt/Cocoa, it has bindings to many languages (core in C), it has a small API which makes it easy to learn (message-passing-like instead of lots of methods), it has a lot of widgets (but I missed one: a tree table with columns), it has ongoing work for iOs and WebAssembly.

                          1. 4

                            Common Lisp, because it has the fastest write-test cycle I know of, while still giving lots of compilation warnings (when we compile one function with a keystroke), it has more libraries than you think, I love the comfy and consistent syntax, and we can build executables. I wouldn’t go with Python anymore, I am not happy with the development workflow, the type checking and the deployment story (specially if I want to deploy a fleet of apps). I am lurking into other languages, but they always miss something CL has :] Oh, and I really want to try the hot reload capacity. I must be great for small updates. With Python if I want to deploy a quickfix it impacts the app’s availability (by not much, but users still face a buggy app for a couple of minutes).

                            1. 5

                              To dive int CL, my preferred links:

                              1. 6

                                Wow this is really incredible. Makes me want to learn Racket.

                                MUST… RESIST… URGE TO CHASE BRIGHT SHINY!!!

                                :)

                                Years from now when I reach near Expert level Python Racket or Clojure are definitely my next language choice.

                                1. 7

                                  Check out https://beautifulracket.com/ you might like it.

                                  1. 7

                                    NOOOOOO ahem Thanks :) I filed that away for a time when I can use it guilt free :)

                                    I know being LASER focused and not branching out at all seems counter-intuitive in this polyglot world of 2019 but I spent years mastering NOTHING and as such my core skills never got to where they needed to be. My rigid blinders around anything non Python have paid off in a huge way already so I’m sticking with it for the nonce :)

                                  2. 1

                                    it’s a really pleasant language! i highly recommend it. in particular, if you ever want to develop a small cross-platform gui app with high developer productivity it’s one of the best tools i’ve found for the job.

                                    1. 3

                                      When you say small GUI are there patent limitations? (lack of useful widgets?)

                                      1. 1

                                        it doesn’t have as much in the way of widgets as e.g. qt does, though it has all the standard ones and a canvas so you can make your own. another drawback is that there aren’t that many people writing gui apps in it, so even though it is relatively straightforward to create custom widgets, in practice there is a poor specialised widget ecosystem (e.g. there’s a map widget because someone made one, but i couldn’t find a date picker/calendar widget in a brief search).

                                        it also suffers from a lack of niceties like theming, and misses features like accessibility and internationalisation. see this bug for more. the gui framework was largely developed to build the drracket ide, and that tends to show in a lot of places.

                                        on the other hand it really does make it easy to write a quick gui app for some small, specialised task. the main hurdle again is that there are not many tutorials and examples out there, so getting started can be a bit slow, but once you get familiar with the basic gui framework it’s a pleasure to use. and it has some surprising widgets, such as a hypertext widget where the links call back into racket code, and a 3d renderer.

                                        1. 1

                                          Thanks! It’s exactly what I thought about Ltk (I’m turning to the IUP bindings now).

                                          1. 1

                                            from racket? i think i tried once and had trouble getting them working; if you can’t then the chicken scheme binding is well worth checking out.

                                            1. 1

                                              hey sorry, no I tested the Common Lisp bindings (ltk and IUP).

                                      2. 2

                                        Racket seems rather unique in that it’s a Scheme with an unusual bent towards solving real world problems, and it seems to have a really vibrant community of people doing just that and providing a really solid and diverse library ecosystem.

                                        I look forward to learning it… In the future :)

                                    1. 1

                                      The worst is that traumatic changes in python (and nearly any other language) will appear again… my alternative is a lisp language. You can add any language feature you want with the same syntax. And in the case of CL, you can even program the syntax reader: you can make that in your source files, { } will denote a dictionary, use @-decorators, etc. Without ever waiting a language update, or breaking existing libraries. CL is famous for its stability. Code written in the 90s (and probably before) can still run as is.

                                      Then, async support depends on the implementations. That’s what is possible in CL: https://github.com/CodyReichert/awesome-cl#parallelism-and-concurrency

                                      1. 3

                                        In my opinion CL avoids thos problem in the worst way possible: no code is actually idiomatic in the ecosystem. It can be idiomatic within a project, but between projects, taking a piece of code from one and putting it into another will result in code that is not idiomatic for one project, but is for the other.

                                        1. 2

                                          I don’t understand. We don’t copy&paste code from one project to another. The ecosystem is actually pretty conservative. And if we use features from other libraries, it’s like importing a library of pattern matching of futures into python: not idiomatic, just incorporated into your project for your own use.

                                          1. 2

                                            We don’t copy&paste code from one project to another.

                                            Yes, that is the consequence of the choices LISP makes. I argue it’s a bad thing. You need to learn what is idiomatic for every project if you want to contribute to it. Meanwhile in Python, or Go, or C, or almost any other language if you know what is idiomatic within a language, you know what is idiomatic within a project. This reduces the initial thinking overhead for new contributors and allows to easily reuse solutions from other projects in yours. When understanding what it does, copy-pasting code is one of the more powerful tools in programmer’s toolbox.

                                            1. 1

                                              well even in Python I don’t copy and paste code so we’ll have a short discussion. But regarding lisp, once again the community is quite conservative meaning you don’t encounter crazy new languages atop of it, then looking at the imported libraries one has to learn what they do anyway, exactly like in Python.

                                      1. 2

                                        This article sort of touches on why I am mostly allergic to javascript. It’s not my primary or even secondary language and the ecosystem changes so fast that it’s a full-time job trying to just keep up with what is idiomatic. I guess it’s not the javascript language itself that is the issue. It’s more the libraries and tooling that create this problem.

                                        1. 1

                                          Nah, I disagree. Evolving syntax and other (missing) languages features are part of the problem. Lisp languages avoid those trauma…

                                        1. 4

                                          For the emacs-y browser, there is/will be the Next browser :)

                                          1. 14

                                            I don’t like the direction he wants to go with HTML and web integration. If I want webmail and web chat and perfect HTML rendering, I’ll open my browser. I don’t think the core of Emacs should be bogged down with a browser engine. I understand that some people want to use Emacs for everything, but at the end of the day it is supposed to be a text editor and not a web browser.

                                            It’s easy enough to say “Just turn it off”, but it’s bound to be a security mess, bloat the memory use, and make the code base even more complicated, so there are side effects even for people who don’t want these features.

                                            1. 13

                                              at the end of the day it is supposed to be a text editor and not a web browser.

                                              It’s supposed to be an operating system; more of a Lisp Machine refugee camp, making do with what’s available on Unix.

                                              1. 2

                                                Maybe, but the modern web is a product of Unix, continued on with technical compromises and consumer friendliness. If Emacs were to become a text browser, sure I would not have to leave Emacs anymore, but the product would really not be the computational environment built on free software any more – rather it would just be reduced to another, probably sub-par browser.

                                                1. 2

                                                  Done right, I think that it would very much not be just another browser, and done right it need not be sub-par. I can easily imagine a Lisp-extensible editor with enough knowledge of HTML, JavaScript and CSS to be indistinguishable from Firefox or Chrome.

                                                  What I can’t easily imagine is the FSF, GNU or the Emacs project itself having the resources to build such a thing. And sadly, no-one with those resources cares enough about Lisp or Emacs to do it either.

                                                  1. 1

                                                    I can easily imagine a Lisp-extensible editor with enough knowledge of HTML, JavaScript and CSS to be indistinguishable from Firefox or Chrome.

                                                    If it’s indistinguishable, what’s the point?

                                                2. 1

                                                  Guixsd already exists, and uses a better lisp!

                                                3. 4

                                                  I don’t think the core of Emacs should be bogged down with a browser engine.

                                                  Emacs already has a web browser and if you haven’t noticed it by now then I doubt a new one getting added is going to bogg anything you already use down.

                                                  1. 3

                                                    I know, and I use it almost every day. I have it set as my default browser in Emacs. I use it to open Org mode web links, browse documentation, do web searches/research while working, and occassionally use github and sourcehut. It’s nice because I can avoid the distraction of Slack, email, Lobste.rs, and the rest of the web.

                                                    I guess my argument is that Eww already supports the right amount of HTML for a browser embedded in a text editor. Obviously, very much IMO.

                                                  1. 10

                                                    The article matches my experience. Python was my favorite language because [I thought] it had great support for interactive programming, which is the style I’m more comfortable with. After learning CL I know longer think that is true. Python is another batch-oriented ‘dead’ language to me. (And TDD at least allows me to treat it as a zombie ^_^)

                                                    A minor nit about the hype epilogue

                                                    JavaScript was written in CL!

                                                    It is incorrect or at least overselling it. Mozilla had a CL prototype of ES4 iirc, but it was never shipped. Although there is a JavaScript implementation in CL by the author of code mirror: http://marijnhaverbeke.nl/cl-javascript/.

                                                    The C# garbage collector was prototype in CL though!

                                                    About iterators, although as the article mentions there are libraries that implement them, in practice (loop :for ... := ...) does the job.

                                                    1. 1

                                                      Hey, I found the links back: https://jorgetavares.com/2010/05/19/original-implementation-of-javascript-in-cl/

                                                      “js/semantics contains experimental code used to generate LR(1) and LALR(1) grammars for JavaScript as well as compile and check formal semantics for JavaScript. The semantics can be executed directly or printed into either HTML or Microsoft Word RTF formats. This code is written in standard Common Lisp. It’s been used under Macintosh Common Lisp 4.0, and Allegro Common Lisp 5.0.1 for Windows, but should also work under other Common Lisp implementations.”

                                                      We still can see sources: https://dxr.mozilla.org/mozilla/source/js2/semantics/

                                                      (taking notes here: https://github.com/vindarel/list-of-languages-implemented-in-lisp/tree/master#javascript)

                                                    1. 4

                                                      I’m improving my bookshops management software (here), and dealing with a lot of technical debt :S (Python2 and Angularjs 1.x…) I’m getting my feet wet for a rewrite in Common Lisp. Currently the very basics work in a readline interface (a handy one, with autocompletion for everything). I didn’t decide on the web frontend yet… I’m productive in Vue, but my dream would be to use Weblocks (it’s seeing a rewrite since a couple years), but I must complete the documentation myself (coming soon: routing). I’d like a simple GUI too. Probably with the IUP bindings.

                                                      I’m also trying out isomorphic web frameworks. Last in date: Hyperstack (Ruby & React), but the installation instructions failed for me. I’ll have a look at Rust’s seed-rs, but they all are alpha… I have a little list here. I welcome any feedback. Can we write isomorphic webapps today?