Comment by hazelnut-tree | Hacker News Reader

Comment by hazelnut-tree | Hacker News Reader

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.

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

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

Reply on news.ycombinator.com