5 ms·

No it did not. Sigplan doesn't even have a most notable paper award. https://www.sigplan.org/Awards/ https://www.sigplan.org/Awards/ It won an award from the

No it did not. Sigplan doesn't even have a most notable paper award. https://www.sigplan.org/Awards/ https://www.sigplan.org/Awards/ It won an award from the Dynamic Languages Symposium. A minor workshop that gets about 4-6 submissions per year. By the standards of modern academia this would be considered a tiny venue, like 10x smaller than any say at workshop at NeurIPS and quite a bit smaller than an ICFP workshop.

DonHopkins 2y ago
I actually tried to add DLS to the title of this discussion, but the character limit was one character too short, so I was forced to leave it out. Sorry, the intent was not to deceive you or commit academic fraud. Have you actually read the paper and have anything interesting to say about it, or are you just complaining about the title of this discussion?
- mpweiher 2y ago
  Well DLS is more relevant than ACM SIGPLAN, so you could leave out as much of the less relevant part until the more relevant part fits. Update: I should note that I have published several papers at DLS. It is a great venue(1), but it just is not ACM SIGPLAN. (1) or was. There was no DLS at this year's SPLASH.
  - DonHopkins 2y ago
    Of course you could paint the bikeshed that color, but it's too late now. If you really care that much and want to bother him, you could email hn@ycombinator.com and maybe dang will edit the title. Do you have anything interesting to say about the contents of the paper itself, or did you just come here to complain about the discussion title too?
    - mpweiher 2y ago
      Pointing out a highly misleading article title and how it could be easily improved is not bike-shedding in the least. As to the contents, I am not sure I have anything interesting to say about it, but I find the idea of layering one dynamic language on top of another dynamic language in this fashion unconvincing. The benchmarks cited in the paper bear out my skepticism: "... between one and two orders of magnitude slower than the Squeak Interpreter in C". On chrome it was between 2 and 3 orders of magnitude. So around a hundred times slower than the Squeak byte code interpreter, which is already not exactly a speed demon. One thing the paper does demonstrate is the incredible performance of today's hardware, well even the hardware of 10 years ago, which is the only thing that makes such an approach even remotely viable. When I attended ESUG '19 in Cologne, there were several of these Smalltalk → JavaScript projects present (I think at least 3). The others worked using transpilation, but the purpose of all these systems was to run existing legacy Smalltalk systems without existing legacy VMs. So a lot of legacy. Very little innovation. I rarely saw good reasons for Smalltalk apart from "well, we just have this huge legacy codebase that we don't want to touch" (and a bit of "I am used to the IDE"). Made me a bit sad. Yes, running a Squeak image unmodified in the browser by simply porting the VM is neat, as a curiosity. Kinda like booting Linux in the browser. https://bellard.org/jslinux/ https://bellard.org/jslinux/ But please don't do it. We already have too many layers as it is, and this way of just plopping one layer on top of another layer in order not to have to change things is exactly how we got there. (unless you are very explicitly doing code archeology as described in the paper) See: We are likely looking at over 50 million active lines of code to open a garage door…. https://spectrum.ieee.org/lean-software-development https://spectrum.ieee.org/lean-software-development
- hitekker 2y ago
  [flagged]

DonHopkins 2y ago

I actually tried to add DLS to the title of this discussion, but the character limit was one character too short, so I was forced to leave it out. Sorry, the intent was not to deceive you or commit academic fraud. Have you actually read the paper and have anything interesting to say about it, or are you just complaining about the title of this discussion?

mpweiher 2y ago
Well DLS is more relevant than ACM SIGPLAN, so you could leave out as much of the less relevant part until the more relevant part fits. Update: I should note that I have published several papers at DLS. It is a great venue(1), but it just is not ACM SIGPLAN. (1) or was. There was no DLS at this year's SPLASH.
- DonHopkins 2y ago
  Of course you could paint the bikeshed that color, but it's too late now. If you really care that much and want to bother him, you could email hn@ycombinator.com and maybe dang will edit the title. Do you have anything interesting to say about the contents of the paper itself, or did you just come here to complain about the discussion title too?
  - mpweiher 2y ago
    Pointing out a highly misleading article title and how it could be easily improved is not bike-shedding in the least. As to the contents, I am not sure I have anything interesting to say about it, but I find the idea of layering one dynamic language on top of another dynamic language in this fashion unconvincing. The benchmarks cited in the paper bear out my skepticism: "... between one and two orders of magnitude slower than the Squeak Interpreter in C". On chrome it was between 2 and 3 orders of magnitude. So around a hundred times slower than the Squeak byte code interpreter, which is already not exactly a speed demon. One thing the paper does demonstrate is the incredible performance of today's hardware, well even the hardware of 10 years ago, which is the only thing that makes such an approach even remotely viable. When I attended ESUG '19 in Cologne, there were several of these Smalltalk → JavaScript projects present (I think at least 3). The others worked using transpilation, but the purpose of all these systems was to run existing legacy Smalltalk systems without existing legacy VMs. So a lot of legacy. Very little innovation. I rarely saw good reasons for Smalltalk apart from "well, we just have this huge legacy codebase that we don't want to touch" (and a bit of "I am used to the IDE"). Made me a bit sad. Yes, running a Squeak image unmodified in the browser by simply porting the VM is neat, as a curiosity. Kinda like booting Linux in the browser. https://bellard.org/jslinux/ https://bellard.org/jslinux/ But please don't do it. We already have too many layers as it is, and this way of just plopping one layer on top of another layer in order not to have to change things is exactly how we got there. (unless you are very explicitly doing code archeology as described in the paper) See: We are likely looking at over 50 million active lines of code to open a garage door…. https://spectrum.ieee.org/lean-software-development https://spectrum.ieee.org/lean-software-development
hitekker 2y ago
[flagged]