4 ms·

There’s some real gold in here: > Though it seems funny now to think that Scheme lexical environments were ever difficult to understand, you must take my word

There’s some real gold in here: > Though it seems funny now to think that Scheme lexical environments were ever difficult to understand, you must take my word that in 1976, people with PhDs in computer science required careful explanation with lots of examples to get it. In fact, many people — myself included — had to write lexical interpreters to understand the interactions that led to the external behavior, and understanding the interactions was required to get it. Nowadays lexical scope is the default, and dynamic scope is hard to explain to folks who don’t understand it yet. Makes you wonder how many hard problems would be easy with a different frame of reference. > Nevertheless, in 1980—to pick a round date—the AI folks and programming languages folks parted ways. And with their departure came programming language winter. Although I imagine that a lot of folks would strongly disagree, there is a very real sense in which programming languages haven’t really progressed since the early 80s. > These interpreters became Scheme, and from them they learned that function calling and message-passing were fundamentally the same, a lesson still not well and thoroughly learned today. Surprisingly, this still seems true a dozen years later.

bmitc 4y ago
Is dynamic scope hard to understand or be explained or isn't it just the case that most find it to be a terrible idea for general purpose software development?
- aardvark179 4y ago
  It does seem hard to explain to people, and although I agree it is not normally the right answer, it is often a better answer than simple thread local variables.
- eadmund 4y ago
  > Is dynamic scope hard to understand or be explained or isn't it just the case that most find it to be a terrible idea for general purpose software development? I think that dynamic scope is strictly better than global variables: all of its downsides are shared by globals, but it has the important advantage that a dynamic binding is scoped. Given that every popular language I am aware of supports globals in some form, I think that adopting dynamic scope would be an improvement. Even more interesting is to consider what would it would mean to replace global with dynamic scoping entirely. I don’t really know if that is possible or efficient, but it certainly is intriguing. Almost like dependency injection throughout the language. Kinda sorta kinda.
  - skybrian 4y ago
    I think Go's context objects serve a similar purpose to dynamic scope? https://pkg.go.dev/context https://pkg.go.dev/context It seems like pretty much anything that lets you pass in an environment as a function parameter would work.
    - agumonkey 4y ago
      I believe dynamic variables are reinvented every year. Even dependency injection seems like a sibling.
  - gpderetta 4y ago
    Implicit parameters seems to be the principled dynamic scoping for statically typed languages. Implicit parameters are in the list of must-have features for the programming language I'll never get around to implement.
  - samatman 4y ago
    This is effectively how globals are handled in Lua: they are first-class environments, ordinary tables which can be assigned to a function (5.1/LuaJIT) or upvalue (5.2+) to resolve globals. I like it a lot, it's a supplement to lexical scope: like ordinary globals it's a flat namespace 'behind' the locals, unlike many implementations of globals these environments are replaceable and (mostly) fungible.
- CoastalCoder 4y ago
  I'm surprised that dynamic vs. lexical scope is hard for seasoned programmers / computer-scientists to grasp. Maybe it's because the two concepts are inter-related during program execution? Similar to the way that latency vs. bandwidth can confuse some people, because they're inter-related in some circumstances but not others?
- slaymaker1907 4y ago
  It is definitely useful for things like semi-global options like a variable for the current stdout.
Banana699 4y ago
>there is a very real sense in which programming languages haven’t really progressed since the early 80s. Can this be made any more precise to somebody who doesn't share the feeling? As a programming language aficionado, my attitude is the exact opposite of this. 1980 is the debut of Smalltalk. Standardisation of CommonLisp happened sometimes in the mid 1980s. The 1990s is the "Interpreters Renaissance", when Python and Ruby (and other less elegant siblings) came out, as well as the JVM and the proto-beginnings of the CLR. The 1980s and 1990s was an era of massive interest in Partial Evaluation, the revolutionary idea with consequences such as deriving a compiler out of an interpreter automatically. Those ideas were later revived\paid off in projects like PyPy and GraalVM+Truffle, late 2000s and early 2010s stuff. Haskell? 1990, and only popular beginning in the late 2000s\early 2010s. LLVM? early 2000s. SML? OCaml? F#? Scala? Erlang? Rust? Clojure? Perl and its legacy in Raku? Julia? Mathematica? I can go on and on. Highly skeptical of that "very real sense" that views all of this cambrian explosion of ideas and explorations as not really progress.
- rjsw 4y ago
  Looks more like keeping reinventing the wheel than a cambrian explosion of ideas to me.
- abecedarius 4y ago
  ML existed in the early 80s. So did early lazy functional languages (KRC). I could go on in this vein if the "very real sense" he means is about finding basic ideas vs. developing and spreading them. (I get the impression Rust passes this test, though. E.g. Wadler's "Linear types can change the world" is from 1990, Baker's "Lively linear Lisp" from 1992, and after that I stopped looking.) I haven't read the OP yet.
- eadmund 4y ago
  > > there is a very real sense in which programming languages haven’t really progressed since the early 80s. > 1980 is the debut of Smalltalk. 1972, actually! > Standardisation of CommonLisp happened sometimes in the mid 1980s. Finished in the mid 90s. But Lisp was around well before the 80s, and CL was in a lot of ways a standardisation of the practices developed in the 70s & 80s. > 80s. The 1990s is the "Interpreters Renaissance", when Python and Ruby (and other less elegant siblings) came out I don’t really count that as progress. Python is just an unacceptable Lisp (1958), and Ruby is by analogy an unacceptable Smalltalk (1972). > … the JVM and the proto-beginnings of the CLR. The JVM is just refinement of ideas dating back to UCSD Pascal (1977), and the CLR is just an embraced and extended JVM. > The 1980s and 1990s was an era of massive interest in Partial Evaluation, the revolutionary idea with consequences such as deriving a compiler out of an interpreter automatically. Emanuelson & Haraldsson wrote about partial evaluation in Lisp in their 1980 paper On compiling embedded languages in LISP. > Haskell? 1990, and only popular beginning in the late 2000s\early 2010s. LLVM? early 2000s. SML? OCaml? F#? Scala? Erlang? Rust? Clojure? Perl and its legacy in Raku? Julia? Mathematica? Haskell was strongly influenced by Miranda (1985), and of course based on Hadley-Milner (1969/1978), albeit with improvements. I’ll grant you that Wadler & Blott’s typeclass proposal date to the late 80s. What about LLVM is fundamental progress rather than refinement of existing work? Standard ML dates back to the early 80s: 1983. ML itself dates to the early 70s. OCaml is OO ML, a marriage of a language from the early 80s and a concept from the early 60s (Simula dates back to 1962). F# is another member of the ML (1973) family. ‘Something old, but this time on a new VM!’ isn’t really progress, is it? Scala is OO (60s) plus functional programming (50s). Erlang appeared in 1986, so I will grant that it’s just outside of my ‘early 80s’ comment. But did it progress as a language or as a runtime? Granted the boundaries are fuzzy. I’m not familiar with the scholarship which influenced Rust — it may genuinely have a few ideas which don’t date back to the late 70s/early 80s. I imagine someone here can educate me! Clojure is ‘not-really-Lisp, but on the JVM’; is that really progress as opposed to refinement? Not that refinement is unimportant! Perl’s origin in 1988 is past the early 80s, but … is there really much original there? Especially in its early versions it was basically a better awk (1977). I am not familiar with Raku, but it doesn’t really look original, but more like a polishing of Perl. Julia’s big thing is multiple dispatch, right? That dates back to the early 70s, so it can’t really be counted as an innovation in a language from a decade ago. Finally, Mathematica dates to the late 80s, so definitely outside the window I gave, but isn’t there a substantial overlap between its functionality on one hand and Lisp/Macsyma on the other? Edit: reformatted to not make this a huge string of paragraphs. Instead, it’s a wall of text. Dunno if that is an improvement. Do let me know …

bmitc 4y ago

Is dynamic scope hard to understand or be explained or isn't it just the case that most find it to be a terrible idea for general purpose software development?

aardvark179 4y ago
It does seem hard to explain to people, and although I agree it is not normally the right answer, it is often a better answer than simple thread local variables.
eadmund 4y ago
> Is dynamic scope hard to understand or be explained or isn't it just the case that most find it to be a terrible idea for general purpose software development? I think that dynamic scope is strictly better than global variables: all of its downsides are shared by globals, but it has the important advantage that a dynamic binding is scoped. Given that every popular language I am aware of supports globals in some form, I think that adopting dynamic scope would be an improvement. Even more interesting is to consider what would it would mean to replace global with dynamic scoping entirely. I don’t really know if that is possible or efficient, but it certainly is intriguing. Almost like dependency injection throughout the language. Kinda sorta kinda.
- skybrian 4y ago
  I think Go's context objects serve a similar purpose to dynamic scope? https://pkg.go.dev/context https://pkg.go.dev/context It seems like pretty much anything that lets you pass in an environment as a function parameter would work.
  - agumonkey 4y ago
    I believe dynamic variables are reinvented every year. Even dependency injection seems like a sibling.
- gpderetta 4y ago
  Implicit parameters seems to be the principled dynamic scoping for statically typed languages. Implicit parameters are in the list of must-have features for the programming language I'll never get around to implement.
- samatman 4y ago
  This is effectively how globals are handled in Lua: they are first-class environments, ordinary tables which can be assigned to a function (5.1/LuaJIT) or upvalue (5.2+) to resolve globals. I like it a lot, it's a supplement to lexical scope: like ordinary globals it's a flat namespace 'behind' the locals, unlike many implementations of globals these environments are replaceable and (mostly) fungible.
CoastalCoder 4y ago
I'm surprised that dynamic vs. lexical scope is hard for seasoned programmers / computer-scientists to grasp. Maybe it's because the two concepts are inter-related during program execution? Similar to the way that latency vs. bandwidth can confuse some people, because they're inter-related in some circumstances but not others?
slaymaker1907 4y ago
It is definitely useful for things like semi-global options like a variable for the current stdout.

Banana699 4y ago

>there is a very real sense in which programming languages haven’t really progressed since the early 80s. Can this be made any more precise to somebody who doesn't share the feeling? As a programming language aficionado, my attitude is the exact opposite of this. 1980 is the debut of Smalltalk. Standardisation of CommonLisp happened sometimes in the mid 1980s. The 1990s is the "Interpreters Renaissance", when Python and Ruby (and other less elegant siblings) came out, as well as the JVM and the proto-beginnings of the CLR. The 1980s and 1990s was an era of massive interest in Partial Evaluation, the revolutionary idea with consequences such as deriving a compiler out of an interpreter automatically. Those ideas were later revived\paid off in projects like PyPy and GraalVM+Truffle, late 2000s and early 2010s stuff. Haskell? 1990, and only popular beginning in the late 2000s\early 2010s. LLVM? early 2000s. SML? OCaml? F#? Scala? Erlang? Rust? Clojure? Perl and its legacy in Raku? Julia? Mathematica? I can go on and on. Highly skeptical of that "very real sense" that views all of this cambrian explosion of ideas and explorations as not really progress.

rjsw 4y ago
Looks more like keeping reinventing the wheel than a cambrian explosion of ideas to me.
abecedarius 4y ago
ML existed in the early 80s. So did early lazy functional languages (KRC). I could go on in this vein if the "very real sense" he means is about finding basic ideas vs. developing and spreading them. (I get the impression Rust passes this test, though. E.g. Wadler's "Linear types can change the world" is from 1990, Baker's "Lively linear Lisp" from 1992, and after that I stopped looking.) I haven't read the OP yet.
eadmund 4y ago
> > there is a very real sense in which programming languages haven’t really progressed since the early 80s. > 1980 is the debut of Smalltalk. 1972, actually! > Standardisation of CommonLisp happened sometimes in the mid 1980s. Finished in the mid 90s. But Lisp was around well before the 80s, and CL was in a lot of ways a standardisation of the practices developed in the 70s & 80s. > 80s. The 1990s is the "Interpreters Renaissance", when Python and Ruby (and other less elegant siblings) came out I don’t really count that as progress. Python is just an unacceptable Lisp (1958), and Ruby is by analogy an unacceptable Smalltalk (1972). > … the JVM and the proto-beginnings of the CLR. The JVM is just refinement of ideas dating back to UCSD Pascal (1977), and the CLR is just an embraced and extended JVM. > The 1980s and 1990s was an era of massive interest in Partial Evaluation, the revolutionary idea with consequences such as deriving a compiler out of an interpreter automatically. Emanuelson & Haraldsson wrote about partial evaluation in Lisp in their 1980 paper On compiling embedded languages in LISP. > Haskell? 1990, and only popular beginning in the late 2000s\early 2010s. LLVM? early 2000s. SML? OCaml? F#? Scala? Erlang? Rust? Clojure? Perl and its legacy in Raku? Julia? Mathematica? Haskell was strongly influenced by Miranda (1985), and of course based on Hadley-Milner (1969/1978), albeit with improvements. I’ll grant you that Wadler & Blott’s typeclass proposal date to the late 80s. What about LLVM is fundamental progress rather than refinement of existing work? Standard ML dates back to the early 80s: 1983. ML itself dates to the early 70s. OCaml is OO ML, a marriage of a language from the early 80s and a concept from the early 60s (Simula dates back to 1962). F# is another member of the ML (1973) family. ‘Something old, but this time on a new VM!’ isn’t really progress, is it? Scala is OO (60s) plus functional programming (50s). Erlang appeared in 1986, so I will grant that it’s just outside of my ‘early 80s’ comment. But did it progress as a language or as a runtime? Granted the boundaries are fuzzy. I’m not familiar with the scholarship which influenced Rust — it may genuinely have a few ideas which don’t date back to the late 70s/early 80s. I imagine someone here can educate me! Clojure is ‘not-really-Lisp, but on the JVM’; is that really progress as opposed to refinement? Not that refinement is unimportant! Perl’s origin in 1988 is past the early 80s, but … is there really much original there? Especially in its early versions it was basically a better awk (1977). I am not familiar with Raku, but it doesn’t really look original, but more like a polishing of Perl. Julia’s big thing is multiple dispatch, right? That dates back to the early 70s, so it can’t really be counted as an innovation in a language from a decade ago. Finally, Mathematica dates to the late 80s, so definitely outside the window I gave, but isn’t there a substantial overlap between its functionality on one hand and Lisp/Macsyma on the other? Edit: reformatted to not make this a huge string of paragraphs. Instead, it’s a wall of text. Dunno if that is an improvement. Do let me know …