3 ms·

I have always thought that the hardware was responsible for the creation of each programming language. Well, not entirely, but a large part of the reason was th

I have always thought that the hardware was responsible for the creation of each programming language. Well, not entirely, but a large part of the reason was the hardware and the new or different capabilities of the moment.

KMag 6y ago
Hardware was certainly the reason for the development of new assembly languages, and for the creation of niche languages for niche hardware (such as CUDA and OpenCL for GPUs). However, I don't see new hardware as being the impetus for the creation of any of the most popular languages of today. Do you mind elaborating on which languages you think arose due to which hardware capabilities?
- meerita 6y ago
  What I've meant it was my bias. I thought it were mainly the hardware components who drived the creation of most languages, but, well, Javascript wasn't created using this criteria :)
  - KMag 6y ago
    C was explicitly created as a portable assembly language to avoid re-porting the Unix kernel in assembly yet again. C++ was intended to be hardware-independent. Java is even more intentionally and explicitly hardware-independent. Early Python was POSIX-centric, but not hardware-centric. There were Lisp machines by Symbolics, LMI, and others, but in these cases the hardware was bent to the language instead of the language to the hardware. Common Lisp and Scheme are intentionally hardware-independent. I think Cray had a Fortran dialect that exposed vector operations, but I'm not sure how many people would consider that a new language. I think programmer ergonomics/productivity and program correctness/safety are the two most common drivers for new (non-hobby) language creation, where the former is often expressed as a matter of taste/preference. (I suspect personal hobby languages far outnumber other languages, but we have no way of knowing how many of these exist.)
    - meerita 6y ago
      That's amazing. And what about functional languages?
      - KMag 6y ago
        I've seen several definitions of functional languages, but I presume you're talking about languages that encourage the use of pure functions and immutable data structures. I think the driver there is that it's much easier to reason about (and prove properties of) pure functions. At first glance, that seems pretty clearly a correctness driver. Some strong proponents of functional languages would argue that bugs are a huge detriment to programmer ergonomics, so correctness also ends up being an ergonomic issue. On the other hand, people with lots of experience programming in imperative styles that encourage mutable state (such as many classical object oriented styles) find it uncomfortable to switch over to a functional style. (I realize some languages, such as Scala, encourage a fusion of OO and functional styles, but mutable state played a big role in classical OO languages. For instance, Java missed a big opportunity by having the Map and List interfaces expose mutator methods instead of having MutableMap and MutableList interfaces that extend mutator-less base interfaces. In Java, immutable maps and lists usually end up implementing the Map and List interfaces, but having the mutators always throw exceptions. If you find implementors of your interfaces regularly subvert the contract you try to establish in this way, you've probably made a mistake in defining your interface.)
- jerome-jh 6y ago
  There is some truth in OP: https://queue.acm.org/detail.cfm?id=3212479 https://queue.acm.org/detail.cfm?id=3212479 https://en.wikipedia.org/wiki/CAR_and_CDR https://en.wikipedia.org/wiki/CAR_and_CDR Then Java was created as a way to waive C++ cumbersome dynamic dispatch, because high end hardware of that time could handle it performance wise. Then a huge number of scripting languages appeared basically saying: "let's do everything at runtime!". There is another trend where correctness is the driving factor (Haskell, Rust). Proving correctness on large programs tends to be CPU/memory intensive, so in a sense that trend is also enabled by hardware.
- langitbiru 6y ago
  Blockchain gave birth to at least 2 programming languages: Solidity and Vyper. Not sure though we can categorize blockchain as hardware or not.
  - KMag 6y ago
    > Not sure though we can categorize blockchain as hardware or not. I think in this sense, blockchains would be VMs, not hardware. Though, like the JVM, it would be possible to make a hardware (and presumably firmware) implementation of the VM.

KMag 6y ago

Hardware was certainly the reason for the development of new assembly languages, and for the creation of niche languages for niche hardware (such as CUDA and OpenCL for GPUs). However, I don't see new hardware as being the impetus for the creation of any of the most popular languages of today. Do you mind elaborating on which languages you think arose due to which hardware capabilities?

meerita 6y ago
What I've meant it was my bias. I thought it were mainly the hardware components who drived the creation of most languages, but, well, Javascript wasn't created using this criteria :)
- KMag 6y ago
  C was explicitly created as a portable assembly language to avoid re-porting the Unix kernel in assembly yet again. C++ was intended to be hardware-independent. Java is even more intentionally and explicitly hardware-independent. Early Python was POSIX-centric, but not hardware-centric. There were Lisp machines by Symbolics, LMI, and others, but in these cases the hardware was bent to the language instead of the language to the hardware. Common Lisp and Scheme are intentionally hardware-independent. I think Cray had a Fortran dialect that exposed vector operations, but I'm not sure how many people would consider that a new language. I think programmer ergonomics/productivity and program correctness/safety are the two most common drivers for new (non-hobby) language creation, where the former is often expressed as a matter of taste/preference. (I suspect personal hobby languages far outnumber other languages, but we have no way of knowing how many of these exist.)
  - meerita 6y ago
    That's amazing. And what about functional languages?
    - KMag 6y ago
      I've seen several definitions of functional languages, but I presume you're talking about languages that encourage the use of pure functions and immutable data structures. I think the driver there is that it's much easier to reason about (and prove properties of) pure functions. At first glance, that seems pretty clearly a correctness driver. Some strong proponents of functional languages would argue that bugs are a huge detriment to programmer ergonomics, so correctness also ends up being an ergonomic issue. On the other hand, people with lots of experience programming in imperative styles that encourage mutable state (such as many classical object oriented styles) find it uncomfortable to switch over to a functional style. (I realize some languages, such as Scala, encourage a fusion of OO and functional styles, but mutable state played a big role in classical OO languages. For instance, Java missed a big opportunity by having the Map and List interfaces expose mutator methods instead of having MutableMap and MutableList interfaces that extend mutator-less base interfaces. In Java, immutable maps and lists usually end up implementing the Map and List interfaces, but having the mutators always throw exceptions. If you find implementors of your interfaces regularly subvert the contract you try to establish in this way, you've probably made a mistake in defining your interface.)
jerome-jh 6y ago
There is some truth in OP: https://queue.acm.org/detail.cfm?id=3212479 https://queue.acm.org/detail.cfm?id=3212479 https://en.wikipedia.org/wiki/CAR_and_CDR https://en.wikipedia.org/wiki/CAR_and_CDR Then Java was created as a way to waive C++ cumbersome dynamic dispatch, because high end hardware of that time could handle it performance wise. Then a huge number of scripting languages appeared basically saying: "let's do everything at runtime!". There is another trend where correctness is the driving factor (Haskell, Rust). Proving correctness on large programs tends to be CPU/memory intensive, so in a sense that trend is also enabled by hardware.
langitbiru 6y ago
Blockchain gave birth to at least 2 programming languages: Solidity and Vyper. Not sure though we can categorize blockchain as hardware or not.
- KMag 6y ago
  > Not sure though we can categorize blockchain as hardware or not. I think in this sense, blockchains would be VMs, not hardware. Though, like the JVM, it would be possible to make a hardware (and presumably firmware) implementation of the VM.