amno

I don't understand this argument: "it's 47 years old" as a bad thing. If something has been around that long, does it not mean it is proof tested?

The syntax of Taskfile looks more verbose to me than Makefile, which is basically a shell script in disguise. To note also is that you praise Devenv because of it being based on Guix (Guile scheme), while you ditch Makefile which also embeds Guile scheme as the extension language (in latest versions).

Also to note, the opening argument, writing Readme files on how to build and use the software, has nothing to do with Makefiles at all. You could write a simple skeleton codegen that generates a Readme file skeleton or a template with those steps autogenerated in any language preferred, shell included, and run it as a Makefile target.

As long as you don't distribute it, you are OK.

Yeah, I have never seen it before, but I saw it yesterday, and it is easily the best talk on programming languages, and programming, I have ever seen.

I have posted it to /r/cpp and interestingly some mode removed it as C++ was only "briefly mentioned".

To me, it feels quite obvious that "modern C++" has taken a note from that talk, and its efforts seem to be towards what Steel describe there, as a big language that lets people the possibility to extend the language and look relatively the same as the native syntax via its new meta programming facilities. That talk also answers many complaints about C++ heard today of being large, hard, write-only etc.

Also, in the historical context, I think it is quite a peak towards Gosling & Co, and Java, which at the time was heavily marketed not seldom by shunning of some of the C++ features, notably operator overloading and multiple inheritance.

I don't think anything of this has with trunks or branches to do. I think all said arguments are equally valid for both types of CV systems. It really is a developers discipline that decides here. All this with CI, frequent merging etc are just as easy and possible with Git as well, especially since we got worktrees.

That was pretty much my first thought too when I was reading the article.

> Extreme terseness, even when done very elegantly, makes programs very hard to read and sometimes also hard to maintain.

I will definitely agree with you on this one. The tersness, which has many faces, is what I experience to be reason for "write-only" effect in Bash, Perl and now even C++. There, tersness come in form of trying to overload operators with lots of different meanings in different contects.

> I suspect that's one of the reasons Lisps (and functional languages in general) haven't caught up in popularity even as it becomes much easier to adopt one for any target and in any organization.

Here I believe you are perhaps wrong. I don't think Lisp is about tersness. In this case about control flow, on the contrary. Lisp was actually the language that introduced the 'if' and some other higher level constructs we take for granted today into the mainstream. Before McCarthy and Lisp there were no 'if' in any other programming language. Some Lisp(s) have do, while, cond, unless, when, and most importantly, the condition system, which is in a way, very close to the idea presented in the article.

Also note that some Lisp have rich facilities to extend the language itself, where the idea is that programmers should create abstractions to express progams in the problem domain, rather then use low-level language primitives. I am not so good at words, but I think Peter Norvig captures Lisp ideas very well in his Paradigms of AI book: https://norvig.github.io/paip-lisp/#/chapter3.

I wouldn't say that Lisp hasn't cought up. Lisp was very, very popular, at certain time, but has gone away. Perhaps Lisp was ahead of its time and had its own .COM crash. Or was it killed by big tech greed? I don't know, but many of Lisp ideas are in mainstream languages, it is just that they use different syntax and sometimes terminology.

Very similar could be said for functional languages too, Note as well that Lisp(s) are not necessarily functional programming languages. Many, if not all Lisps, do support functional paradigm, but they are (mostly?) procedural and some do support OOP too.

We are still early in our digital age as a civilization. If we think of the history of humanity, we have spent about 300 thousand years in the woods, and only last 10K years in urban settlements and for only about last 2.5K years do we seem to have developed science as a logical/mathematical discipline. Less than 100 years have we spend on programming languages theory.

I am quite sure we are still just testing our waters for the right direction. The only unfortunate thing with dying is to not be able to see how the civilization will look like in about a 1k or 10k years from now. Wonder how computers will look like and how programming languages would look like. The only thing I am sure about is that any guess I would make now would probably be wrong :).

Only to those that have a signed contract with YT, no?

> not to be Stallman's group of friends

Nobody said that, either.

> That he did a good job before doesn't mean there's not a job now that still needs doing well.

And you personally know he can't help doing this job further on, and he is on his own entire board in FSF? You are free to nominate and show the world what you can do!

President is Geoffrey Knauth; not RMS; you should have probably looked up the facts before sending unnecessary comment: https://www.fsf.org/about/staff-and-board

https://en.wikipedia.org/wiki/Geoffrey_Knauth

Nobody claims RMS should be president for life, or anyone else, I just dislike the rhetoric the Op uses.

> Social media is how a lot of political activism happens, for better and for worse. But as far as I'm aware the FSF does not have a presence here.

Indeed. People in the inner circle around RMS do not use social media. They are either genuinely uninterested, or for the political reason does not want to use anything that includes non-free JavaScript or other non-free technologies, where non-free is defined by the GNU project, i.e. the GPL compatible license.

> Now, let's contrast that to right-to-repair.

Because that is something that people can immediately "feel".

I believe people should become more aware that free software, or at least, open source software, is important for democracy and freedom. How can you ever have freedom if whomever wish can spy on you and control what you say? Can you have free elections if your vote is manipulated? How can you ever be sure if machines run closed source software only very few chosen ones have access to? How can you ever know what happens in the world and make informed decisions if there is no free information. Can we trust any information and software if it runs closed source binary blobs? I believe that the only way to solve this is to make laws that demand open source software to be used in software of public importance.

> What significant, tangible accomplishments does Stallmann have in the past 15 years?

You believe you will never grow old? Do you wish your family and friends to turn back on you because you are old and don't have the same energy as you had when you were 20? The question is how the landscape would look like today and if there even would be "open source" in the broader sense as we see it today, with permissive licenses, if it wasn't for him.

Sure, you can look at a person's mistakes only, but you could also look at all the good a person has done. Do you yourself ever do mistakes? You never made a bad decision in your entire life? C'mon. To err is human. How would world look like if everyone was thrown out from the job and the society when they do a mistake, and if everything in the world would be judged by mistakes and not by the value it adds. Reflect over yourself first, are you sure you are qualified to throw a rock?

Nice! My two-minute thought on your idea, I refactored your code somewhat:

    ;;; test.el ---                                      -*- lexical-binding: t; -*-

    Don't know if it's useful in practice, but if we had multiline comments, we
    could add invisible property on those markers to auto-hide them. Interlaced with
    Emacs Lisp code, it gives a "feel" of literate programming.

    (defun cursed-elisp-block-comment (beg end)
      (interactive "r")
      (save-excursion
        (let ((start (format "#@%d " (+ (- end beg) 2))))
          (goto-char end)
          (insert "\037")
          (put-text-property end (1+ end) 'invisible t)
          (goto-char beg)
          ;; account for space and terminator
          (insert start)
          (put-text-property beg (+ beg (length start)) 'invisible t))))

    (defun make-visible (beg end)
      (interactive "r")
      (remove-text-properties beg end '(invisible t)))

    This file is a little demo of the concept, but to actually be useful, there
    should probably be some routine to automatically mark text paragraphs with
    invisible markers, since it is a bit labourous to do it by hand for each
    paragraph. Surprisingly, indentation engine didn't complain at all, while
    font-lock of course does not know I am in a comment.

    (message "hello multiline comments")

    (provide 'test)
    ;;; test.el ends here

Above file evaled as emacs-lisp buffer:

https://postimg.cc/SnfNNfyh

Did you ever wondered where all those strange name in Lisp comes from? What is car and cdr, why they are called so, what makes Lisp so special, or why are so many parenthesis in Lisp code?

A Croatian professor, Kazimir Majorinc, decided to research the subject and the result is a beautiful and easy to digest book, Moćan koliko je god moguće, about early Lisp history and major ideas and concepts in early Lisp.

An English translation in working is now available on GitHub; you are free to read it and share it unmodified under the CC Attribute-No Derivatives license.

Language corrections are welcome, please read the Readme.org to see how to contribute.