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

Scala – 1 Star – Would Not Program Again

overwatering.org

Post reply on HN
Print view View original

181–190 of 324 posts

Re: Scala – 1 Star – Would Not Program Again

#181

Post by pkolaczk »

Ygg2 wrote: post #28

What is my biggest gripe theoretical gripe about Scala is that Trait order is important! Because traits can override common function. A class that is e.g. Ball with traits Shiny and Red is NOT the same as e.g. Ball with traits Red and Shiny. Why? Why complicate testing to a point where you need not only test traits for correct behavior, and not just composing of Traits, but even the order in which they are composed?…

As long as your traits are independent, the order does not matter. Anyway, how do you imagine this could be done better? For order to not matter, the linearization could not be possible and we'd end up with something much more complex and ugly like multiple inheritance in C++ with all the diamond inheritance problems, etc.

Re: Scala – 1 Star – Would Not Program Again

#182

Post by pkolaczk »

eranation wrote: post #68
fizx wrote: post #57

Earlier quoted context omitted.

You might be better off using a pre-release snapshot of Java 8 as a better Java. You'll get closures, functional collections, and better type inference. I bet Eclipse and Intellij support it better too.

Java 8 for me is still far from making me move from Scala. Lambda expressions is only a small part of what I like about Scala. For me Scala is a statically typed Ruby / Python / JavaScript that runs on the JVM, and is very Java like. I would change some things in it, but a language doesn't have to be revolutionary to make me want to use it. Things I have in Scala that I like and Java 8 won't provide (many are syntact…

There's even more: - implicit objects & type classes - path dependent types - abstract types - generic variance control - trait linearization - awesome collections library

Re: Scala – 1 Star – Would Not Program Again

#183

Post by steilpass »

bmurphy1976 wrote: post #101
bmurphy1976 wrote: post #96

Earlier quoted context omitted.

Strongly typed headers are great, but for the love of God please give us a back door. And I don't mean just a dictionary for every "unknown" header, but we should be able to override every "known" header as well. I'll give you a real-world example. Mono. HttpWebRequest used to store the Content-Size value as an int32. What about files larger than 4gb? Oops... That was a big problem for us. Thankfully Mono is open sou…

I have another good example. Please see this thread I posted to the Go mailing list a few months ago: https://groups.google.com/forum/#!searchin/golang-nuts/s3/go... The short summary is that Amazon S3 does not behave like a normal web server and expects HTTP path's to be "url encoded". S3 is pretty obviously something you would want to interoperate with. Go's http client (which isn't very strict at all) causes frict…

Too bad it didn't get very much attention on the mailing list.

Re: Scala – 1 Star – Would Not Program Again

#184

Post by peq »

EpicEng wrote: post #82
chrismorgan wrote: post #37

The section on HTTP headers and typing is a little concerning to me. I've been making rust-http recently and (before I was aware of Spray) I felt strongly about the typing. So, I'd like to discuss this. Am I wrong after all? Here clearly is someone that disagrees with me. I think I should probably write up a long blog post on the topic explaining my reasoning and so forth. rust-http is, at present at least, rejecting…

But what practical problem is such a scheme actually solving? If I write response["headre"] = ... I have a bug, sure, but an obvious bug that will be fixed very quickly. With this type system I am now limited in an annoying way. I don't get it.

For me, a big benefit is the tooling support. If the API is statically typed, I can easily find the headers I am able to set using my IDE. And for setting the date I don't have to check the http spec for which syntax I have to use for the date.

Re: Scala – 1 Star – Would Not Program Again

#185

Post by pkolaczk »

evincarofautumn wrote: post #70
bcoates wrote: post #33

Earlier quoted context omitted.

That's a gratuitously category-theoretic explanation, all you need to explain covariance and contravariance is is-a. An immutable List of Foos is a List of Bars if a Foo is a Bar. A function taking X and returning Y is a function taking A and returning B if A is a X and Y is a B. It's just answering the question "Can I use type relationships to guarantee that I will have no run-time conversion failures?"

T is covariant (positive) if A ≤: B ⇒ T ≤: T . T is contravariant (negative) if A ≤: B ⇒ T ≤: T (i.e., the other way around). Pretty simple stuff.

It is easy to remember if you think of it:

+ (covariant): the type can be cast to some broader (more general) type

- (contravariant): the type can be cast to some narrower (more concrete) type

Re: Scala – 1 Star – Would Not Program Again

#186

Post by davidw »

MetaCosm wrote: post #132
jerkface wrote: post #130

Earlier quoted context omitted.

4GL and MUMPS? Sounds like you've spent a bit of time in the dark corners of the healthcare industry. My condolences.

Indeed, DEEP in the east coast systems. But, it was great for me, it was literally name my own price consulting (lawyer rates) with multi-month contracts. I would guess it still is a name your own price market if you have the stomach for it. Travel and horrible tech. I was in an odd position of having picked up 4GL and MUMPS via odd random ways when I was 19/20 -- so when everyone who used to maintain those systems v…

> Ever port a MUMPS app to Erlang... I have!

Wow - that sounds like an article I'd read!

Re: Scala – 1 Star – Would Not Program Again

#187

Post by voyou »

gfodor wrote: post #55

Several years ago I picked up Odersky's book. I got a few hundred pages in, considered the types of problems I had encountered in my career so far, and decided life is too short to be spending my time learning some hyper-complex programming language that seemed, like C++, to seem unable to say "no" to introducing complexity where it would provide minimal upside in Getting Shit Done. Instead, I learned Clojure. I use…

Scala reminds me of C++ too, but it's impressive that, in a mere 10 years, Scala has achieved all the multi-paradigm incoherence it took C++ 30 years and tortuous backwards compatibility constraints to attain.

Actually, I spent some time over the weekend trying to get familiar with Scala by using it to solve some Project Euler problems, and it was pretty entertaining. Still, the language's bias towards there being more than one way to do anything does worry me; it does seem that the kind of mutually incomprehensible code bases the OP talks about are likely. I would assume that, like C++, you need a strong style guide for a Scala project laying down which parts of the language you are going to use. Does anyone have any recommendations for guides on writing comprehensible, maintainable Scala?

Re: Scala – 1 Star – Would Not Program Again

#188

Post by Peaker »

mercurial wrote: post #139
Peaker wrote: post #39

Earlier quoted context omitted.

After using Haskell, using Java makes me very sad... In Java's OO paradigm, instance variables are inherently defined separately from their initialization, making it quite difficult to make sure they're always used when initialized, properly. The nullability stuff bites me over and over :( Forgetting to use .start() on a thread is a stupid runtime error, instead of using some design where it isn't possible to forget…

For thread pools, use ExecutorService or the Guava flavour. The lack of pattern-matching is a pain, but note that you can use Enum values in switch statements.

As is often the case, writing the code from scratch in Haskell is easier than reusing a library in Java..

Android uses named integers rather than enums, due to some issue with Java enums.. And the switch would only help a bit, the main problem is needing to correctly interpret the associated payload according to the message type. That's what sum types give you, which Java doesn't properly have.

They could be emulated with visitor pattern, if one is masochistic...

Re: Scala – 1 Star – Would Not Program Again

#190

Post by virtualwhys »

Agreed, SBT plain sucks _without IDE support_ to guide you. If you have IDE support for your /project/*.scala SBT file(s) then the various symbols and conventions make sense as you can click through to _discover_ the library -- huge difference between that and blindly typing away in a text editor; the latter is a recipe for insanity ;-)
Post reply on HN