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

61–70 of 161 posts

Re: Reasonable Scala Compiler

#61

Post by moomin »

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.

I'd have said the fact that no-one's done it is pretty good evidence it's not as easy as you think. As plenty of people have pointed out, FP means different things to different people. But so does OO. In fact, I'd argue that Scala is about as close as you're going to get to your spec. Not helped by the fact that, as any Scalazzi could tell you, the requirements of 1 and 2 contain contradictory elements and make complexity shoot through the roof. (You can get fewer FP features and less complexity by going for F# instead.)

Personally, I like Haskell. It's great for 1 and 3, 4 is pretty acceptable and 2 gets thrown in the bin.

5 could do with some work, though.

Re: Reasonable Scala Compiler

#62

Post by hota_mazi »

clhodapp wrote: post #51
bmc7505 wrote: post #40

Earlier quoted context omitted.

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.

This has existed on the JVM for years: annotation processing.

Much less heavyweight than macros and easier to reason about.

Re: Reasonable Scala Compiler

#63

Post by zeckalpha »

hota_mazi wrote: post #3

Regardless of Scala, it's an absolutely insane idea to develop your own language to write your apps. Either stick to the real Scala or switch to Java or Kotlin, but writing your own language is a failure waiting to happen. I give this project a few more months before it gets canceled.

You posted this on hacker news, which is essentially the only app written in its language.

Re: Reasonable Scala Compiler

#64

Post by hota_mazi »

foolfoolz wrote: post #11
hota_mazi wrote: post #3

Regardless of Scala, it's an absolutely insane idea to develop your own language to write your apps. Either stick to the real Scala or switch to Java or Kotlin, but writing your own language is a failure waiting to happen. I give this project a few more months before it gets canceled.

> it's insane to write your own language > switch to Java or kotlin ah yes rewriting in a new language, the classic not-insane approach

I offered several alternatives and I made it clear they belong in a spectrum. Don't make it sound like I claimed it was binary.

If the options are "Keep writing in Scala", "Port to Kotlin" and "Write a Scala compiler", the latter is clearly the worst and most costly of all.

Re: Reasonable Scala Compiler

#65

Post by catnaroek »

didibus wrote: post #57
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.

> 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 excessive amount of features is the problem in the first place.

Re: Reasonable Scala Compiler

#66

Post by catnaroek »

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…

> FP means different things for different people

It's difficult to agree with a definition of FP that doesn't require expressing as much computation as possible as function evaluation. Functions being mappings from values to values, having a rich set of values (not the same thing as objects!) is a prerequisite.

Re: Reasonable Scala Compiler

#67

Post by ece »

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/

Scala has scala-native: https://github.com/scala-native/scala-native

Any myriad of FP (scalaz, cats), concurrency libraries (rx, akka)

scastie: https://scastie.scala-lang.org/

scala.js: https://www.scala-js.org/

This FP-focused fork of the Scala compiler: http://typelevel.org/scala/

The next gen Scala compiler called dotty: http://dotty.epfl.ch/

Twitter doesn't mention scala-native...

Re: Reasonable Scala Compiler

#68

Post by lmm »

hota_mazi wrote: post #62
clhodapp wrote: post #51

Earlier quoted context omitted.

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.

This has existed on the JVM for years: annotation processing. Much less heavyweight than macros and easier to reason about.

Annotation processing is impossible to reason about; it's equivalent to macros but much less visible.

Most Scala doesn't need macros (other than those inside shapeless) because Scala has a) higher-kinded-types, for/yield and an existing library for working with context-like types, and b) generic traversal of object graphs via shapeless. Between them those cover virtually all the use cases for annotation processing, macros or anything like that.

Re: Reasonable Scala Compiler

#69

Post by lmm »

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.

They're not a complete non-issue. They're just much less of an issue than not using Scala.

(And bear in mind that Twitter has literally the largest Scala codebase in the world. Almost all scala programmers work on something an order of magnitude smaller, with correspondingly smaller compile times)

Re: Reasonable Scala Compiler

#70

Post by clhodapp »

hota_mazi wrote: post #62
clhodapp wrote: post #51

Earlier quoted context omitted.

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.

This has existed on the JVM for years: annotation processing. Much less heavyweight than macros and easier to reason about.

In my experience, annotation processors are definitely way harder to reason about than def macros in Scala (especially blackbox ones). I find them to be about as hard to reason about as macro annotations despite being less powerful. They are also way harder to write and distribute and not at all an analogue to typeclasses.
Post reply on HN