cross_wiber

vor 6 Jahrendiscuss

This sounds very similar to my perspective, which is that most applications try to provide a nice user experience in order to assist in doing something: creating a document, communicating with friends, reading the news, etc. With a game, though, the user experience is what it is trying to do. There's nothing other than UX. That makes game development good practice for focusing on UX in general.

cross_wiber

vor 7 Jahrendiscuss

That's a good point. It explains why you can very often unintentionally end up with an O(n^2) algorithm in the first place, and Dawson's law then explains why no one bothers to fix it until it's too late.

cross_wiber

vor 7 Jahrendiscuss

I believe this language is based on the "chemical programming" model as described in http://pop-art.inrialpes.fr/~fradet/PDFs/RULE04.pdf and https://www.researchgate.net/publication/225418037_Higher-Or....

I hadn't thought of the connection to the join calculus - that's pretty cool!

cross_wiber

vor 7 Jahrendiscuss

The earliest one I know of is in the Emerald programming language. There is a brief description of the technique in http://www.emeraldprogramminglanguage.org/OOPSLA-86-paper.pd... from 1986.

See http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.103... for more history and description of the implementation. From that paper: "The run-time system constructed an AbCon for each <type, implementation> pair that it encountered. An object reference consisted not of a single pointer, but of a pair of pointers: a pointer to the object itself, and a pointer to the appropriate AbCon". (Called an AbCon because it "mapped Abstract operations to Concrete implementations.)

cross_wiber

vor 8 Jahrendiscuss

Emerald objects can move from one node to another. So, for example, if an object on machine X wants to perform computation using data on some remote machine Y, the object can move to Y and have (fast, local) access to Y's data, then move back to X when it is done. So the computations themselves are mobile. This required some cleverness in the implementation, because a process's stack might even be split between multiple machines (I might be remembering that wrong).

cross_wiber

vor 8 Jahrendiscuss

Most of the comments seem to be about the page design, for a page that was probably created in the 90s. Nevertheless, Emerald the language is pretty fascinating, and way ahead of its time (it was developed in the mid to late 80s). They had strong static typing, including getting co-/contravariance right a decade before Java got it wrong! It was the first object-oriented language that I know of to have a statically-typed structural type system. In fact, the technique that Go uses to implement dynamic dispatch was independently invented 20 years earlier in Emerald. And its objects were mobile, which very few languages even today attempt.

cross_wiber

vor 9 Jahrendiscuss

(Disclaimer: I play jazz saxophone...)

I think part of the reason classical saxophone is reviled is because the "correct" tone for saxophones in a classical setting is kind of bad (with apologies to my old saxophone professor). In classical music you are expected to play with a particular tone that sounds kind of harsh and honky to me. In jazz, on the other hand, having a unique and identifiable tone - especially on saxophone - is extremely important. At least, it used to be. Compare the sounds of Ben Webster [1] (breathy, rich vibrato, almost cello-like sound in the upper register, as around 2:32 in the linked video), John Coltrane [2] (harder-edged, brighter, more pure), Stan Getz [3] (light, airy, "pretty").

But yes, you have to work at it. Unlike, say, guitar, where you just pluck the string and that's that ;)

[1]: https://www.youtube.com/watch?v=meNK2rnXDFg

[2]: https://www.youtube.com/watch?v=Je2tpX6Z-QA

[3]: https://www.youtube.com/watch?v=OBWr_cjBDhU

cross_wiber

vor 9 Jahrendiscuss

No. The MADCAP programming language included indentation for conditionals and for-loops at least by 1961 (see, for example, the chapter on MADCAP II in Annual Review in Automatic Computing Volume 2).