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

True Scala complexity

yz.mit.edu

Post reply on HN
Print view View original

101–110 of 152 posts

Re: True Scala complexity

#101

Post by soc88 »

a_strange_guy wrote: post #99
soc88 wrote: post #88

Earlier quoted context omitted.

I still have not found a single comment showing "how easy it is in other languages". Do you have a link?

I'm not Parent, but I think that this is his implementation: https://github.com/nickik/Persistent-Vector-in-Dylan/blob/ma... The last part (line 222+) is what defines it as a sequence in Dylan. Dylan (and other multi-dispatch languages) don't have the problem of "adding methods to objects/classes", because methods are standalone entities (first-class, whereas in Scala the are not) that exist independently of the data…

That has nothing to do with the issues mentioned in the original article.

In fact, the thing you described is trivial in Scala.

    implicit def Upcase(s: String) = new { def upcase = s.toUpperCase }

    "abc".upcase

Re: True Scala complexity

#102

Post by runT1ME »

joshhart wrote: post #69
modersky wrote: post #32

First, I think a blog post ending with "bring on the flames" should have comments enabled, otherwise it's not really fair. It comes across as whining without wanting to listen to advice or a response. Second, I think the blog post is useful because it shows what's wrong with some (fortunately very small) part of the Scala ecosystem, and because it points to a way to fix it. Here's a quick recap: The author tries to a…

Please don't do that. I don't want to go work for some Scala shop or team in the future and find out that I'm limited to L1-only features because of management practice.

Instead you'd prefer the team to just pick Java or a lesser JVM language over Scala because they're cautious about some of the complexities implicit conversions bring?

If there was a safe, 'simpler' subset of Scala, I think you'd see a lot more adoption. And hell, once you get a job there, you can always make a good case for using some of the advanced stuff in certain parts of the code.

Unfortunately in the world we live in, not every programmer should be given the tools to let them write their own DSL as a means to accomplish their day to day tasks..

Re: True Scala complexity

#103

Post by lisper »

soc88 wrote: post #100
lisper wrote: post #98

Earlier quoted context omitted.

Maybe if you stated what you think the actual issue is in clear, unambiguous terms instead of being pissy and snarky about it this discussion will not degenerate into chaos. No, CL is not statically typed. And your point would be...?

Well ... maybe just click the link and read the article? It is pretty clear. Ahh, the famous behavior of Lisp fanatics. Tragic, how it is obvious to everyone – except themselves – why no one wants to use their language. > No, CL is not statically typed. And your point would be...? Uh ... what about a) Author complains about the inability of the compiler to prove some property of his code. b) Untyped languages – by de…

> Author complains about the inability of the compiler to prove some property of his code.

No, the author is complaining about the complexity of the language. Maybe you should go back and re-read the article. Start with the title.

> Untyped languages

Lisp is not untyped. "Not statically typed" is not synonymous with "untyped."

> Therefore, you are completely missing the point.

Which of us is missing the point remains to be seen.

Re: True Scala complexity

#104

Post by jcrites »

knuttycombe wrote: post #76
modersky wrote: post #32

First, I think a blog post ending with "bring on the flames" should have comments enabled, otherwise it's not really fair. It comes across as whining without wanting to listen to advice or a response. Second, I think the blog post is useful because it shows what's wrong with some (fortunately very small) part of the Scala ecosystem, and because it points to a way to fix it. Here's a quick recap: The author tries to a…

Implicit conversions (and implicit parameter substitution) are just about the most important feature of the Scala language, from my perspective, and I don't think it makes any sense to hide this behind a compiler switch. Just about every modern Scala library depends upon the "implicit typeclass pattern" - many of which require that you define your own typeclasses for your own code, or at least are able to correctly c…

> I know that for my own usage, Scala's benefits only really became evident once I understood implicits; before that, it was simply a slightly better Java. With implicits, it's a tool that makes Java look like COBOL

I would be interested to read any examples you may have which demonstrate this contrast.

Re: True Scala complexity

#105

Post by harryh »

akeefer wrote: post #17
harryh wrote: post #15

Earlier quoted context omitted.

"adding an additional function to the existing collections library is something that's possible in other languages" Is it possible in other statically compiled strongly typed languages? I don't think so? The advantages/disadvantages of static vs. dynamic languages seem out of scope for the "is scala too complex?" question.

See my examples below for how to do it in Gosu (via enhancements). In C# it's pretty much the same (via extension methods). Both are statically typed languages. Again, not 100% the same as Scala, and each comes with a different set of tradeoffs than the Scala approach (i.e. they're statically dispatched in Gosu), but they're certainly both reasonable, and much "simpler", solutions to the problem of "how do I add a fi…

OK I read up some on this and neither Gosu enhancement nor C# extended methods come close to what the post author is trying to attempt (adding methods to Seq and having them automatically get attached to Array, String, and CharSequence) with a single method.

So it doesn't really seem like they solve the problem "how do I add a filterMap function to all arrays or collections that works pretty much how I want it to" any simpler than Scala. All the complexity that the author brings up in his post is because he was trying to add this functionality with a single method (and a bunch of implicits).

Re: True Scala complexity

#106

Post by Dn_Ab »

jbrechtel wrote: post #89
Dn_Ab wrote: post #58

Earlier quoted context omitted.

In F# this is approximated with: type 'a IEnumerable with member this.filterMap f = [for x in this do if f x None then yield (f x).Value] let j = Map([("a",1) ; ("b",2) ]).filterMap(fun kv -> if kv.Value = 1 then Some(kv.Key,kv.Value) else None) |> Map.ofList let n = [1.;2.;4.].filterMap(fun x -> if x % 2. = 0. then Some(x**2.) else None) The extension works with any Sequence (arrays, sequences, maps,etc.) with the c…

Arrays are not sequences in Scala. They are Java arrays, not Scala sequences.

Yes, I picked this up, and was not making any statement against that. In fact I do not subscribe to the validity of his approach. But I gave a shot at seeing if I could give code that was succinct and matched.

The requirement was to add a method that works for all collections, whether platform or language specific, while preserving type. The code I gave is an approximation of a solution - to use a rough analogy: topologically speaking the code matches but loses the geometry. The code I gave works on basically all .NET collections, whether C# or F#, string or tree - as long as they implement the interface - they are matched. That it leverages the existing organization should not count against it. The failing is that although types are preserved it is under a new geometry or structure.

Re: True Scala complexity

#107

Post by Dn_Ab »

harryh wrote: post #105
akeefer wrote: post #17

Earlier quoted context omitted.

See my examples below for how to do it in Gosu (via enhancements). In C# it's pretty much the same (via extension methods). Both are statically typed languages. Again, not 100% the same as Scala, and each comes with a different set of tradeoffs than the Scala approach (i.e. they're statically dispatched in Gosu), but they're certainly both reasonable, and much "simpler", solutions to the problem of "how do I add a fi…

OK I read up some on this and neither Gosu enhancement nor C# extended methods come close to what the post author is trying to attempt (adding methods to Seq and having them automatically get attached to Array, String, and CharSequence) with a single method . So it doesn't really seem like they solve the problem "how do I add a filterMap function to all arrays or collections that works pretty much how I want it to" a…

Up top http://news.ycombinator.com/item?id=3444688 I gave working code that comes close. To be fair the reason why it gets closer (works with both F# and C# lists,arrays, sequences,dictionaries,maps,strings etc) is clerical. From this thread, I understand Scala and Java arrays are divorced.

But the problem is: put in a string and it gives back a list of characters. So I use the term it is "topologically correct" heh. To be honest I do not think there is anything functional about what he is attempting but perhaps the idioms in Scala are different? My knowledge of scala is mostly horizontal (from Ocaml,F#, haskell).

Re: True Scala complexity

#108

Post by ittayd »

modersky wrote: post #32

First, I think a blog post ending with "bring on the flames" should have comments enabled, otherwise it's not really fair. It comes across as whining without wanting to listen to advice or a response. Second, I think the blog post is useful because it shows what's wrong with some (fortunately very small) part of the Scala ecosystem, and because it points to a way to fix it. Here's a quick recap: The author tries to a…

I think that if you put a flag it effectively means removing those features from Scala, because it will declare them as dangerous. If that happens, then you have lost to Kotlin / Ceylon because these languages have an edge on Scala in terms of ecosystem (IDE / hibernate). The only chance Scala has is in allowing more sophisticated language constructs.

I think the source of the problem, at least in this blog post, is that extension methods are limited today. They are done with implicit conversion which is limited for obvious reasons I guess (not allowing type A to arbitrarily become B). I think a feature focusing just on adding extension methods is required, even if it makes the language spec larger.

Re: True Scala complexity

#109

Post by etorreborre »

OlegYch wrote: post #84

Very good post. One point with which i cannot agree is "In fact, it is impossible to insert a new method that behaves like a normal collection method. " Please see http://ideone.com/ePUHG An excerpt: import MyEnhancements._ println("qwe".quickSort) println(Array(2,0).quickSort) println(Seq(2,0).quickSort)

Miles Sabin's solution is also worth a look: https://gist.github.com/f83892f65f63b14a1f75

It uses dependent types which will be included by default in Scala 2.10. I don't consider this as "simple" but my point of view is that Computer Science is not "simple" :-). And having a language supporting that level of genericity is really helpful for type-safety and code reuse.

Re: True Scala complexity

#110

Post by gtani »

hp wrote: post #26
oacgnol wrote: post #21

I wonder how much of an impact it would be if Scala simply had better documentation . I love the terseness of the code and the complex things you can do, but I'll be damned if I could ever glean ideas from looking at method definitions rather than code examples.

I found it essential to read Martin Odersky's Programming in Scala book - if you haven't then I recommend it. It makes many things clear that can be hard to pick up using only the free online resources. There's also a new docs site and it's getting better all the time: http://docs.scala-lang.org/

There's a lot of good books on the language, this is 1st edition of staircase book, which covers 2.7, so probably the majority was written for 2.8

http://www.artima.com/pins1ed/

There's also a book manuscript (downloadable from typesafe.com, and Manning.com has 3 books in the pipeline, tho the 3rd, on FP by Tony Morris doesn't show there.

Post reply on HN