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.
Towards Scala 3
111–120 of 383 posts
Re: Towards Scala 3
#112Earlier quoted context omitted.
F# is now supported within the .NET core world so it opens up the deployment scenarios beyond anywhere traditional .NET would live.
Not everyone is getting into .NET Core. In fact, Microsoft has to advocate library writers to actually care about .NET Core and .NET Standard. https://channel9.msdn.com/Shows/Visual-Studio-Toolbox/NET-St...
Meh, the reason many people weren't targeting .Net Core until recently was because of the huge pain in the ass it involved. .Net Standard 1.0/1.1 were missing a LOT of API surface area that many libraries needed. .Net Standard 2.0 fixes this, and makes life easier for library authors who already support multiple runtimes in the process by providing a sane upgrade path from the hell that is PCL's. It's all about tooling, there's no reason for library authors to not target .Net Standard in their projects now unless they really need some Windows/Full-specific assembly that isn't included.
Re: Towards Scala 3
#113There are a lot of comments pointing out pros and cons of Scala, comparing it to other languages using superficial proxies. I'd like to share a different perspective based on my own work with OOP-centric and FP-centric languages. If you take OOP to its logical conclusion, OOP is a slippery slope that eventually leads to Gang-Of-Four centric designs. If you take FP to its logical conclusion, FP is a slippery slope tha…
> If you take FP to its logical conclusion, FP is a slippery slope that eventually leads to Monad-Transformer centric designs. I don't understand what you mean by this, and I write production haskell for a living. We don't have teetering towers of transformers, and the best advice I've seen is often "put away the shiny tools and just use functions", https://lukepalmer.wordpress.com/2010/01/24/haskell-antipatt... . Si…
>I don't understand what you mean by this, and I write production haskell for a living.
Well, "It is difficult to get a man to understand something when his salary depends upon his not understanding it" - Upton Sinclair
Re: Towards Scala 3
#114So many cool things already done and even more to come. Some parts that excite me as a Scala nerd:
* One can now use implicit function types to basically build your own table language syntax that is type-safe. [1]
* Multiversal Equality: you get to decide whether it makes any sense to compare an Apple and an Orange using "==" or "!=", as opposed to Java's forced requirement of allowing you to compare anything with anything. [2]
* Null safety checks! Quoting from [3], "Adding a null value to every type has been called a "Billion Dollar Mistake" by its inventor, Tony Hoare. With the introduction of union types, we can now do better. A type like String will not carry the null value. To express that a value can be null, one will use the union type String | Null instead."
* First-class enums, finally. [4]
* Erased parameters: you can declare variables specifically for type-safety that _don't exist_ during run-time, improving efficiency. [5]
[1] http://dotty.epfl.ch/docs/reference/implicit-function-types....
[2] http://dotty.epfl.ch/docs/reference/multiversal-equality.htm...
[3] http://dotty.epfl.ch/docs/reference/overview.html
Re: Towards Scala 3
#115Earlier quoted context omitted.
About GUI on .NET Framework: - Windows form works but not perfect. The editor works if you install the template for it, but not the auto generation of code, like double click on button -> handler generated. You write code programmatically. but is used a lot. I use it in the repl (fsi), to generate chart, custom data visualization. - WPF the same, works, no editor (but codegen is less needed) - Xamarin support F# ( ht…
GUI development without designer support is just like time traveling to implementing Turbo Vision and Clipper applications on MS-DOS. Never understood the mentality for designing UIs by coding instead of visually. I care for what comes in the box, and is directly supported by Visual Studio and Blend. If someone needs to lose their .NET GUI tooling productivity to embrace F#, then better wait while C# keeps getting F#…
Ever heard of the web?
Re: Towards Scala 3
#116There are a lot of comments pointing out pros and cons of Scala, comparing it to other languages using superficial proxies. I'd like to share a different perspective based on my own work with OOP-centric and FP-centric languages. If you take OOP to its logical conclusion, OOP is a slippery slope that eventually leads to Gang-Of-Four centric designs. If you take FP to its logical conclusion, FP is a slippery slope tha…
I disagree with that. Haskell is category theory as a language. The Scala community got invaded by Haskellites trying to turn Scala into Haskell, but there’s a particular style of OOP/FP hybrid that requires a language like Scala to use/teach/explore. The problem is that in creating the tool to enable that, we ended up with a language that was too big to have a coherent style, which led to an incredibly fractured com…
Haskell is category theory
as a language.
One of Odersky's motives in creating Scala was bringing the power of Haskell into the JVM world, although this is not the only motive (tight integration of OO and FP being another).
Haskell's key innovation over its predecessors (Miranda and ML) was the addition of higher-kinded types, which in turn made ad-hoc polymorphism digestable in a typed world (in the form of type-classes). The combination of HKTs and type-classes enables the monadic abstractions that contemporary Haskell programming is widely known for today.
Note that Scala has HKTs and type classes (via implicits), so Haskell programs can typically transliterated into idiomatic Scala without major complications.
[1] P. Hudak, J. Hughes, S. Peyton Jones, P. Wadler, A History of Haskell: Being Lazy With Class. http://haskell.cs.yale.edu/wp-content/uploads/2011/02/histor...
[2] Interview with Simon Peyton-Jones. http://www.cs.cmu.edu/~popl-interviews/peytonjones.html
[3] E. Moggi, Notions of Computation and Monads. https://core.ac.uk/download/pdf/21173011.pdf
Re: Towards Scala 3
#117Earlier quoted context omitted.
Not everyone is getting into .NET Core. In fact, Microsoft has to advocate library writers to actually care about .NET Core and .NET Standard. https://channel9.msdn.com/Shows/Visual-Studio-Toolbox/NET-St...
How is this relevant to the discussion though? F# works on either .NET Core or the regular .NET Framework.
Eh, it mostly works on .Net Core. There's still some bugs with the compiler around Generative Type Providers when running the compiler on the .Net Core runtime, forcing you to compile with a build of fsc running on mono or the full .Net Framework.
Still, for all intents and purposes you are correct - but there's still some growing pains in the tooling that are hard to ignore.
Re: Towards Scala 3
#118...ships in 2020?
I'm impressed with what they're doing (and love the language), and it's hard work, and their speed is faster than, say, Java's dead-pace evolution in the 2000s.
But, poking around at TypeScript, I've been blown away with the MS/TS speed of development. ~2-3 month release cycles, with non-trivial changes to the language (mapped types, conditional types, etc.), that are themselves unique/novel type system features, not like Java finally getting around to copying the obvious/best-practice approach to case/data classes.
Granted, I'm sure the MS/TypeScript budget is huge comparatively...
Seems like that's the "best" (realistic) way for dev tooling to evolve lately: come from, or attach yourself to, a ~top-5 tech company that makes their money somewhere else and can bankroll developer tools/languages (e.g. MS with TS, FB with React/Flow, Google with a myriad of things e.g. Dart & AdWords, Go).
Bringing it back to Scala, seems like they were close to this (flirted with adoption/sponsorship from a few startups like FourSquare, etc.) but, thinking about it now, "software development in the large" is a huge concern for those companies (e.g. anyone with enough extra money to actually pay for language/tooling improvements), and that's never really been Scala's strong suit (compile times, painless compiler upgrades).
Re: Towards Scala 3
#119Earlier quoted context omitted.
About GUI on .NET Framework: - Windows form works but not perfect. The editor works if you install the template for it, but not the auto generation of code, like double click on button -> handler generated. You write code programmatically. but is used a lot. I use it in the repl (fsi), to generate chart, custom data visualization. - WPF the same, works, no editor (but codegen is less needed) - Xamarin support F# ( ht…
GUI development without designer support is just like time traveling to implementing Turbo Vision and Clipper applications on MS-DOS. Never understood the mentality for designing UIs by coding instead of visually. I care for what comes in the box, and is directly supported by Visual Studio and Blend. If someone needs to lose their .NET GUI tooling productivity to embrace F#, then better wait while C# keeps getting F#…
Depends for what you need GUI.
You need it for complex LOB app? So no, editor will be good.
Personally, i write c# and xaml, and i dont use the editor (vs or blend), but i edit directly the xaml.
About f# and gui, depends on use case. For example https://fslab.org/XPlot/ to show graphs.
let series = [ "bars"; "bars"; "bars"; "lines" ]
let inputs = [ Bolivia; Ecuador; Madagascar; Average ]
inputs
|> Chart.Combo
|> Chart.WithOptions
(Options(title = "Coffee Production", series =
[| for typ in series -> Series(typ) |]))
|> Chart.WithLabels
["Bolivia"; "Ecuador"; "Madagascar"; "Average"]
|> Chart.WithLegend true
|> Chart.WithSize (600, 250)
But yes, if you use editor like c# version, F# is less nice to use. But again, programmatically allow other things, like https://github.com/fsprojects/Elmish.XamarinForms
So depends how much time you edit the view (and why), vs gains in the logic behind the view. For me the global tradeoff, but depends, so you are right.
Re: Towards Scala 3
#120Earlier quoted context omitted.
> Also many open source libraries in Scala land have a very short life time and will not be upgraded to Scala3. No problem with Java, but it will take months for many larger projects to remove Scala2 library dependencies from their code base. The announcement says Scala 3 will be able to call Scala 2 libraries, so even if you're right (which is not my experience of open-source Scala libraries at all FWIW) this won't…
Yes I've read that point, but a.) it means not 2 but 2.12 b.) what happens if the 2.12 class file depends on old Scala library code? "this won't be an issue." After a decade of Scala usage and a several 100k line project to code on, I'll believe it when I see it.
> what happens if the 2.12 class file depends on old Scala library code?
Not possible - 2.12 is source- but not binary-compatible with 2.11, any "2.12 class file" will only have 2.12 dependencies.
So we're talking about the release planned for 2020 having binary compatibility back to 2016 and source compatibility back to 2014. Not the same level of backwards compatibility as Java by any means, but better than many languages offer.