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

21–30 of 138 posts

Re: Is your programming language unreasonable? (2015)

#21

Post by ColinWright »

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?

Re: Is your programming language unreasonable? (2015)

#22

Post by rightbyte »

Smaug123 wrote: post #9
gitgud wrote: post #4

> " 4. Objects must always be initialized to a valid state. Not doing so is a compile-time error. " So this essentially means there can never be a NULL object assigned to anything... how is this possible? is it avoided by throwing exceptions instead of returning NULL?

If you forget everything you ever learned about programming, and then I ask you for an integer, you're never in a million years going to reply "null"; the existence of "null" is something you had to learn. A language could simply not have a concept of "null". Even an OO language could have no concept of "null". In practice, it's useful to be able to answer "I'm sorry, Dave, I can't do that". Some languages do that by…

Null is just an invalid pointer target that you can verify easely. It is just abi convenience and removes the need for a flag.

On the other hand I unironicly write goto:s and use globals as much as a please (think GNU Bison/Flex) so who I am to judge.

Re: Is your programming language unreasonable? (2015)

#23

Post by sullyj3 »

tremon wrote: post #15
gitgud wrote: post #4

> " 4. Objects must always be initialized to a valid state. Not doing so is a compile-time error. " So this essentially means there can never be a NULL object assigned to anything... how is this possible? is it avoided by throwing exceptions instead of returning NULL?

Not only that, it implies that there must be a valid null-state for every type, which is also a bad idea.

I'm not entirely sure what you're getting at here. Are you saying the author is arguing a call like

  new Customer()
should return something valid? I think the FP way would be to disallow constructor overloads with no arguments, as really, there's no reasonable thing to be done here. If you don't have all the necessary information to initialize a customer yet, you don't get to initialize one, and you pass around a partially applied constructor function instead.

ie, The argument is that (in pseudocode):

  Customer(name = "Jimmy", address = null)
is not really a customer if address is a necessary piece of information, so we should distinguish at the type level by passing around a function that takes the address and returns the correctly initialized Customer like so

  \addr -> Customer(name = "Jimmy", address = addr)
Admittedly, this prevents you from accessing name until you provide an address, but I don't think there are many valid use cases where you want to access data before the Customer value is corrrectly initialized. I'd consider this a code smell to be refactored.

Re: Is your programming language unreasonable? (2015)

#24

Post by lmm »

tremon wrote: post #15
gitgud wrote: post #4

> " 4. Objects must always be initialized to a valid state. Not doing so is a compile-time error. " So this essentially means there can never be a NULL object assigned to anything... how is this possible? is it avoided by throwing exceptions instead of returning NULL?

Not only that, it implies that there must be a valid null-state for every type, which is also a bad idea.

No it doesn't; the whole point is to avoid every type having a null state. You only define null states for those types for which it's semantically valid. For most types, you just don't have a null state and don't allow them to be constructed in an invalid state.

Re: Is your programming language unreasonable? (2015)

#25

Post by lmm »

rightbyte wrote: post #22
Smaug123 wrote: post #9

Earlier quoted context omitted.

If you forget everything you ever learned about programming, and then I ask you for an integer, you're never in a million years going to reply "null"; the existence of "null" is something you had to learn. A language could simply not have a concept of "null". Even an OO language could have no concept of "null". In practice, it's useful to be able to answer "I'm sorry, Dave, I can't do that". Some languages do that by…

Null is just an invalid pointer target that you can verify easely. It is just abi convenience and removes the need for a flag. On the other hand I unironicly write goto:s and use globals as much as a please (think GNU Bison/Flex) so who I am to judge.

At ABI level you might want to use all-bits-zero to represent something other than a valid instance of your type, sure; that's how Rust's option type works. But making your language semantics say that that has to be allowed everywhere a valid instance could be passed is a mistake; for most functions it's an error to call that function without passing valid argument values, so it's better if the language has a way of enforcing that rather than forcing you to write it out by hand every time.

Re: Is your programming language unreasonable? (2015)

#26

Post by gridlockd »

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

"Once created, objects and collections must be immutable."

If this is how you want to program, fine. Don't tell me this is "the right way" to program. Immutable data structures can have a lot of overhead, which disqualifies them from many domains.

The real world is all about mutable state. At some point, you need to take the training wheels off.

Re: Is your programming language unreasonable? (2015)

#27

Post by deergomoo »

gitgud wrote: post #4

> " 4. Objects must always be initialized to a valid state. Not doing so is a compile-time error. " So this essentially means there can never be a NULL object assigned to anything... how is this possible? is it avoided by throwing exceptions instead of returning NULL?

You can still have “the absence of a value”, but it’s codified in the type system. Most languages with this feature implement an Optional or Maybe wrapper type, that is either Some or None (i.e. no value).

The difference is, because you’re now receiving a different type, you are forced to deal with the case where there’s no value.

Rather than your function returning a Customer that could sometimes be null—and if it’s only null infrequently, you’re much more likely to forget to handle it—it instead returns Optional. To operate on that Customer object, you are forced to unwrap the Optional by checking whether the underlying value is there.

How well you handle the None case is up to you, but the compiler won’t let you forget (generally anyway; for example Swift allows you to force-unwrap optionals with a crash on the None case, but eh).

Re: Is your programming language unreasonable? (2015)

#28

Post by rightbyte »

lmm wrote: post #25
rightbyte wrote: post #22

Earlier quoted context omitted.

Null is just an invalid pointer target that you can verify easely. It is just abi convenience and removes the need for a flag. On the other hand I unironicly write goto:s and use globals as much as a please (think GNU Bison/Flex) so who I am to judge.

At ABI level you might want to use all-bits-zero to represent something other than a valid instance of your type, sure; that's how Rust's option type works. But making your language semantics say that that has to be allowed everywhere a valid instance could be passed is a mistake; for most functions it's an error to call that function without passing valid argument values, so it's better if the language has a way of…

Ye some "always valid kinda a pointer"-type is nice. I wish there was some standardized compiler support for that in C, like MS kinda silly empty macros in function signatures to annotate input and output pointers etc.

Re: Is your programming language unreasonable? (2015)

#29

Post by mrkeen »

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…

I'm not sure you're contradicting the author as much as taking his argument a step further. His second example is arguing for value-equality instead of reference-equality as a saner default. He created two "value-ish" Customer objects and used them to motivate his argument.

So when he writes:

>> Why not make the objects equal by default, and make reference equality testing the special case?

this refers in particular to these value objects.

I completely agree with you that InputStream should not have equals defined. A sane language would not conflate values with classes, and InputStream is not a value.

So perhaps it could be better-written as:

If defined, equality should test by value, rather than by reference.

Re: Is your programming language unreasonable? (2015)

#30

Post by dudul »

gitgud wrote: post #4

> " 4. Objects must always be initialized to a valid state. Not doing so is a compile-time error. " So this essentially means there can never be a NULL object assigned to anything... how is this possible? is it avoided by throwing exceptions instead of returning NULL?

You can represent the possible absence of value with your type system. You can use a Maybe/Option type for example.
Post reply on HN