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

Re: Is your programming language unreasonable? (2015)

#81

Post by alkonaut » Sat, Oct 10, 2020, 3:12 PM UTC

joshsyn wrote: post #74

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…

How is it avoiding subtle bugs? Looks like a sane default to me

Which default is default though? An ordinal comparison? Or system-local one? (E.g one that considers a German ß equal to “ss” or one that doesn’t?).

On that same note, coming from a country that uses decimal comma, I very much would prefer it if code always had to specify a target locale when printing a decimal number.

Re: Is your programming language unreasonable? (2015)

#82

Post by qsort » Sat, Oct 10, 2020, 3:25 PM UTC

scns wrote: post #72

mwcampbell wrote: post #65

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?

I would bet my money on Bucklescript/ReasonML/ReScript. https://github.com/rescript-lang/rescript-compiler/wiki/Why-... https://www.javierchavarri.com/performance-of-records-in-buc... Its Standard library Belt is optimized to compile to efficient JS too. (edit: added line about Belt)

Is Reason even actively developed these days? Isn't it sort of a dead project, or have I misunderstood something?

Re: Is your programming language unreasonable? (2015)

#83

Post by z3t4 » Sat, Oct 10, 2020, 3:25 PM UTC

I agree that the more stuff the language lets you do - the more people will abuse it. But there is also a productivity of higher level languages.

Re: Is your programming language unreasonable? (2015)

#84

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

qsort wrote: post #82

scns wrote: post #72

Earlier quoted context omitted.

I would bet my money on Bucklescript/ReasonML/ReScript. https://github.com/rescript-lang/rescript-compiler/wiki/Why-... https://www.javierchavarri.com/performance-of-records-in-buc... Its Standard library Belt is optimized to compile to efficient JS too. (edit: added line about Belt)

Is Reason even actively developed these days? Isn't it sort of a dead project, or have I misunderstood something?

I just discovered that the BuckleScript team started a rebranding to ReScript a few months ago: https://rescript-lang.org/

Re: Is your programming language unreasonable? (2015)

#85

Post by qsort » Sat, Oct 10, 2020, 3:34 PM UTC

mwcampbell wrote: post #84

qsort wrote: post #82

Earlier quoted context omitted.

Is Reason even actively developed these days? Isn't it sort of a dead project, or have I misunderstood something?

I just discovered that the BuckleScript team started a rebranding to ReScript a few months ago: https://rescript-lang.org/

Yeah, that's the issue with this kind of tools, unfortunately. I myself would like a more functional-oriented approach, but realistically JS/TS is a more stable ecosystem. My go-to choices are JS for small individual projects and TS for larger projects or if a team is involved.

Re: Is your programming language unreasonable? (2015)

#86

Post by phillipcarter » Sat, Oct 10, 2020, 3:39 PM UTC

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…

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

So the C#, VB, and F# compilers (all huge, "immutable data representations" codebases serving millions of developers worldwide) are training wheels?

Re: Is your programming language unreasonable? (2015)

#87

Post by adwn » Sat, Oct 10, 2020, 3:53 PM UTC

dunefox wrote: post #43

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'm assuming that comment was written by a bot, tbh.

Judging by that user's other comments, you're probably right.

Re: Is your programming language unreasonable? (2015)

#88

Post by jasonhansel » Sat, Oct 10, 2020, 3:57 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…

Linear types fix this problem, by letting you prove to the compiler that logically immutable operations can be implemented as in-place updates.

Re: Is your programming language unreasonable? (2015)

#89

Post by lostcolony » Sat, Oct 10, 2020, 4:01 PM UTC

alkonaut wrote: post #80

lostcolony wrote: post #73

Earlier quoted context omitted.

'You cannot program without mutation in the general case. You simply don’t always have the performance/power budget for it.' So by 'general case' you mean 'every case'? Because to my mind, those instances you don't have the performance/power budget for 'it' are very much special cases, not general ones. It also seems a curious distinction; I mean, Python and Ruby both allow for mutable data, but are quite slow and me…

I mean for a programming language to be able to handle the general cases it should also handle the maybe 10% or 20% of programs that might need mutation in their hot paths. Obviously one solution is to call out to a different programing language for only the areas that require it, but I’d consider that a definite deficiency if it’s commonly required. I think e.g C# and F# handle mutation well, but I think F# does the…

"Depends on what problems you are solving I suppose. " - well, yes. Hence my question about what you're defining as the general case; that 10-20% seems rather high for cases you'd need mutability.

I think it's a bit of a red herring to ask "can you solve them quickly enough" - after all, if pure speed across all use cases is your concern, why would you advocate a garbage collected language?

Re: Is your programming language unreasonable? (2015)

#90

Post by tzs » Sat, Oct 10, 2020, 4:07 PM UTC

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(customerOrError.Customer.Id);
  if (customerOrError.IsError)
      Console.WriteLine(customerOrError.ErrorMessage);

Do most (or any) languages in which people take this approach actually enforce handling of all cases? Or could a programmer write that this way:

  var repo = new CustomerRepository();
  var customerOrError = repo.GetById(42);
  Console.WriteLine(customerOrError.Customer.Id);

and still have the same problem as the original?

It seems to me that the "reasonable" version is getting its reasonableness from naming the variable that gets the GetById return "customerOrError" which reminds the reader that there is an error case, not from the language having sum types. That's just a convention. Nothing stops you from naming it "customer" just like in the "unreasonable" language.

(I'd actually expect that from a lot of people, because you are probably going to have a lot more code in the case that you have gotten the Customer variant than in the Error variant case, and you probably don't want to be calling it customerOrError in the 99% of the code where you know that it is a Customer).