This excellent and stimulating talk (including slides) examines four programming languages from the 1970s:

- SQL

- Prolog

- ML (Meta Language)

- Smalltalk

- A surprise bonus language revealed near the end of the talk

Presentation description:

"The 1970’s were a golden age for new programming languages, but do they have any relevance to programming today? Can we still learn from them?"

"In this talk, we’ll look at four languages designed over forty years ago — SQL, Prolog, ML, and Smalltalk — and discuss their philosophy and approach to programming, which is very different from most popular languages today."

Some quotes from the talk:

"So what can we learn from the 1970s? Some interesting things that we haven't really caught up [today]...Pretty much everything that we can think of as modern programming happened in the 1970s"

The following programming paradigms stabilised by the early-1980s: Imperative, Object-oriented, Functional, Symbolic, Logic, Stack-based:

"What's interesting is all these paradigms really solidified by the late 70s and early 80s, and these are the paradigms we still use today. We really haven't progressed that much."

Probably the biggest difference today is that everything needs to have some compatibility layer with C and/or C++ or else it's basically nonviable.

Having a compatibility layer with C doesn't impact your language design, and depending on how 'complete' you want that compatibility it doesn't have to be a lot of effort. Interestingly I think all high-level languages have had to deal with this, I don't think it's new. The very old FORTRAN manuals would all describe how to include assembly functions. Lots of old C content would explain how to use Fortran functions with your work, or how to use C with different system languages for mainframes.

Looking at the complete programming language landscape, Fortran, C, and assembly are relatively similar.

If you have garbage collection (more so for GC that moves objects around), lazy sequences, strings that aren’t byte sequences terminated by zeroes, etc. your C compatibility layer will have warts.

If you really need to call C, and want that to be performant, that may limit your design options. Python is a clear example.

That issue applies to anything 'managed', and applies between managed languages as well (actually more so, have fun interfacing between two different GC systems). The compatibility layer can be a bit warty, but does it matter? We just want the ability to use libraries/interfaces we find useful. I don't think this is unique to C, and frankly I think C has some of the easier ABIs to get basic interfacing with. What language can't talk in arrays and numbers?

Numbers aren’t as easy as one would think because of the size of integers and endianness. Also, some languages need to convert their dynamically sized integers to 32- or 64-bit C integers.

For arrays, multi-dimensional ones are tricky, as is returning them from calls.

And then, there’s structure, with C’s insistence that fields in a structure get stored in declaration order and structure padding.

> We really haven’t progressed that much.

Have related fields like, say, Mathematics changed a great deal since then?

Maybe not, but a lot of programming related stuff is actually regression, usually change for change's sake with a snuff of NIH thrown in for good measure.

In math it moves monotonically upwards, slowly but steadily.

No, but mathematicians don’t come up a new notation every three months that they promise will revolutionise the field.

A semi related video about the relationship between mathematics and computer science

https://www.youtube.com/watch?v=IOiZatlZtGU "Propositions as Types" by Philip Wadler

As an EE undergrad 40 years ago, the title made me think of the programming languages taught in my courses at the time.

- FORTRAN (no surprise here, I was an EE major not CS)

- Pascal (this was the new kid on campus at the time, only the CS folks used it)

- MIX (Knuth's generic assembly language)

FWIW I was an EE/Math undergrad 45 years ago and ours were

- FORTRAN (heavy on the numerical methods)

- MIX (only in a side project)

- PL/C (a really nifty "training wheels" version of PL/1)

- BASIC (on a PDP-series computer with a room full of ASR-33's)

I remember in 1970 I was kicked out of some job and ended in advising total novices in BASIC programming. One older man had problem:

    "A=B+13 ei pysy samana". (= Does not stay the same) 

After some pondering I realized that this man did not see the program as sequence of actions, but statements of relations and truths, which computer magically solves.

Very interesting idea, could this be more natural way of programming? But then I found MuMath from some BBS, and realized this new programming language of mine was just extended equation solver.

there's an entire field of programming languages which work just like that. One of the most mainstream ones is Qt's QML: https://www.qt.io/product/qt6/qml-book/ch04-qmlstart-qml-syn...

Here's a trivial example:

    Column {
        Dial {
            id: dial
            from: 10
            to: 100
            value: 30
        }
        
        Text {
            text: (dial.value * 100) + "°C"
            font.pointSize: dial.value
        }
    }

whenever the slider's value changes, all the properties of the text are automatically updated. Live demo: https://tinyurl.com/2p5z5ufc

Functional programming languages often work that way. E.g., in Erlang, if you've already bound a variable X to a value, and want to compute another value of X, you cannot use the same variable name - you have to use X2 or something else.

Scott has some of the best videos and writing on programming out there. This talk[0] (the programmers toolkit) is one of my favorites and is something that you can keep coming back to regardless of experience or background.

[0] https://m.youtube.com/watch?v=bK-Tz-GLfOs

I've just started learning Elixir very recently after nearly 23 years of working solely with languages such as VB, C, C#, Ruby, Python, Javascript, and Go.

I know exactly what the presenter means when he says learning a language should be a "mind-blown" event. It's opening my eyes to an entirely new way of thinking about solving challenges. Absolutely love it, and I feel like I did myself a serious disservice for not learning something like Elixir or Erlang earlier in my career as opposed to always learning just another new imperative language.

I was lucky enough to have learned Erlang in college and I had a similar "mind-blown" experience right in the middle of the lecture hall.

When I use most other languages ever since, there's always a part of me that knows this little piece of the program could be that much more elegant and robust in Erlang...

I found Scala functional programming to be my “mind blown” revelation after 15 years of software. I dislike the ecosystem and the build system but I sure loved the language.

I was hoping for Eiffel, but alas