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

Reasonable Scala Compiler

github.com

Post reply on HN
Print view View original

131–140 of 161 posts

Re: Reasonable Scala Compiler

#131

Post by devdoomari »

harveywi wrote: post #127
smitherfield wrote: post #125

Earlier quoted context omitted.

Not a trendy language by any means, but C# meets all your criteria. 1. About the strongest OOP support of any language which doesn’t have a dynamic or Scala-esque exotic type system. Also supports non-OOP imperative, unlike Java. 2. Linq is nigh-on the best FP support offered in any non-FP language’s standard library, and really is one of the best FP libraries period. 3. Invented async/await, by far the most ergonomi…

I had used Scala for many years before trying C#, and I have to agree. The only thing that I really missed in C# were higher-kinded types.

There's F# and then there's "F* " language that seem to have higher-kinded types

(I really mean F* as in 'F-star' language)

Re: Reasonable Scala Compiler

#132

Post by catnaroek »

tome wrote: post #77
catnaroek wrote: post #65

Earlier quoted context omitted.

> Scala, Common Lisp, C++, D, Clojure, F#, OCaml, Kotlin, etc. Out of those, only OCaml really provides “reasonable” support for functional programming. The ability to manipulate compound values (say, lists or trees) directly, without using objects having a queryable physical identity, is of course a prerequisite. > it is difficult to create the perfect language, and any sufficiently complete language (...) Maybe the…

F# allows you to distinguish values by identity?

You can always query the identity of the .NET object that underlies a putative compound value.

Re: Reasonable Scala Compiler

#133

Post by wpietri »

Huzzah! Maybe this is already in the works, but I would love to see a compiler that stays hot in RAM and works incrementally.

RAM is cheap nowadays, and the number one reason I want a fast compiler is to speed up my feedback cycle between making a change and evaluating the effects of the change. So I want something that squats on a large chunk of RAM and works in parallel with me, updating with every edit I make.

Re: Reasonable Scala Compiler

#134

Post by catnaroek »

loup-vaillant wrote: post #117
stewbrew wrote: post #82

Earlier quoted context omitted.

While OCaml might be the most reasonable in theory, AFAIK opam on Windows still doesn't work. Also its standard library is too minimal for my liking.

User catnaroek was only talking about support for Functional programming. And they're right: it's hard to reasonably support typed functional programming without sum types. And we're talking about a language dammit, not libraries or package managers. Let's have a good language first, then build the tools around it.

It's even worse: it's hard to reasonably support functional programming, typed or untyped, when list and tree values aren't directly expressible in the language's semantics. If you need a social convention not to query physical object identities, you have already lost.

Re: Reasonable Scala Compiler

#135

Post by catnaroek »

stewbrew wrote: post #82
catnaroek wrote: post #65

Earlier quoted context omitted.

> Scala, Common Lisp, C++, D, Clojure, F#, OCaml, Kotlin, etc. Out of those, only OCaml really provides “reasonable” support for functional programming. The ability to manipulate compound values (say, lists or trees) directly, without using objects having a queryable physical identity, is of course a prerequisite. > it is difficult to create the perfect language, and any sufficiently complete language (...) Maybe the…

While OCaml might be the most reasonable in theory, AFAIK opam on Windows still doesn't work. Also its standard library is too minimal for my liking.

The lack of a good standard library can always be fixed: write one. OTOH, language semantics issues can't be fixed without redefining the language, invalidating all code that has already been written in it.

Re: Reasonable Scala Compiler

#136

Post by edem »

Writing a reasonable compiler would need a reasonable language, no? Scala had its chance in the last 13 years now it is time for this abomination to go.

Re: Reasonable Scala Compiler

#137

Post by 16bytes »

harveywi wrote: post #127
smitherfield wrote: post #125

Earlier quoted context omitted.

Not a trendy language by any means, but C# meets all your criteria. 1. About the strongest OOP support of any language which doesn’t have a dynamic or Scala-esque exotic type system. Also supports non-OOP imperative, unlike Java. 2. Linq is nigh-on the best FP support offered in any non-FP language’s standard library, and really is one of the best FP libraries period. 3. Invented async/await, by far the most ergonomi…

I had used Scala for many years before trying C#, and I have to agree. The only thing that I really missed in C# were higher-kinded types.

I think I'd miss pattern matching the most.

The first time I saw how pattern matching with regular expressions automatically extracted the matching bits I was sold.

I'd also miss block expressions. I keep wanting to write if-expressions (as opposed to if-statements) in every non-scala language I touch.

But I agree, c#/.net is a good alternative if you're used to the expressiveness of scala.

Re: Reasonable Scala Compiler

#138

Post by DeepRote »

edem wrote: post #136

Writing a reasonable compiler would need a reasonable language, no? Scala had its chance in the last 13 years now it is time for this abomination to go.

Scala is a great language. There's room to shoot yourself in the foot, but maybe you should watch your muzzle more if you're having that problem.

Imo the biggest obstacle in scalaverse is sbt and implicits. 10000% the two things I have to devote extra time to when showing somebody the ropes.

Re: Reasonable Scala Compiler

#139

Post by _lbaq »

wpietri wrote: post #133

Huzzah! Maybe this is already in the works, but I would love to see a compiler that stays hot in RAM and works incrementally. RAM is cheap nowadays, and the number one reason I want a fast compiler is to speed up my feedback cycle between making a change and evaluating the effects of the change. So I want something that squats on a large chunk of RAM and works in parallel with me, updating with every edit I make.

SBT always runs Scalac in the same VM, so it will be hot and JIT compiled after a few passes.

Intellij implemented a SBT Shell in 2017.1, so it will keep the same SBT session going between passes also.

Re: Reasonable Scala Compiler

#140

Post by colefichter »

smitherfield wrote: post #125
majidazimi wrote: post #35

This truly means we still lack a programming language with: 1. reasonable support of object oriented programming. 2. reasonable support of functional programming. 3. solid concurrency features. 4. runs comparable to native code. 5. simple to learn. Even though it is not difficult to create such a language but we see a new language poping out every now and then and none of them try to solve these issues.

Not a trendy language by any means, but C# meets all your criteria. 1. About the strongest OOP support of any language which doesn’t have a dynamic or Scala-esque exotic type system. Also supports non-OOP imperative, unlike Java. 2. Linq is nigh-on the best FP support offered in any non-FP language’s standard library, and really is one of the best FP libraries period. 3. Invented async/await, by far the most ergonomi…

> 3. Invented async/await, by far the most ergonomic concurrency primitive yet created.

This feels like a bit of hyperbole. The actor model seems much more intuitive than async/await. Indeed, message passing between actors is how concurrency works in the real world (think about how people interact with each other).

Post reply on HN