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

Towards Scala 3

scala-lang.org

Post reply on HN
Print view View original

361–370 of 383 posts

Re: Towards Scala 3

#361

Post by lptk »

YorkshireSeason wrote: post #360
lptk wrote: post #356

Earlier quoted context omitted.

Your example of nested functions with default arguments does not correspond to what derived implicits do. As a result of implicit resolution, an expression with an arbitrary number of subexpressions may be synthesized, the shape of which depends on the types involves. Default parameters simply cannot do that. The example you give to justify "recursion is quite restricted" is not a restriction on recursion at all, it'…

> does not correspond to what derived implicits do I did not claim it did. The first example disproved ionforce's claim that default values cannot be constructed dynamically. > Define `a` as `y` to shadow the function parameter, Whoops, yes that's correct. I didn't realise this was possible.

> The first example disproved ionforce's claim that default values cannot be constructed dynamically.

But I don't think that is what they meant. I think they meant something along the lines of what I said above:

> an expression with an arbitrary number of subexpressions may be synthesized, the shape of which depends on the types involves

Re: Towards Scala 3

#362

Post by dionian »

lmm wrote: post #105
realusername wrote: post #75

Earlier quoted context omitted.

I would start with operators and operator overrides, most of the time they don't make sense and it's difficult to know what it does, that's why most other languages banned them. Secondly, the implicit concept makes the code difficult to read. Then I would add that the differentiation between function & variable isn't always clear and sometimes you don't know what you call.

> I would start with operators and operator overrides, most of the time they don't make sense and it's difficult to know what it does, that's why most other languages banned them. Yeah, that's what I was talking about - in Scala operators are just functions, and badly named operators are an issue with some libraries rather than an issue with the language. They're unfortunate, but all one can really do is avoid them -…

most of these criticisms I agree with but I don't blame scala as a language for it. I write, and encourage my colleagues to write, code that is very easy to follow and reckon about. Few obscure operators, almost zero implicits....

Re: Towards Scala 3

#363

Post by dionian »

MrBuddyCasino wrote: post #78
Cyph0n wrote: post #53

Earlier quoted context omitted.

Implicits are very powerful when used correctly, but are terrible if not.

If " is very powerful when used correctly, but terrible if not": think long and hard before adding to a language.

which is why I'd be against adding them in Java and favor keeping the power in scala.

Re: Towards Scala 3

#364

Post by room271 »

jvican wrote: post #340
room271 wrote: post #138

As a heavy Scala user I'm excited by this. But really I don't think it will improve Scala adoption because the blockers there are all around developer experience (tooling is terrible - sbt, and feedback cycles are very slow). Personally, for a lot of my current use cases (APIs) I'm veering towards Go more and more as I find it a lot more productive.

At the Scala Center we’re working on addressing these problems. We now have working groups devoted to ease coding in Scala and make it easier for any dev to use any build tool.

That's great news! Thanks for the reply.

Re: Towards Scala 3

#365

Post by pjmlp »

AsyncAwait wrote: post #350
Cyph0n wrote: post #265

Earlier quoted context omitted.

> I know. So why did you refer to Kotlin on the JVM? > No, Kotlin Native can interface with GDB or LLDB, they're charging for CLion which provides a GUI interface atop of these. Cool, thanks for the response.

> So why did you refer to Kotlin on the JVM? Because I was trying to explain that the only reason Kotlin/Native is tied to (paid) CLion is because that's the only IDE where JetBrains have native GDB/LLDB integration, not that they charge for a debugger, which is demonstrated by the fact that where there would be the most potential customers, (JVM Kotlin users), they don't charge anything. The only reason they charge…

They are charging for the experience of using a GUI based debugger.

I don't remember when it was the last time I was forced to use a command line debugger even for C and C++, typing s, n, l, p all the time. Maybe around 2000 or so.

Re: Towards Scala 3

#366

Post by lomnakkus »

pacala wrote: post #161
jrq wrote: post #122

Disclaimer : I'm nobody important, but I do have an opinion If scala team were to disavow sbt, that'd be the single best thing they could possibly do for the ecosystem. I used to write a lot of scala, and working with sbt was enough to eventually get under my skin. I really like some of the OOP aspects of scala, the left-to-right style of thinking matches how my brain works. Scala having a lot to offer can distract n…

> If scala team were to disavow sbt, that'd be the single best thing they could possibly do for the ecosystem. Seconded. Between http://www.lihaoyi.com/mill/ and https://bazel.build/ , there are plenty of alternatives.

If you look at what they currently support in terms of plugin availability and stability these are nowhere near being viable alternatives at the moment.

The only remotely viable alternative to SBT I've found is Pants. (I guess Maven and Gradle might qualify too, but it's been so long since I've used them with Scala that I can't be sure.)

Re: Towards Scala 3

#367

Post by lomnakkus »

stephen wrote: post #121
framebit wrote: post #111

I saw a presentation recently on Mill[1] which looks extremely promising and looks poised to remove the giant Scala development headache of working with SBT. [1] https://github.com/lihaoyi/mill

sbt is terrible, and I have a lot of respect for Li as "the scala.js guy", but I'm slightly baffled that YABT (yet another build tool) was really necessary vs. just making the existing (say) gradle experience super-polished. Granted, it's probably more fun to start from scratch :-), just seems more realistic for long-term adoption/maintainability to leverage existing tools.

The models of SBT/Gradle/Maven are broken, or at least, that's the premise for writing these build tools.

The model of Mill, Bazel, Buck, Pants are fundamentally different in very important ways which allow e.g. using a shared build cache across all the developers in a team (or even all the developers in a whole company if one takes the monorepo approach for absolutely everything). This is not something that can be retrofitted into, say, SBT or Gradle.

Re: Towards Scala 3

#368

Post by lomnakkus »

yawaramin wrote: post #332
lmm wrote: post #199

Earlier quoted context omitted.

OCaml users tend to avoid its object system, so while it attempted to fuse object-oriented and functional I don't think we can say it succeeded. F# is, as you say, later.

OCamlers tend to avoid OOP mostly because we can get away with modules, functors, polymorphic variants to model subtyping, and now also GADTs and open variant types to precisely model and add cases. When we do need to use it, it is actually pretty elegant and well-designed. It's just that since we've tasted the power of the more functional abstraction techniques, OOP loses its allure.

Indeed. I think that what OCaml proved is that the "O" isn't actually necessary. :)

Re: Towards Scala 3

#369

Post by yawaramin »

lptk wrote: post #359
yawaramin wrote: post #326

Earlier quoted context omitted.

See this talk https://youtu.be/P8jrvyxHodU He mentions module systems fairly early on.

What does this have to do with the original assertion that "one of Odersky's motives in creating Scala was bringing the power of Haskell into the JVM world"? AFAIK, Odersky doesn't particularly like people trying to replicate Haskell patterns in Scala. For example, he thinks using monads for most effects is inappropriate.

Threading fail. I thought I was replying to someone who had asked for a citation for:

> Odersky has long claimed ML as his primary functional programming influence, not Haskell.

Re: Towards Scala 3

#370

Post by stephen »

lomnakkus wrote: post #367
stephen wrote: post #121

Earlier quoted context omitted.

sbt is terrible, and I have a lot of respect for Li as "the scala.js guy", but I'm slightly baffled that YABT (yet another build tool) was really necessary vs. just making the existing (say) gradle experience super-polished. Granted, it's probably more fun to start from scratch :-), just seems more realistic for long-term adoption/maintainability to leverage existing tools.

The models of SBT/Gradle/Maven are broken, or at least, that's the premise for writing these build tools. The model of Mill, Bazel, Buck, Pants are fundamentally different in very important ways which allow e.g. using a shared build cache across all the developers in a team (or even all the developers in a whole company if one takes the monorepo approach for absolutely everything). This is not something that can be r…

Gradle does have a build cache, which can be local or remote:

https://docs.gradle.org/current/userguide/build_cache.html

It is a newer feature, so that might be why you're unaware of it.

Also, I get that the models of Bazel/Buck/Pants are fundamentally different, because they are inherently cross-language / "sit on top of other compilers" systems. And are best for mono repos.

But Mill doesn't fit in that camp AFAICT.

Post reply on HN