71–80 of 161 posts
I'm a bit confused. I have been told multiple times by Scala users that Scala compile times are a non-issue.
Earlier quoted context omitted.
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, m…
* https://github.com/adamw/macwire
* https://github.com/fthomas/refined
* https://github.com/adamw/quicklens
* https://github.com/scala/scala-async
* https://github.com/typelevel/machinist
Earlier quoted context omitted.
> 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.
Earlier quoted context omitted.
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, m…
I agree that most application-level code doesn't need new macros (you rarely have to develop a new macro to add a feature to an application) but there are definitely a lot of very legitimate use-cases for them outside of Shapeless. To give just a few: * https://github.com/adamw/macwire * https://github.com/fthomas/refined * https://github.com/adamw/quicklens * https://github.com/scala/scala-async * https://github.com…
There are performance problems with inductive implicits in the current compiler; I'd rather see that fixed at the compiler level (I believe there's already a PR?) than see every library try to work around it. Actually I'd like to just build something like Shapeless' functionality into the language proper; I'd say e.g. case classes and sealed traits should have come with the equivalent of LabelledGeneric already.
I'm a bit confused. I have been told multiple times by Scala users that Scala compile times are a non-issue.
But faster compiled languages still _feel_ better.
Earlier quoted context omitted.
I agree that most application-level code doesn't need new macros (you rarely have to develop a new macro to add a feature to an application) but there are definitely a lot of very legitimate use-cases for them outside of Shapeless. To give just a few: * https://github.com/adamw/macwire * https://github.com/fthomas/refined * https://github.com/adamw/quicklens * https://github.com/scala/scala-async * https://github.com…
macwire and scala-async are bad ideas in my book (having worked on codebases that use them) and I suspect the same of machinist and refined; they're both making too big a change to the language to make sense as a library, the cost/benefit doesn't stack up. (I do think prototyping language improvements is one other thing macros are good for, but that's not something you'd do in production code). quicklens looks like a…
We'll just have to disagree on these sorts of "power tools", I think.
Quicklens does a lot more for you than Shapeless's lenses, which to my knowledge not very many people are using for new projects at this point. I think once the Cats port lands, I'll be moving to Monocle for my own stuff, though (I think this will be the trend).
Of course, the compiler getting better about inductive implicts can only be a good thing, but I do think there may be some upper limit to what can be done short of an effort similar to what Eugene is taking on with Reasonable Scala, since they are using a typechecker as an unwitting computer when we program that way. The work that Miles did to improve inductive implicit performance is tremendously helpful but it does not fully solve the problem. As an example, my very-induction-heavy codebase compiles about twice as fast with his patch enabled. That's nothing to scoff at and is super-impressive for a single patch, but it doesn't make the problem evaporate.
I fully agree with you that it would be great if Generic-like stuff were baked into the language. To me, that sort of thing is the only compelling use-case for whitebox def macros. I feel like things would be better if we could just drop those.
Earlier quoted context omitted.
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…
I'm a bit confused. I have been told multiple times by Scala users that Scala compile times are a non-issue.
Could people who have had issues with compilation speed explain their workflow, I'd like to better understand the problem.
For example, here's my general workflow:
1. code in IntelliJ until the feature/fix is complete, and there aren't any red-wavy lines in my source tree
2. run `compile` in an already running sbt session.
As a result, I only find myself "waiting" for a compile a few times a day. And even then, because I'm using the incremental compiler it's usually only a few seconds.
The only reason I run the sbt compile at all is because the IntelliJ compiler is known to be a bit buggy, especially around things like implicit resolution and some of the more advanced features used for abstract programming.
I have seen CI builds take some time, but even then, in every project I've worked on, the complete compile-time is dwarfed by the time taken to run tests.
I'm not trying to dismiss problems that others have; I would love to learn more about them!
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.
1. Solid mix of functional programming and Object oriented programming (though FP is more important - I'd gladly give up inheritance if I get good support for interfaces and traits instead)
2. Static type checking
3. Good support for efficient immutable data structures.
4. Solid concurrency features
5. Easy cross-compilation to and interaction with JS
5a. Cross-compilation to iOS and Android would be nice but it's not a dealbreaker
6. Good tooling (i.e. IDE-support, package manager)
7. A solid standard library
8. An active open source community around it
9. Said open source community should contain a good web MVC framework (or sensibly pluggable modules to the same effect)
10. A REPL
11. Sensible compilation times
So far it looks to me like only Scala and Haskell are candidates - and it sounds like Scala really struggles with the compilation times. If Reason/ocaml gained more traction it might become a contender. And if I gave up on static type checking then Clojure would be an option. And if I settled for a sprinkling of functional programming instead of having that be the basis, then Kotlin or maybe C#. Any other suggestions?
Earlier quoted context omitted.
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, m…
I agree that most application-level code doesn't need new macros (you rarely have to develop a new macro to add a feature to an application) but there are definitely a lot of very legitimate use-cases for them outside of Shapeless. To give just a few: * https://github.com/adamw/macwire * https://github.com/fthomas/refined * https://github.com/adamw/quicklens * https://github.com/scala/scala-async * https://github.com…
* https://github.com/zalando/grafter
to your list.