I’d guess that in the end, CL shouldn’t be seen as a functional language, since Lisp wasn’t even originally conceived as functional language.

There’s a page which I can’t find now which makes the case that the term “functional programming language” evolves over time to mean “the most functional programming language which currently exists”, so different features rotate in and out of defining what it effectively means to be a functional programming language.

(I’d add that each generation has a different boogeyman idea, an idea which the Average Programmer regards as being “too complex” and which others write blog posts or the local equivalent to explain.)

The first generation was when Algol introduced recursion. Recursion is also the boogeyman idea of this era.

The second generation begins with “mature” Lisp (that is, Lisp implementations like MACLISP and Lisp Machine Lisps, not LISP 1.5) and, later, Scheme, where the defining feature is first-class functions and closures, and the boogeyman idea is Scheme’s continuations. Common features are strong dynamic typing and a universal feature is garbage collection. The new-school scripting languages (Perl, Python, Ruby) are languages of this type with object systems bolted on, and Java’s getting there, slowly.

(Some pre-Common Lisp Lisps didn’t have closures. They had the upwards funarg problem, instead.)

The third generation is ML and everything after, including OCaml and Haskell. Now, functional programming includes strong, static type systems with algebraic types, Hindley-Milner type inference, and, at a syntactic level, pattern-matching as flow control. The boogeyman idea is monads, and, more specifically, requiring the use of monads to mark out side-effecting code, as Haskell does.

The underlying point is that “Functional programming is whatever your language of choice doesn’t have yet”: Recursion is now universal. It wasn’t when FORTRAN IV was “your language of choice” for a lot of programmers. Strong dynamic typing and garbage collection aren’t universal, but they’re not weird and wacky ideas only long-haired MIT AI Lab types can make sense of. Marking your side-effecting code in a machine-readable way is still weird and wacky… for now.

I wonder why backwards compatibility was a concern if CL could not run any of that old code unmodified. Ot could it?

Yeah, I guess it’s my expecation that the language is supposed to be functional that makes lisp-2 look so disappointing for me. It technically has everything for FP to work, so I feel cheated. ;)

Taking a minimal fixed image as the base for building and paying some attention to what is being downloaded from where is much more closer to reproducible builds than building a package on a continuously changing traditional system with lots and lots of libraries and admin/user activity.

When you start nailing versions of OS and every library to build a reproducible image, soon you will be down to managing many virtual machines, and at some point plain containerization of builds makes more sense.

In Coq, the Fixpoint construct can encode bounded recursion and it is checked for termination: termination must be either inferred or proved. Termination check is easy for structural recursion over inductive types, including Peano-encoded numbers (just iterate until it’s exhausted), but for the Euclid algorithm it’s not obvious: the Euclid algorithm is guaranteed to terminate, but it’s not structurally obvious and requires a number-theoretical proof.

Coq uses a small set of conservative, syntactic criteria to check termination of all recursive definitions. These criteria are insufficient to support the natural encodings of a variety of important programming idioms. [0]

[0] http://adam.chlipala.net/cpdt/html/GeneralRec.html

as much as off-topic as any article about Facebook and Cambridge Analytica, isn’t it?

– yes, exactly, I don’t want politics (even if it’s web-related) here, Lobsters is a technical place for me and I don’t want it to lose focus, which is very easy with politics-related discussions (everybody always has something to say about politics, including me). If I want to read yet another heated (and completely pointless) political discussion, I can go to HN.

The topic of the article is related to web only tangentially (using web as an excuse to talk about geopolitics), and labels networking and finance are completely misleading here.

P.S. Thanks for the reminder, I went through recent stories about Facebook/CA and hid those too.

Also, it’s as much as off-topic as any article about Facebook and Cambridge Analytica, isn’t it?

Indeed! And those get flagged mercilessly as well.

On hn, the author of the article mentions about he’s far more interested in a good way of expressing set operations and business rules in those terms, rather than writing a high performance array processing language for Erlang.

Hmm well this is what I got, which is pretty incomprehensible to someone starting out with haskell I think.

<interactive>:4:1: error:
    • No instance for (Foldable ((,,) t0 t1))
        arising from a use of ‘length’
    • In the expression: length (1, 2, 3)
      In an equation for ‘it’: it = length (1, 2, 3)
<interactive>:4:9: error:
    • Ambiguous type variable ‘t0’ arising from the literal ‘1’
      prevents the constraint ‘(Num t0)’ from being solved.
      Probable fix: use a type annotation to specify what ‘t0’ should be.
      These potential instances exist:
        instance Num Integer -- Defined in ‘GHC.Num’
        instance Num Double -- Defined in ‘GHC.Float’
        instance Num Float -- Defined in ‘GHC.Float’
        ...plus two others
        ...plus three instances involving out-of-scope types
        (use -fprint-potential-instances to see them all)
    • In the expression: 1
      In the first argument of ‘length’, namely ‘(1, 2, 3)’
      In the expression: length (1, 2, 3)
<interactive>:4:11: error:
    • Ambiguous type variable ‘t1’ arising from the literal ‘2’
      prevents the constraint ‘(Num t1)’ from being solved.
      Probable fix: use a type annotation to specify what ‘t1’ should be.
      These potential instances exist:
        instance Num Integer -- Defined in ‘GHC.Num’
        instance Num Double -- Defined in ‘GHC.Float’
        instance Num Float -- Defined in ‘GHC.Float’
        ...plus two others
        ...plus three instances involving out-of-scope types
        (use -fprint-potential-instances to see them all)
    • In the expression: 2
      In the first argument of ‘length’, namely ‘(1, 2, 3)’
      In the expression: length (1, 2, 3)

For someone new to Haskell, the notion that – were you to invest the time to learn, this would be a readable message – is hard to fathom. I think that sort of imagination barrier is why generally things with steep learning curves are less popular.

Precisely because of the lack of GC and the focus on lifetimes, Rust is much more similar to (modern) C++ than D will ever be. Writing Rust is like writing correctly written C++.

D, having a GC, leads to different programs (than C++ or Rust) because of this global owner for resources that are only memory. eg: slices have no ownership information in the type system. This makes scripting very friction-less, at the cost of some more problems with non-memory resources. But not at the cost of speed.

D has @safe which is machine-checked, opt-in memory safety.

I agree with all those points.

I was more thinking about folks skipping over D in the past, and how that potentially limited its uptake, than from the perspective of a D programmer looking at the current popular trends. Certainly an interesting perspective though. Thanks for sharing!

I think it should go back to its roots, which is why I happen to like it: “D: the C++ you always wanted.”

You two must be incredibly skilled if you can wade through spaghetti code (at least the kind I have encountered in my admittedly meager experience) and prefer it to helper function calls. I very much prefer being able to consider a single small issue in isolation, which is what I tend to use helper functions for.

However, a middle ground does exist, namely using scoping blocks to separate out code that does a single step in a longer algorithm. It has some great advantages: it doesn’t pollute the available names in the surrounding function as badly, and if turned into an inline function can be invoked at different stages in the larger function if need be.

The best example of this I can think of is Jonathan Blow’s Jai language. It allows many incremental differences between “scope delimited block” and “full function”, including a block with arguments that can’t implicitly access variables outside of the block. It sounds like a great solution to both the difficulty of finding where a function is declared and the difficulty in thinking about an isolated task at a time.

A lot of code nowadays (looking at you, Haskell, Rust, and most of the trendy JS frontend stuff that’s in vogue) basically assumes you have a lot of tooling handy, and that you’d never deign to do something as simple as adding a quick patch

I do quick patches in Haskell all the time.

I’ve seen bad code with too many small functions and bad code with god functions. I agree that conventional wisdom (especially in the Java community) pushes people towards too many small functions at this point. By the way, John Carmack discusses this in an old email about functional programming stuff.

Another thought: tooling can affect style preferences. When I was doing a lot of Python, I noticed that I could sometimes tell whether someone used IntelliJ (an IDE) or a bare bones text editor based on how they structured their code. IDE people tended (not an iron law by any means) towards more, smaller files, which I hypothesized was a result of being able to go-to definition more easily. Vim / Emacs people tended instead to lump things into a single file, probably because both editors make scrolling to lines so easy. Relating this back to Java, it’s possible that everyone (with a few exceptions) in Java land using heavyweight IDEs (and also because Java requires one-class-per-file), there’s a bias towards smaller files.

Storing our code in files is a vestige of the 20th century. There’s no good reason that code needs to be organized into text files in directories. What we need is a uniform API for exploring the code. Files in a directory hierarchy is merely one possible way to do this. It happens to be a very familiar and widespread one but by no means the only viable one. Compilers generally just parse all those text files into a single Abstract Syntax Tree anyway. We could just store that on disk as a single structured binary file with a library for reading and modifying it.

True, but does it make sense to link to a byte position within an image or binary? In the latter case, perhaps — but might it not also make more sense to link to a character within the display version of the binary?

Yup!

Take care if you use hugo, the default rss template does not render the full article.

Here’s a modified one that renders the full article in the feed:

<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>{{ .Title}} </title>
    <link>{{ .Permalink }}</link>
    <description>Recent posts</description>
    <generator>Hugo -- gohugo.io</generator>{{ with .Site.LanguageCode }}
    <language>{{.}}</language>{{end}}{{ with .Site.Author.email }}
    <managingEditor>{{.}}{{ with $.Site.Author.name }} ({{.}}){{end}}</managingEditor>{{end}}{{ with .Site.Author.email }}
    <webMaster>{{.}}{{ with $.Site.Author.name }} ({{.}}){{end}}</webMaster>{{end}}{{ with .Site.Copyright }}
    <copyright>{{.}}</copyright>{{end}}{{ if not .Date.IsZero }}
    <lastBuildDate>{{ .Date.Format "Mon, 02 Jan 2006 15:04:05 -0700" | safeHTML }}</lastBuildDate>{{ end }}
    {{ with .OutputFormats.Get "RSS" }}
        {{ printf "<atom:link href=%q rel=\"self\" type=%q />" .Permalink .MediaType | safeHTML }}
    {{ end }}
    {{ range .Data.Pages }}
    <item>
      <title>{{ .Title }}</title>
      <link>{{ .Permalink }}</link>
      <pubDate>{{ .Date.Format "Mon, 02 Jan 2006 15:04:05 -0700" | safeHTML }}</pubDate>
      {{ with .Site.Author.email }}<author>{{.}}{{ with $.Site.Author.name }} ({{.}}){{end}}</author>{{end}}
      <guid>{{ .Permalink }}</guid>
      <description>{{ .Content | html }}</description>
    </item>
    {{ end }}
  </channel>
</rss>

I probably should have included that in the article… Too late now.

Blogs should just be an XSLT transform applied to RSS ;)

Weirdly, though, that all comes down to the good design of Firefox reader mode :D.