3 ms·

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

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

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