4 ms·

Holt's 'short introduction to concurrent euclid': https://dl.acm.org/doi/pdf/10.1145/947923.947931 https://dl.acm.org/doi/pdf/10.1145/947923.947931

082349872349872 4y ago
p73 for what I found to be the most unique feature of Euclid: its antipathy to aliasing.
- mikewarot 4y ago
  I read it, and I don't really get it. X is used out of scope, which is why we try to eliminate global variables, and use appropriate names. It seems like a huge over-reaction.
  - 082349872349872 4y ago
    https://en.wikipedia.org/wiki/Restrict https://en.wikipedia.org/wiki/Restrict is an attempt to declare that the programmer has avoided aliasing. https://en.wikipedia.org/wiki/Separation_logic https://en.wikipedia.org/wiki/Separation_logic is a very fancy attempt to reason in the presence of possible aliasing. History says the Euclid approach was a huge over-reaction, but consider also the naive memcpy: while(count--) *dst++ = *src++; which works just fine ... as long as the destination and source buffers don't overlap (are not aliased). You might consider no-aliasing imperative to have been an attempt to stake out a halfway position between "pointers are the goto of data structures" wild west full imperative, and "no mutation, even when unaliased" strict functional, disciplines.
  - jerf 4y ago
    There are many such things in historical PL design. I consider immutability in Erlang to be another example... what Erlang needed was processes to not be able to send each other mutable references. Full immutability in data achieves that goal, but is an over reaction. It was sufficient when the type system simply doesn't have references in it. Another example is the whole dynamic scripting language world considered as a reaction to the terrible static world of the 1990s. Yes, the 1990s were too static, no question, but that didn't mean we needed to turn all objects into hash tables, be able to dynamically re-write classes on both the class and the instance level, and just generally make everything, everywhere so dynamic that the language spends the majority of its runtime basically checking to see that nothing has dynamically changed since last time it did something. The PL design world is learning and growing and I find it an interesting story over time. Unfortunately when proving out a theory takes a minimum of about 20 years from thousands of programmers it's a slow process. (Also, while my comments above are certainly in some sense criticisms of the languages, I actually don't intend them as criticisms of the people involved. It is still an amazing achievement to move the state of the art ahead at all in such a harsh environment; I'm not angry that they didn't in one fell swoop fix all problems forever, even for decades not yet here.)
    - cmrdporcupine 4y ago
      re: dynamism/late-binding; it was seen as very exciting at the time. At least to me. Maybe under the influence of Self and Smalltalk, which were doing interesting things with object behaviour composition using delegation and slots and all sorts of late-bound magic. It definitely let people experiment. In JavaScript especially a thousand (inelegant) flowers bloomed and then some practices were codified into later revisions of the language and the door shut on that kind of experimentation. I'm a big fan of static type systems generally. But I do think dynamic scripting languages have their place. In particular as prototyping/scripting languages embedded in larger more robust runtimes. e.g. the original goal of JavaScript (which has now become a full blown application development language). AutoCAD had/has its lisp dialect. Emacs its own (ok it's more than just embedded scripting in that case). Many FPGA and HW eng tools use Tcl. Various games have Lua etc etc. This is a useful pattern potentially.
      - jerf 4y ago
        "But I do think dynamic scripting languages have their place." My thought isn't actually static/dynamic, but rather the amount of dynamicness. I suspect we could get 99%+ of the benefits of static languages at a fraction of the runtime cost if someone redid a dynamic language from scratch today to be dynamic only in selected ways. You pay a lot of runtime performance in Python to be able to do things like at any time edit a method three levels up the inheritance hierarchy, but you almost never actually do that sort of thing. One idea I cite often is to have a declaration phase versus a runtime phase, because the vast, vast bulk of "dynamicness" is achieved at startup. A JIT could be really aggressive about a lot of optimizations if the language itself guaranteed that after a program (or a module, or a function, or whatever makes sense in the end) declares itself "done being dynamic" that there will be no more changes. In fact I think there's a niche for a high-performance "mostly" dynamic language with threading built in from the beginning in the next 5-10 years. Static languages are getting most of the attention right now, and there's reasons for that, but I think there's a niche here that is not being well explored. Personally I'm having a hard time using dynamically-typed languages right now because the amount of performance I'm throwing away almost makes me nauseous. That's a combination of the problem with being too dynamic, as I said, and multi-decade-old implementations not being able to be multithreaded very easily. I think a language that solved those two things could be very interesting.
mikewarot 4y ago
I found this example[1]. At first blush, it looks like someone really hated semicolons. It's un-natural to me, with strong code smell. I do like that the end of a block repeats the name, to ensure matching. [1] https://www.cs.oswego.edu/~odendahl/coursework/csc443/notes/07-monitors/euclid-eg.html https://www.cs.oswego.edu/~odendahl/coursework/csc443/notes/...
- andsoitis 4y ago
  Python.
  - musicale 4y ago
    Javascript when I feel like writing it that way for fun

082349872349872 4y ago

p73 for what I found to be the most unique feature of Euclid: its antipathy to aliasing.

mikewarot 4y ago
I read it, and I don't really get it. X is used out of scope, which is why we try to eliminate global variables, and use appropriate names. It seems like a huge over-reaction.
- 082349872349872 4y ago
  https://en.wikipedia.org/wiki/Restrict https://en.wikipedia.org/wiki/Restrict is an attempt to declare that the programmer has avoided aliasing. https://en.wikipedia.org/wiki/Separation_logic https://en.wikipedia.org/wiki/Separation_logic is a very fancy attempt to reason in the presence of possible aliasing. History says the Euclid approach was a huge over-reaction, but consider also the naive memcpy: while(count--) *dst++ = *src++; which works just fine ... as long as the destination and source buffers don't overlap (are not aliased). You might consider no-aliasing imperative to have been an attempt to stake out a halfway position between "pointers are the goto of data structures" wild west full imperative, and "no mutation, even when unaliased" strict functional, disciplines.
- jerf 4y ago
  There are many such things in historical PL design. I consider immutability in Erlang to be another example... what Erlang needed was processes to not be able to send each other mutable references. Full immutability in data achieves that goal, but is an over reaction. It was sufficient when the type system simply doesn't have references in it. Another example is the whole dynamic scripting language world considered as a reaction to the terrible static world of the 1990s. Yes, the 1990s were too static, no question, but that didn't mean we needed to turn all objects into hash tables, be able to dynamically re-write classes on both the class and the instance level, and just generally make everything, everywhere so dynamic that the language spends the majority of its runtime basically checking to see that nothing has dynamically changed since last time it did something. The PL design world is learning and growing and I find it an interesting story over time. Unfortunately when proving out a theory takes a minimum of about 20 years from thousands of programmers it's a slow process. (Also, while my comments above are certainly in some sense criticisms of the languages, I actually don't intend them as criticisms of the people involved. It is still an amazing achievement to move the state of the art ahead at all in such a harsh environment; I'm not angry that they didn't in one fell swoop fix all problems forever, even for decades not yet here.)
  - cmrdporcupine 4y ago
    re: dynamism/late-binding; it was seen as very exciting at the time. At least to me. Maybe under the influence of Self and Smalltalk, which were doing interesting things with object behaviour composition using delegation and slots and all sorts of late-bound magic. It definitely let people experiment. In JavaScript especially a thousand (inelegant) flowers bloomed and then some practices were codified into later revisions of the language and the door shut on that kind of experimentation. I'm a big fan of static type systems generally. But I do think dynamic scripting languages have their place. In particular as prototyping/scripting languages embedded in larger more robust runtimes. e.g. the original goal of JavaScript (which has now become a full blown application development language). AutoCAD had/has its lisp dialect. Emacs its own (ok it's more than just embedded scripting in that case). Many FPGA and HW eng tools use Tcl. Various games have Lua etc etc. This is a useful pattern potentially.
    - jerf 4y ago
      "But I do think dynamic scripting languages have their place." My thought isn't actually static/dynamic, but rather the amount of dynamicness. I suspect we could get 99%+ of the benefits of static languages at a fraction of the runtime cost if someone redid a dynamic language from scratch today to be dynamic only in selected ways. You pay a lot of runtime performance in Python to be able to do things like at any time edit a method three levels up the inheritance hierarchy, but you almost never actually do that sort of thing. One idea I cite often is to have a declaration phase versus a runtime phase, because the vast, vast bulk of "dynamicness" is achieved at startup. A JIT could be really aggressive about a lot of optimizations if the language itself guaranteed that after a program (or a module, or a function, or whatever makes sense in the end) declares itself "done being dynamic" that there will be no more changes. In fact I think there's a niche for a high-performance "mostly" dynamic language with threading built in from the beginning in the next 5-10 years. Static languages are getting most of the attention right now, and there's reasons for that, but I think there's a niche here that is not being well explored. Personally I'm having a hard time using dynamically-typed languages right now because the amount of performance I'm throwing away almost makes me nauseous. That's a combination of the problem with being too dynamic, as I said, and multi-decade-old implementations not being able to be multithreaded very easily. I think a language that solved those two things could be very interesting.

mikewarot 4y ago

I found this example[1]. At first blush, it looks like someone really hated semicolons. It's un-natural to me, with strong code smell. I do like that the end of a block repeats the name, to ensure matching. [1] https://www.cs.oswego.edu/~odendahl/coursework/csc443/notes/07-monitors/euclid-eg.html https://www.cs.oswego.edu/~odendahl/coursework/csc443/notes/...

andsoitis 4y ago
Python.
- musicale 4y ago
  Javascript when I feel like writing it that way for fun