Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Is your programming language unreasonable? (2015)

fsharpforfunandprofit.com

Post reply on HN
Print view View original

101–110 of 138 posts

Re: Is your programming language unreasonable? (2015)

#101

Post by alkonaut »

tyrrrz wrote: post #99
alkonaut wrote: post #60

> Objects containing the same values should be equal by default. I strongly disagree with this. I’d take it one step further and say that there should be no equality operator or default equals function for non-primitive data types. Some specific type of records/tuples could use a default equality, but it should be opt-in or follow from using metadata like an attribute (e.g Rust derive) or only for those specific type…

To me "avoiding mutations" does not mean "no mutations", but rather "no mutations in-between states in a state machine". The system should model state as an immutable snapshot, while mutations when forming that state are completely acceptable.

There is obviously mutation at some level of abstraction but usually one form of coding is idiomatic and one isn’t. I’m all for using immutable data and pure functions, but I’d discard a language and standard library that doesn’t have a good/idiomatic story for e.g mutating large arrays in place or has a good selection of contiguous (array-backed) collections be too limited for many types of work.

Re: Is your programming language unreasonable? (2015)

#102

Post by mitchtbaum »

Memosyne wrote: post #49
ColinWright wrote: post #21

Earlier quoted context omitted.

I really can't work out what you're trying to say here. I can guess, but maybe it would be better if you wrote something more expository or discursive. For example, is "Speakeasy, Lightouch, Jazz" intended to be a single noun? A single thing? Or is it a collection? A sequence? What do you mean by "getting stable shelter"? Or to "hand off notes to people"? Have you written something already? is there a link?

I think he's referring to this: https://github.com/speakeasy-engine/lighttouch

Lighttouch is Speakeasy's Web Application Framework.

With Speakeasy I'm aiming at a complete solution stack.

Re: Is your programming language unreasonable? (2015)

#104

Post by [deleted] »

ColinWright wrote: post #21
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.

I really can't work out what you're trying to say here. I can guess, but maybe it would be better if you wrote something more expository or discursive. For example, is "Speakeasy, Lightouch, Jazz" intended to be a single noun? A single thing? Or is it a collection? A sequence? What do you mean by "getting stable shelter"? Or to "hand off notes to people"? Have you written something already? is there a link?

[deleted]

Re: Is your programming language unreasonable? (2015)

#105

Post by throw_m239339 »

edflsafoiewq wrote: post #100
tzs wrote: post #90

In example #6, he gives this as the unreasonable approach: var repo = new CustomerRepository(); var customer = repo.GetById(42); Console.WriteLine(customer.Id); with the issue being customer can be null, which is not being accounted for. The reasonable approach he says is to use a sum type: var repo = new CustomerRepository(); var customerOrError = repo.GetById(42); if (customerOrError.IsCustomer) Console.WriteLine(c…

Typescript allows this const c = getCustomer(); // type is Customer | null const z : Customer = c; // ERROR; incompatible types if (x === null) { // handle null } else { const y : Customer = c; // OK; knows c isn't null here }

Well Typescript is really a static code analyser for Javascript and not a language, since it does nothing at runtime, and that's fine, its type system can catch a broad range of issues and improve code quality drastically. It's a huge godsend for big codebases. But afaik it doesn't guard against null by default.

A simpler example:

    declare type Foo = {name:String};
    declare function getFoo():Foo|null;

    const f = getFoo();
    if(f!==null) // mandatory or yields an error
        console.log(f.name);
But afaik it doesn't guard against null by default.

Re: Is your programming language unreasonable? (2015)

#106

Post by discreteevent »

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.

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.

Re: Is your programming language unreasonable? (2015)

#107

Post by vram22 »

Athas wrote: post #58
leephillips wrote: post #56

Earlier quoted context omitted.

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…

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.

Re: Is your programming language unreasonable? (2015)

#108

Post by masklinn »

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.

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

Simple example: hashsets equality & conversion to sequences.

Hashset equality, to the extent that it's present, is always based on the presence of items in the set.

But the iteration order of two hashsets with the same contents can depend on the way they were initialised (as that influences whether collisions happen) and the order in which items were added.

So given a and b be hashsets and f be toArray (or whatever), it is very common to have a == b but f(a) != f(b).

Re: Is your programming language unreasonable? (2015)

#109

Post by guenthert »

mpweiher wrote: post #45
rootsofallevil wrote: post #8

> I don’t care what my language will let me do, I care more about what my language won’t let me do. I think this is the best summary of the article. In short, please protect me from my own stupidity and/or laziness.

Alan Kay referred to this as the "Wirth school of non-programming". It obviously has some merit, but I'd rather have a language be an enabler rather than a disabler. And again, not having to worry about messing up is or at least can be a kind of enabler, but I prefer a more positive approach, with good defaults encouraging me to do the good and simple, but the language getting out of my way for things it might not kn…

Well, I'd like to differentiate between different use cases. Am I exploring an idea on a lazy afternoon or am I one of dozens contributing to a code base older than the millennium in which bugs might cause measurable loss and some top500 exec call our enterprise's exec? I wouldn't think it reasonable to expect that there is one language which suits those (and there are other) needs equally well. I know which language I'll enjoy better and which my co-workers (and potentially my later self) enjoy better. It helps to be paid for using the latter.

Re: Is your programming language unreasonable? (2015)

#110

Post by masklinn »

tzs wrote: post #90

In example #6, he gives this as the unreasonable approach: var repo = new CustomerRepository(); var customer = repo.GetById(42); Console.WriteLine(customer.Id); with the issue being customer can be null, which is not being accounted for. The reasonable approach he says is to use a sum type: var repo = new CustomerRepository(); var customerOrError = repo.GetById(42); if (customerOrError.IsCustomer) Console.WriteLine(c…

> Do most (or any) languages in which people take this approach actually enforce handling of all cases?

In "most functional languages", your result would be a sum type which requires dispatching explicitly between one case or the other, aka you wouldn't have a pair of conditionals instead you'd have something along the lines

    switch (customerOrError) {
        case IsCustomer(customer):
            Console.WriteLine(customer.ID);
        case IsError(errorMessage):
            Console.WriteLine(errorMessage);
    }
so from `customerOrError` you wouldn't have any sort of direct access to the customer or error, you must go through a dispatching construct.

In OO languages lacking sum types this sort of constructs would generally be implemented through lambdas or some sort of visitor e.g.

    customerOrError.then(
        customer => { Console.WriteLine(customer.Id); },
        onError: errorMessage => { Console.WriteLine(errorMessage) }
    );
Post reply on HN