This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-05-12
Channels
- # beginners (40)
- # boot (2)
- # cider (16)
- # clara (2)
- # cljs-experience (2)
- # clojure (100)
- # clojure-italy (11)
- # clojure-russia (2)
- # clojure-spec (9)
- # clojure-uk (34)
- # clojurescript (36)
- # community-development (3)
- # core-async (4)
- # cursive (4)
- # datascript (1)
- # datomic (20)
- # duct (10)
- # emacs (1)
- # fulcro (2)
- # off-topic (40)
- # onyx (12)
- # overtone (8)
- # portkey (6)
- # quil (1)
- # re-frame (7)
- # ring-swagger (2)
- # shadow-cljs (2)
- # spacemacs (2)
- # test200 (10)
- # tools-deps (16)
- # unrepl (1)
- # vim (24)
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.
@andy.fingerhut Yeah, I did a lot of Algol-68 at university. But that was... 35 years ago...
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'.
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 #
(less confusing to use #
..`#` to delimit comments than co
..`co` I think, for folks not used to reading Algol-68)
Wow, this takes me back... I loved writing Algol-68!
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 ๐
Interesting!
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.
Between that and a Sinclair programmable calculator, that's what got me hooked on programming!
BTW @dpsutton a friend of mine named a cat Snobol... because, and I quote, "she was a good string manipulator!"...
(Andrew Koenig)
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
About mailing the code and getting the results later. Can't imagine waiting two weeks and getting "hello world" in the mail ha
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.
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 ๐
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...
@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.
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...)
You don't if you nest the callbacks instead of chaining them though
I'm stuck in a promised-land. I suppose I could call (new js/Promise (fn [reject resolve]))
in the top-level
I'm not telling you to abandon Promises - by callbacks, I mean what you pass to the then method
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 stuckhttps://gist.github.com/pesterhazy/74dd6dc1246f47eb2b9cd48a1eafe649 apparently this is a well known problem
(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))
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
I suppose you have a little issue with .catch
with plet
, but I'm sure there's some clever solution to that too ๐
There is promesa which implements some of this, but I don't really want something too complicated.
@U09LZR36F by nesting callbacks, I meant something like this:
(.then (fn [_] (.fetchBuffer))
(.then (fn [buf]
(-> (.fetchFile buf)
(.then (fn [file] (.readFile buf file)))
))
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).
I agree. I was just having a bit of a grumble. That I didn't hit this before is quite telling I suppose.
@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.