Fork me on GitHub
#off-topic
<
2018-05-12
>
andy.fingerhut01:05:31

Huh, anyone ever used Algol-68? Yeah, I know that is a real shot in the dark. I ask because Henry Baker's paper defining the "EGAL" operator upon which Clojure's = is based mentions this sentence describing Algol-68 that makes it sound a lot like Clojure's data structures: "There is another model introduced by Algol-68, however, which is cleaner because there is only one kind of mutable object -- the cell (Algol-68 called it a "reference") -- and all other objects are immutable." I guess Algol-68 was long before Bagwell's and Clojure's work on fast implementations of immutable sets/maps/vectors/etc. were devised, so Algol-68 likely didn't have those things, but it just struck a chord of similarity while reading it.

seancorfield02:05:31

@andy.fingerhut Yeah, I did a lot of Algol-68 at university. But that was... 35 years ago...

seancorfield02:05:12

Algold-68 had a ref qualifier for any type, and you could have ref ref int for example, which is a "var" that 'points to' another "var" that contains an 'int'.

seancorfield03:05:54

You made me go do a refresher course ๐Ÿ™‚

int i1 = 2; # i1 is a constant with value 2 #
int i2 := 3; # short for ref int i2 = loc int := 3; i2 is a (constant) reference to a local (stack) int that is initialized with 3 #

seancorfield03:05:49

(less confusing to use #..`#` to delimit comments than co..`co` I think, for folks not used to reading Algol-68)

seancorfield03:05:03

Wow, this takes me back... I loved writing Algol-68!

seancorfield03:05:46

When I did my final year project -- writing an APL interpreter -- I wanted to write it in Algol-68, but my supervisors said they didn't know Algol-68 well enough to review it, so I had to write it in Pascal instead ๐Ÿ˜

dpsutton03:05:20

We had to build a program in SNOBOL-4 in college to validate algol 60 programs

seancorfield03:05:25

I did Algol 60 as a correspondence course at my high school (in the 70's). We wrote our code out by hand on grid paper and it was mailed off to the local technical college who typed it in, corrected the typos and syntax errors, ran it, and mailed us back the printout of results, for us to review a week later.

seancorfield03:05:29

Between that and a Sinclair programmable calculator, that's what got me hooked on programming!

seancorfield03:05:36

BTW @dpsutton a friend of mine named a cat Snobol... because, and I quote, "she was a good string manipulator!"...

๐Ÿ˜ 16
seancorfield03:05:47

(Andrew Koenig)

dpsutton03:05:51

Outstanding! It's an amazing language. And there's this one lone Wolf on GitHub who has implemented a ton of algorithms in SNOBOL-4. It is not an easy language for stuff like that

dpsutton03:05:12

Your story is incredible

dpsutton03:05:22

About mailing the code and getting the results later. Can't imagine waiting two weeks and getting "hello world" in the mail ha

mikerod03:05:31

It seems that itโ€™d be difficult to get very complex programs done with such a horrible feedback cycle. I guess programs were simpler back then though.

arrdem04:05:10

http://www.mcs.vuw.ac.nz/comp/Publications/archive/CS-TR-02/CS-TR-02-9.pdf page 3, โ€œOn our ability to do muchโ€ instantly sprang to mind ๐Ÿ˜‰

โœ… 4
mikerod05:05:43

Nice. Itโ€™s applicable. Hadnโ€™t see this paper before.

soulflyer05:05:48

My first encounter with programming was filing in coding forms to be passed to an operator to punch a deck of cards. It was a weekend course and the turnaround was actually pretty fast, especially when they started letting us punch out own cards. Not fast enough for my flight of fancy, a proof of concept word processor* in fortran to be returned to me before the weekend ended. Forgot all about it until weeks later I got hauled up in front of the headmaster for wasting computer time.. *bunch of println statements might be a more accurate description...

๐Ÿ˜„ 8
seancorfield05:05:51

@dpsutton Turnaround was a week but, yeah, it was par for the course. My first job was COBOL at an insurance company and we would submit JCL decks and our compile results would come back hours later. A few of us figured out how to "jump the queue" and get near real time compile results (maybe fifteen minutes), and then we figured out how to bypass the queue and run the compiler directly (still as a batch job) so we could get our results in just minutes.

๐Ÿ‘ 4
seancorfield06:05:43

At university, we used to back up stuff on paper tape. Including a prerelease of the O/S that we found mounted on a random drive one evening ๐Ÿ™‚ and boy, did we get in trouble for that! (Primos 19 -- a.k.a. primix -- was Prime Computers first Unix version and we were a beta test site...)

dominicm14:05:38

I've never hit this before, promises suck because you lose your lexical scope

val_waeselynck19:05:57

You don't if you nest the callbacks instead of chaining them though

dominicm19:05:45

I'm stuck in a promised-land. I suppose I could call (new js/Promise (fn [reject resolve])) in the top-level

val_waeselynck19:05:26

I'm not telling you to abandon Promises - by callbacks, I mean what you pass to the then method

dominicm19:05:13

I'm a bit confused, if I do:

(.then (fn [_] (.fetchBuffer))
(.then (fn [buf] (.fetchFile buf)))
(.then (fn [file] (.readFile buf file)))
In my last then I am stuck

dominicm19:05:42

I ended up with using (every buf (.fetchFile buf))

leonoel09:05:59

(defmacro plet [bindings & body]
  (if-some [[s p & bindings] (seq bindings)]
    `(.then ~p (fn [~s] (plet ~bindings ~@body)))
    `(do ~@body)))

(plet [buf (.fetchBuffer)
       file (.fetchFile buf)]
  (.readFile buf file))

leonoel10:05:48

this is the monadic solution javascript async/await syntax, or core.async go macro is another one this is a general problem in asynchronous programming, not really specific to promises

leonoel10:05:34

that being said, promises suck, but not for this reason

dominicm11:05:53

That's a neat solution, not so easy in plain ol' js of course.

dominicm11:05:30

I suppose you have a little issue with .catch with plet, but I'm sure there's some clever solution to that too ๐Ÿ™‚

dominicm11:05:09

There is promesa which implements some of this, but I don't really want something too complicated.

val_waeselynck11:05:22

@U09LZR36F by nesting callbacks, I meant something like this:

(.then (fn [_] (.fetchBuffer))
(.then (fn [buf] 
              (-> (.fetchFile buf)
                 (.then (fn [file] (.readFile buf file)))
              ))

val_waeselynck11:05:28

I also think it's not very useful to include arguments like 'X sucks' or 'Y is awesome' in technical discussions. I find Promises to be the best approach in many contexts (more so than core.async channels and go blocks for example).

dominicm12:05:15

I agree. I was just having a bit of a grumble. That I didn't hit this before is quite telling I suppose.

๐Ÿ‘ 4
leonoel13:05:13

@U09LZR36F error handling is a big deal, that's why I think async/await syntax is superior because you can wrap an await inside a try/catch. however the last time I checked promesa did not allowed this, and you can't do that with core.async either because channels are unaware of failure.

๐Ÿ‘ 4
dominicm14:05:51

I have some resolved values, and I now need to create a whole promise in order to grab my lexical scope & add it to another promise