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

51–60 of 161 posts

Re: Reasonable Scala Compiler

#51

Post by clhodapp »

bmc7505 wrote: post #40
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.

Kotlin? 1. OOP: https://www.packtpub.com/mapt/book/application_development/9... 2. FP: https://blog.plan99.net/kotlin-fp-3bf63a17d64a 3. Concurrency: https://kotlinlang.org/docs/reference/coroutines.html 4. Native: https://github.com/JetBrains/kotlin-native 5. Simple: https://try.kotlinlang.org/

The thing that Scala has and Kotlin completely lacks is the tooling to allow you to avoid runtime reflection. Typeclasses and macros (and especially both together) are way too powerful-yet-principled to give up once you're used to them.

Re: Reasonable Scala Compiler

#52

Post by willtim »

jonathanyc wrote: post #38
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.

It seems to me like OCaml has all of those features except for #3 (which admittedly is pretty frustrating to me too). What do you think?

Depends on what you mean by concurrency support. OCaml has nice green threads via Lwt.

Re: Reasonable Scala Compiler

#53

Post by iLemming »

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.

> even though that's not difficult

Turns out to be quite arduous:

- You ask for reasonable support for both object-oriented and functional programming, this already contradicts with the notion of state (that objects suppose to contain in OOP) and "stateless" ways of FP, let's ignore that for a moment

- FP means different things for different people - some would argue it has to have well thought type system, but what exactly that means? Is strongly but dynamically typed like in Clojure is okay (with added sugar like Clojure.spec)? Or it has to have static types? Does it have to have then type inference like in Elm? Or definitely it has to have algebraic data types like in Haskell? Or maybe dependent types like in Idris?

- Concurrency models vary too, for example: STM in Clojure and Haskell aren't exactly the same. Actor model in Erlang is a beast and sounds awesome on paper, but in real life process coordination may become a headache. Primitives based on CSP model are also known to have their own quirks. Concurrency in any language is never simple and straightforward.

- You're asking for an fast FP language - with immutable data structures and lazy/non-strict evaluation it's probably unrealistic to get it to run as fast as native code

- And "simple to learn" is also very subjective quality - for some Python is easy, but Clojure is hard. For some Haskell is not that difficult as people describe it. For some it feels like insurmountable mountain.

As you can see - it's not that simple. And we probably not gonna get a "perfect" language that suits everyone anytime soon.

Re: Reasonable Scala Compiler

#55

Post by Joeri »

hasenj wrote: post #33
carlosdp wrote: post #4

Earlier quoted context omitted.

That's... not true. You mention Kotlin, that was developed by JetBrains as a better language to develop Intellij and plugins. Hack/HHVM was developed by Facebook to modernize PHP. There are plenty of cases where organizations successfully developed their own languages/compilers that gave them advantages. It's insane only if you have no good reason to do it. This sounds like they have a need: compile times are slow.

> Hack/HHVM was developed by Facebook to modernize PHP. Yes but why use PHP in the first place? It's not the right tool for something like Facebook.

In 2003 PHP was the most sensible choice for rapid prototyping of a web app and for early facebook it was more important to iterate and experiment than build it right. Even today it still holds its own, but there are plenty of alternatives (rails, node.js, ...)

Re: Reasonable Scala Compiler

#56

Post by skrebbel »

jankotek wrote: post #30

> Identify a subset of Scala that can be compiled with reasonable speed I am afraid of Scala fragmentation. There is no way new compiler can be 100% compatible. Hopefully it will be tested on major projects, or there will be some official Scala Language spec. It would be nice to add a switch into old scalac, which downgrades its features, to make it compatible with new scalac. I believe Scala has too many features, a…

> Hopefully it will be tested on major projects

Twitter has pretty big resources. It's probably feasible for them to spin up a build farm that runs their compiler against all active Scala projects on GitHub, measuring error count and compilation speed as they go along.

Re: Reasonable Scala Compiler

#57

Post by didibus »

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.

These all exist, you just don't agree with them being reasonable:

Scala, Common Lisp, C++, D, Clojure, F#, OCaml, Kotlin, etc. Those could all count or not depending on your subjective opinion.

The truth is, it is difficult to create the perfect language, and any sufficiently complete language will always start to have part of it that suffer in exchange.

Re: Reasonable Scala Compiler

#58

Post by harpocrates »

jankotek wrote: post #30

> Identify a subset of Scala that can be compiled with reasonable speed I am afraid of Scala fragmentation. There is no way new compiler can be 100% compatible. Hopefully it will be tested on major projects, or there will be some official Scala Language spec. It would be nice to add a switch into old scalac, which downgrades its features, to make it compatible with new scalac. I believe Scala has too many features, a…

> There is no way new compiler can be 100% compatible. Hopefully it will be tested on major projects, or there will be some official Scala Language spec.

I, for one, think that an official language spec would do the language a lot of good. As it stands, it is sometimes difficult to separate bugs from features in scalac...

Re: Reasonable Scala Compiler

#59

Post by eip »

needusername wrote: post #17

I'm a bit confused. I have been told multiple times by Scala users that Scala compile times are a non-issue.

I don't have any issues with compile times. But I don't work on an underpowered Crapbook Pro.

If you are serious about your work and time than use serious hardware.

You don't see see F1 racers show up on race day with a Scooty Puff Jr..

Re: Reasonable Scala Compiler

#60

Post by majidazimi »

iLemming wrote: post #53
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.

> even though that's not difficult Turns out to be quite arduous: - You ask for reasonable support for both object-oriented and functional programming, this already contradicts with the notion of state (that objects suppose to contain in OOP) and "stateless" ways of FP, let's ignore that for a moment - FP means different things for different people - some would argue it has to have well thought type system, but what…

I would argue Scala already has all of them but the last one. However there are shit load of absolutely unnecessary features in the language. As the parent link states, twitter just removed shitty features and there you go: An easy to use Object/Functional language which runs fast and has awesome concurrency features.
Post reply on HN