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

Re: Is your programming language unreasonable? (2015)

#61

Post by hansvm » Sat, Oct 10, 2020, 2:06 PM UTC

Lavinski wrote: post #39

The article goes through a series of examples to show motivations for the following: 1. Variables should not be allowed to change their type. 2. Objects containing the same values should be equal by default. 3. Comparing objects of different types is a compile-time error. 4. Objects must always be initialized to a valid state. Not doing so is a compile-time error. 5. Once created, objects and collections must be immu…

1. Variables should not be allowed to change their type.

This sounds nice, but is there a way to accomplish it without losing some expressibility or concision? Rather than looking at JS, consider low-level operations on a small chunk of memory as a niche example. Interpreting the same region as a buffer of 64-bit ints vs 16-bit uints gives entirely different behavior to the standard operators like addition, multiplication, and shifts, and there are plenty of cases where it makes sense to mix and match those operators. It's possible to construct a single type that encompasses all that behavior, but the price for doing so is a formidable wall of similar-looking method names rather than just being able to use a plus sign or other easier-to-understand constructs.

Re: Is your programming language unreasonable? (2015)

#62

Post by bgorman » Sat, Oct 10, 2020, 2:06 PM UTC

leephillips wrote: post #56

Lavinski wrote: post #39

The article goes through a series of examples to show motivations for the following: 1. Variables should not be allowed to change their type. 2. Objects containing the same values should be equal by default. 3. Comparing objects of different types is a compile-time error. 4. Objects must always be initialized to a valid state. Not doing so is a compile-time error. 5. Once created, objects and collections must be immu…

5. Once created, objects and collections must be immutable. So this language would not be general purpose, as it would not be suitable for high-performance computing. Large scale simulations almost always involve arrays that are modified in place. Being able to somehow declare a collection to be immutable would be highly useful, but not having the option of mutable collections limits the kinds of problems that can be…

F# and OCaml have mutable arrays.

Re: Is your programming language unreasonable? (2015)

#63

Post by masklinn » Sat, Oct 10, 2020, 2:06 PM UTC

nyanpasu64 wrote: post #46

Lavinski wrote: post #39

The article goes through a series of examples to show motivations for the following: 1. Variables should not be allowed to change their type. 2. Objects containing the same values should be equal by default. 3. Comparing objects of different types is a compile-time error. 4. Objects must always be initialized to a valid state. Not doing so is a compile-time error. 5. Once created, objects and collections must be immu…

Rust's borrow checker would prevent Example 5 from compiling, since once you add `cust` to the collection, you can't touch it anymore (unless you insert a clone or etc.). So in this case at least, the inability to reason about code can be resolved by banning mutable aliasing, without eliminating mutability.

Rust's ownership system would prevent example 5 from working (because you have to move the instance into the set).

The borrow checker is about validating that references don't outlive their target, and R^W.

Re: Is your programming language unreasonable? (2015)

#64

Post by mwcampbell » Sat, Oct 10, 2020, 2:06 PM UTC

mpweiher wrote: post #47

sullyj3 wrote: post #13

Earlier quoted context omitted.

I like how this could be taken as an endorsement or criticism of the article, depending on the hubris of the reader

Or the hubris of the language designer.

I would only take it as hubris or condescension if the language designer chose to write their compiler in a language other than the one they were designing. Otherwise, I'd interpret the presence of strong guard rails as humility, an acknowledge of how fallible our puny human minds are and how much help we need from machines to minimize the cost of our inevitable mistakes.

Re: Is your programming language unreasonable? (2015)

#65

Post by mwcampbell » Sat, Oct 10, 2020, 2:11 PM UTC

Among reasonable programming languages (as defined in this article), which one compiles to the most optimized JavaScript that can efficiently interoperate with external JS code? Reason or OCaml via BuckleScript? F# via Fable? Scala? Maybe Kotlin is close enough?

Re: Is your programming language unreasonable? (2015)

#66

Post by toolslive » Sat, Oct 10, 2020, 2:12 PM UTC

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).

Re: Is your programming language unreasonable? (2015)

#67

Post by masklinn » Sat, Oct 10, 2020, 2:12 PM UTC

hansvm wrote: post #61

Lavinski wrote: post #39

The article goes through a series of examples to show motivations for the following: 1. Variables should not be allowed to change their type. 2. Objects containing the same values should be equal by default. 3. Comparing objects of different types is a compile-time error. 4. Objects must always be initialized to a valid state. Not doing so is a compile-time error. 5. Once created, objects and collections must be immu…

1. Variables should not be allowed to change their type. This sounds nice, but is there a way to accomplish it without losing some expressibility or concision? Rather than looking at JS, consider low-level operations on a small chunk of memory as a niche example. Interpreting the same region as a buffer of 64-bit ints vs 16-bit uints gives entirely different behavior to the standard operators like addition, multiplic…

> Interpreting the same region as a buffer of 64-bit ints vs 16-bit uints

The variable doesn't change its type though, instead you change your interpretation of it. That's a very different and explicit operation & manipulation.

Although example 1 doesn't strictly have anything to do with types, you could get the same behaviour with `x = 0` in any language with closures (like javascript), or `foo = 0` in a language which passes parameters by (mutable) references as long as that information is not visible in the caller.

Re: Is your programming language unreasonable? (2015)

#68

Post by masklinn » Sat, Oct 10, 2020, 2:18 PM UTC

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.

Re: Is your programming language unreasonable? (2015)

#69

Post by jen20 » Sat, Oct 10, 2020, 2:19 PM UTC

mrkeen wrote: post #35

gridlockd wrote: post #26

"Objects containing the same values should be equal by default." No. This breaks down as soon as you have references to other objects in your objects. If you compare by reference, you probably don't get what you want. If you compare by value, you need to go arbitrarily deep, which is not a sane default, because of possible reference cycles. You need a distinction between objects and value types. C# has that (record t…

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.

One small nitpick with this otherwise excellent post - Paxos allows a cluster of nodes to agree on a _single_ value, not a sequence (which requires Multi-Paxos or some other similar extension of 'basic' single-decree Paxos).

Re: Is your programming language unreasonable? (2015)

#70

Post by scns » Sat, Oct 10, 2020, 2:26 PM UTC

hansvm wrote: post #61

Lavinski wrote: post #39

The article goes through a series of examples to show motivations for the following: 1. Variables should not be allowed to change their type. 2. Objects containing the same values should be equal by default. 3. Comparing objects of different types is a compile-time error. 4. Objects must always be initialized to a valid state. Not doing so is a compile-time error. 5. Once created, objects and collections must be immu…

1. Variables should not be allowed to change their type. This sounds nice, but is there a way to accomplish it without losing some expressibility or concision? Rather than looking at JS, consider low-level operations on a small chunk of memory as a niche example. Interpreting the same region as a buffer of 64-bit ints vs 16-bit uints gives entirely different behavior to the standard operators like addition, multiplic…

In descendants of ML (Haskell, OCaml, Rust etc) you can use Algebraic Data Types to condense your wall of methods to one function