4 ms·

This excellent and stimulating talk (including slides) examines four programming languages from the 1970s: - SQL - Prolog - ML (Meta Language) - Smalltalk

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."

criddell 4y ago
> We really haven’t progressed that much. Have related fields like, say, Mathematics changed a great deal since then?
- jacquesm 4y ago
  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.
- richardjam73 4y ago
  A semi related video about the relationship between mathematics and computer science https://www.youtube.com/watch?v=IOiZatlZtGU https://www.youtube.com/watch?v=IOiZatlZtGU "Propositions as Types" by Philip Wadler
- Ma8ee 4y ago
  No, but mathematicians don’t come up a new notation every three months that they promise will revolutionise the field.
duped 4y ago
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.
- veltas 4y ago
  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.
  - Someone 4y ago
    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.
    - veltas 4y ago
      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?
      - Someone 4y ago
        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.

criddell 4y ago

> We really haven’t progressed that much. Have related fields like, say, Mathematics changed a great deal since then?

jacquesm 4y ago
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.
richardjam73 4y ago
A semi related video about the relationship between mathematics and computer science https://www.youtube.com/watch?v=IOiZatlZtGU https://www.youtube.com/watch?v=IOiZatlZtGU "Propositions as Types" by Philip Wadler
Ma8ee 4y ago
No, but mathematicians don’t come up a new notation every three months that they promise will revolutionise the field.

duped 4y ago

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.

veltas 4y ago
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.
- Someone 4y ago
  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.
  - veltas 4y ago
    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?
    - Someone 4y ago
      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.