241–249 of 249 posts
Earlier quoted context omitted.
Ehhh, When Sun was at the helm Java was stuck in quicksand even worse than today. Its only a few years ago.
Later day SUN yes. But 1996-2005 SUN made Java the #1 name in the enterprise and education space back in the day.
Earlier quoted context omitted.
Scala is getting really interesting lately though with projects like Spark and SparkSQL. Spark takes a Scala AST tree and computes a plan on it in order to distribute it to a cluster of possibly thousands of nodes and then uses transformations on that plan, similar to how an SQL query optimizer works, to make the plan more efficient. The cluster compute benchmarks on it are crazy good. The only problem I have with Sc…
>Spark takes a Scala AST tree and computes a plan on it in order to distribute it to a cluster of possibly thousands of nodes Unless Spark has changed dramatically in the year since I used it, that's not really how it works. You lazily construct an expression graph of RDD operators but the actual Scala code (the functional payload of e.g. flatMap) doesn't get analyzed. Are you talking specifically about Spark SQL's c…
The implication of this work I thought is that it could be further expanded to other languages and DSLs. However, Spark's SQL generator still being very JVM-dependent and this optimizer generating bytecode kind of makes it pretty specific to JVM-supporting languages only. This would probably leave out Haskell and Erlang / Elixir in the short term, which is probably where I'd expect to see a different perspective on the whole data analytics front. We have Datomic, sure, (and I guess Clojure is enough for a lot of folks) but it'd be nice to have something other than "we want to make Hadoop... BUT BETTER" as a lot of the motivations.
Earlier quoted context omitted.
There's a very cool implementation of (multi-threaded!) OCaml for the JVM: http://www.ocamljava.org/
I'm upset this wasn't called Joe Camel. And marketed towards children.
Earlier quoted context omitted.
This is the thing with Microsoft is this is never in doubt. It is Google who ends of life's things and stops support. Microsoft still has supports things in Windows 8.1 that were BUGS in MS-DOS in order to allow programs from that era to run. Microsoft will support .NetCore for at least 20 years. Without doubt.
Heard of Visual Basic 6?
Earlier quoted context omitted.
What you're saying is correct, MIT vs GPL is irrelevant if Microsoft owns the whole copyright to the project. Contributors to .NET need to assign their copyright to the .NET Foundation ( http://www.dotnetfoundation.org/faq ), which seems impartial but also has a board of 100% Microsoft employees. If .NET were GPL, then only the .NET Foundation would have the power to let others create proprietary extensions, which I…
Miguel de Icaza is on the board and not an MSFT employee.
F# is a real breath of fresh air in comparison to something like Scala. It's direct ML heritage really shows, also just diving in with an IDE (like Xamarin, or I suppose Visual Studio) is super easy. I see it as the future of pop-functional programming. For example look at the way it handles type inference w/ JSON parsing. Compare that to what you have to do to parse JSON in Scala. It's subtle, but a major usability…
Also interesting is their F* language: http://fstar-lang.org/ "F* is a new higher order, effectful programming language (like ML) designed with program verification in mind. Its type system is based on a core that resembles System Fω (hence the name), but is extended with dependent types, refined monadic effects, refinement types, and higher kinds. Together, these features allow expressing precise and compact specifi…
Earlier quoted context omitted.
case class Fruit(name: String, variants: Set[String]) val fruitJson = Json.parse( """{ "name": "apple", "variants": ["cox", "braeburn"] }""") val fruit = fruitJson.as[Fruit] Doesn't seem to be too painful to me. I agree that F# is syntactically closer to ML (though Scala is closer to ML with its module system which F# gave up completely).
In this base case, no, it isn't too painful. But once you get to larger and more complicated structures, F#'s type provider system can be a tangible timesaver. Especially if you're doing exploratory programming. TBH, I think the JSON example might underrate things a bit anyway. Where type providers really start to feel impressive is when you get to tricks like being able to noodle around inside undocumented (or poorl…
If there is one thing I learned using type providers it is that maintaining your own "description"–be it as sample data or a schema file–loses most benefits of using type providers in the first case.
On the other hand, want a type provider for X in Scala? Just write it.
Stuff is still moving around because Scala devs want to get the meta APIs right first, but if adapting things from time to time is not an issue, then go ahead.
Earlier quoted context omitted.
case class Fruit(name: String, variants: Set[String]) val fruitJson = Json.parse( """{ "name": "apple", "variants": ["cox", "braeburn"] }""") val fruit = fruitJson.as[Fruit] Doesn't seem to be too painful to me. I agree that F# is syntactically closer to ML (though Scala is closer to ML with its module system which F# gave up completely).
Tell me what happens with that technique when your json has > 22 keys. ;) (Edit) this is apparently working in the latest scala 2.11 But it killed my adoption of scala for real work early on. https://issues.scala-lang.org/browse/SI-7099
I never have seen a use-case where this would have been an issue. Sure, it "looks" unfortunate, but there is only so much you can do when running on a completely uncooperative runtime.
If devs need a typed representation of unlimited length, they provide a HList and move on.
Such a representation will replace the length-limited tuples in a future version of Scala.