Is your programming language unreasonable? (2015) • Hacker News Board

Re: Is your programming language unreasonable? (2015)

#111

Post by msla » Sat, Oct 10, 2020, 7:19 PM UTC

retrac wrote: post #98

catlifeonmars wrote: post #59

Earlier quoted context omitted.

Isn’t it possible (at least in theory) to make mutability an implementation detail of the compiler/runtime? Rust’s borrow checker approaches this, but the abstraction leaky or nonexistent. Additionally, many high performance computing applications (e.g. Tensorflow) abstract away expensive mutable operations, so at least in theory, it should be possible to isolate mutability to small segments of code where mutability…

Yes, Haskell as a pure functional language does this too. A naive copy-by-value handling of lists will usually end up in the same order of magnitude for performance as mutate-in-place linked lists in C. The compiler can track those immutable values and just mutate them in place, when it can guarantee that's a safe operation. The vast majority of the time, you can get away with just copying a pointer or renaming, not…

> The caveat is that, in my experience, it's a fair bit harder to reason about performance, as the execution model is even more abstracted away from the hardware than even something like the C model is (which is no longer a good fit either, in this era of speculative execution and multi-level caches.)

One solution is to have a tool developed and distributed along with the compiler (so it can never fall out of sync with the compiler, that's why) annotate the code with notes about performance.

Re: Is your programming language unreasonable? (2015)

#112

Post by msla » Sat, Oct 10, 2020, 7:21 PM UTC

mitchtbaum wrote: post #16

Speakeasy, Lightouch, Jazz is a fifth-generation programming language. I find only small hurdlesv when showing it to programmers. My challenge now is mainly getting stable shelter so I can compile these notes and hand them off to people.

> fifth-generation programming language

Does anyone, anywhere have an actual definition for this?

I thought the whole notion of "generations" was over and done with in the 1980s.

Re: Is your programming language unreasonable? (2015)

#113

Post by zabzonk » Sat, Oct 10, 2020, 7:26 PM UTC

vram22 wrote: post #107

Athas wrote: post #58

Earlier quoted context omitted.

I'm not going to claim that mutability is never useful for performance, but many large scale simulations can be expressed quite elegantly using bulk operations on arrays or other structures, with no mutability in sight. Both particle simulations a la n-body and stencil operations are in this category. An efficient low-level implementation of such bulk operations involves mutable updates, just like any functional lang…

Interesting. Can you explain, with a somewhat simple example, how this can be efficiently implemented, or at all? I mean preserving the appearance of immutability at the source language level, while mutating the original structure under the hood for performance.

C++ supports this via the mutable keyword https://stackoverflow.com/questions/105014/does-the-mutable-... though not particularly for performance purposes.

Re: Is your programming language unreasonable? (2015)

#114

Post by [deleted] » Sat, Oct 10, 2020, 7:28 PM UTC

vram22 wrote: post #107

Athas wrote: post #58

Earlier quoted context omitted.

I'm not going to claim that mutability is never useful for performance, but many large scale simulations can be expressed quite elegantly using bulk operations on arrays or other structures, with no mutability in sight. Both particle simulations a la n-body and stencil operations are in this category. An efficient low-level implementation of such bulk operations involves mutable updates, just like any functional lang…

Interesting. Can you explain, with a somewhat simple example, how this can be efficiently implemented, or at all? I mean preserving the appearance of immutability at the source language level, while mutating the original structure under the hood for performance.

[deleted]

Re: Is your programming language unreasonable? (2015)

#115

Post by amai » Sat, Oct 10, 2020, 7:32 PM UTC

So which languages apart from F# are reasonable according to the authors requirements?

Re: Is your programming language unreasonable? (2015)

#116

Post by toolslive » Sat, Oct 10, 2020, 7:45 PM UTC

masklinn wrote: post #68

toolslive wrote: post #66

it's all about surprises. Programmers hate them. You want to be able to reason about your code For example: fact: a == b fact: f(x) is p deterministic pure function. So I figure f(a) == f(b) Well, maybe... Javascript (obviously) and Python are amongst the programming languages where the above reasoning is not true. (there are exceptions).

> Well, maybe... Javascript (obviously) and Python are amongst the programming languages where the above reasoning is not true. (there are exceptions). There are lots of exceptions. For starters (2) seems like an assumption rather than a fact. An other assumption which is just that is that equality is transitive through f. This is not a generalised fact in any language which allows overriding equality.

even with the python `int`s a: int, b:int and the `str` function as the pure deterministic function you still cannot make the conclusion. It's an utter mess

Re: Is your programming language unreasonable? (2015)

#117

Post by Athas » Sat, Oct 10, 2020, 8:19 PM UTC

vram22 wrote: post #107

Athas wrote: post #58

Earlier quoted context omitted.

I'm not going to claim that mutability is never useful for performance, but many large scale simulations can be expressed quite elegantly using bulk operations on arrays or other structures, with no mutability in sight. Both particle simulations a la n-body and stencil operations are in this category. An efficient low-level implementation of such bulk operations involves mutable updates, just like any functional lang…

Interesting. Can you explain, with a somewhat simple example, how this can be efficiently implemented, or at all? I mean preserving the appearance of immutability at the source language level, while mutating the original structure under the hood for performance.

Any vectorised operation in Numpy is an example of this. The pure subset of Numpy can be used to write useful programs, but the Numpy functions/methods are mostly implemented in impure C.

Another example is completely pure array programming such as in Accelerate[0] or Futhark[1].

[0]: http://www.acceleratehs.org/

[1]: https://futhark-lang.org

Re: Is your programming language unreasonable? (2015)

#118

Post by elihu » Sat, Oct 10, 2020, 8:36 PM UTC

rzwitserloot wrote: post #12

I lost the line of reasoning (or perhaps the author did) at the second example. If I have 2 InputStream objects, nevermind equality. It just doesn't apply here. I don't even want `a.Equals(b)` to be considered valid code in the first place. Having __any__ default behaviour here is a lot like the permissiveness that is bashed in example 1 (a trifecta of unexpected variable scoping rules, the ability to re-type variabl…

A couple other counterexamples to

> "Records with the same internal data ARE equal by default"

Floats: floating point equality tests between two floats of the same value or testing equality with itself is generally "true" with the exception of NaN (i.e. "not a number") values. Testing if NaN == Nan is "false" according to the IEEE [1]. (Probably not all languages follow IEEE's recommendation.)

Functions: some functions are trivially the same, and some functions are trivially different, but deciding whether arbitrary functions (for instance, f(x) { x + x } and f(x) { 2*x } return the same values and have the same side-effects for all possible inputs is generally not something a compiler should be expected to do. So any record with a function as a field can't really be tested for equality.

[1] https://stackoverflow.com/questions/38798791/nan-comparison-...

Re: Is your programming language unreasonable? (2015)

#119

Post by heavenlyblue » Sat, Oct 10, 2020, 9:37 PM UTC

msla wrote: post #111

retrac wrote: post #98

Earlier quoted context omitted.

Yes, Haskell as a pure functional language does this too. A naive copy-by-value handling of lists will usually end up in the same order of magnitude for performance as mutate-in-place linked lists in C. The compiler can track those immutable values and just mutate them in place, when it can guarantee that's a safe operation. The vast majority of the time, you can get away with just copying a pointer or renaming, not…

> The caveat is that, in my experience, it's a fair bit harder to reason about performance, as the execution model is even more abstracted away from the hardware than even something like the C model is (which is no longer a good fit either, in this era of speculative execution and multi-level caches.) One solution is to have a tool developed and distributed along with the compiler (so it can never fall out of sync wi…

I think if performance is part of the requirements of your code, then performance must be a part of your type signature.

For example, a tail-recursive function needs to have it’s type as tail-recursive.

Re: Is your programming language unreasonable? (2015)

#120

Post by mrkeen » Sat, Oct 10, 2020, 10:30 PM UTC

discreteevent wrote: post #106

mrkeen wrote: post #35

Earlier quoted context omitted.

Accountants do not use erasers. Mutating variables in-place is the training wheels. Got a bank account? Want me to transfer money by increasing this account and decreasing that account? But perhaps that's too small an example. What about a large, distributed system? Both Paxos and Raft are recipes for clusters of machines to agree on immutable sequences of values.

They do that because they want to keep a history of each transaction. I don't want to keep a history of all the positions of a character in my game.

> They do that because they want to keep a history of each transaction.

It's about more than just history. Logging would (maybe) suffice for that. It's about getting cause and effect right when there's more than one computer separated by a distance.

> I don't want to keep a history of all the positions of a character in my game.

Sure - not in a single-player game.

But can you take the same approach in a multiplayer game? Grab some players, give them different clocks and separate them 20-150ms apart from another, and have each of them tell the server what happened at the time it happened? Things will diverge pretty quickly.

You end up reinventing the same old append-only log on the server. That way, when client messages arrive at the server out-of-order, you still have the info necessary to rollback state and issue corrections to other clients. When that's all set up, you can then choose some horizon (200ms?) and garbage collect all events before that. Or you can keep the events around and show replays and/or calculate stats for achievements at the end of a match.