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

91–100 of 324 posts

Re: Scala – 1 Star – Would Not Program Again

#91

Post by tel »

jroesch wrote: post #38
tel wrote: post #8

Earlier quoted context omitted.

Usually it enforces statically that you cannot create an Integer that violates its preconditions. If you even do so dynamically it'll make sure there's a dynamic check before the dynamic value can substantiate the more specific type.

It is done statically . Types are a compile time construct, languages like Agda and Coq have no type information at runtime. This means if one can't statically prove that their types are correct the code won't compile. For example if my function returns a Vector[A, N] (a vector of A's with size N), and I try to pass it's return value to a function that expects a of type Vector[A, 2] my code will not compile. This is…

Not all things are statically checkable. If you want to take in some runtime data and treat it as a Vector[A, 3] then you'll need to include a dynamically failing check like (List -> Maybe (Vector n a)).

Re: Scala – 1 Star – Would Not Program Again

#92

Post by politician »

goldenkey wrote: post #85
JulianMorrison wrote: post #54

Problem: author is pining for Go, and doesn't know it. Solution: author should abandon the JVM ecosystem and use Go. - Fast compiles. - Ultra simple, non extensible syntax, yet not verbose in practise. - The code you see is 100% of the code. - A culture of implementing the simple algorithm. - Stable, with version compatibility guarantees. - Nobody is trying to make the types jump through hoops, so the type inference…

It's hard to take your comment with impartiality when 90% of your comments mention Go.

I agree with the parent that the author should investigate Go, but add that the author will get all of those benefits plus a dependency management headache.

Re: Scala – 1 Star – Would Not Program Again

#93

Post by est »

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…

> I take a similarly strong position for such strong typing.

Why not add a weak checking for k-v strings? Something like during compile time:

    if not k in LIST_OF_WELLKNOWNS
        warn('Bad header maybe?')
You don't have to use types to check this.

Re: Scala – 1 Star – Would Not Program Again

#94

Post by yohanatan »

lemmsjid wrote: post #49

I'd say a lot of the critiques are fair but quite exaggerated. I work on a large Scala codebase and yes, the compile times for a fresh start across the codebase are very long, but TDD-type loops are very short, because you're generally waiting for two files (your test target and your test code). Still, the compiler performance in Scala is perhaps my chief criticism, though hardly a show-stopper. As codebases in any l…

Is 'legalese' really a high-level language? It seems to contain a ton of boilerplate. Signal-to-noise ratio is quite low in reality. It could much more succinctly be encoded in a formal language.

Also, I think you exaggerate the 'Scala is bad because DSLs' point. There are indeed a lot of libraries which overuse symbols but you are not obligated to use them. I have found the Scala I've written and read personally to be both concise and readable.

And, Scala isn't the first or the last to 'reach for the expressivity goal'. See: Haskell, Scheme, F#, & ML.

Re: Scala – 1 Star – Would Not Program Again

#95

Post by ubernostrum »

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…

My main concern is the last sentence of the section you quote. There's tension between headers which are well-known and standardized (either formally or through de-facto wide use), and so are amenable to being properly modelled, and headers which are not well-known or which may not even exist yet. Hence, I think, his comment about CORS.

And I'm not sure there's a good solution. The obvious approach, as you already know, is to separate headers into two groups: one group is "properly" handled, and the other group gets tossed into an "other" bucket of key/value string pairs. But it's going to be awfully tempting over time to have "proper" support for the most common non-RFC2616 headers, especially those which have widely-accepted standards of their own.

But that's a bit messy and much less than ideal, as you've also discovered. And I don't know of another way to approach the problem that still lets you have the stuff you want from the type system, and doesn't cut people off the minute they start using extension headers your library doesn't know about.

And that's without getting into all the completely stupid things it's technically legal to do in an HTTP header, and the even more stupid things that aren't legal but that people do anyway. My usual torture test of an HTTP library these days runs through things like non-ASCII content in header values (legal if properly encoded, and not everything in the wild properly encodes), looking to see how large a value a library will accept, whether it will let me throw newlines into headers, etc. etc.

Re: Scala – 1 Star – Would Not Program Again

#96

Post by bmurphy1976 »

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…

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 source, we were able to peruse the code and come up with some magic incantations using reflection to work around the fact that the framework libraries would not allow us to set the Content-Size header without going through the int32 property.

Now, normally you would file that as a bug, however, it (A) took years for a version of mono to be released with that fixed this and (B) could easily have been some misunderstanding in the implementation of the HTTP spec that was overlooked. You're implementing a spec right now. Can you guarantee that the your implementation is 100% correct? Can you guarantee that the spec is 100% correct? Can you guarantee that the spec is implemented 100% correct everywhere?

No, you can't.

So, don't limit me. Help me, but do not prevent me from doing what I need to in order to do my job.

Re: Scala – 1 Star – Would Not Program Again

#97

Post by leokun »

> This issue reached its pinnacle for us when we were unable to figure out how to replicate the magic response composition syntax used by Spray to abstract away the addition of CORS headers to HTTP responses.

I'd just put any kind of application, whether built in Scala, node.js or Go or ruby on rails behind a nginx proxy and use that for setting the headers. That simplifies a lot of things. I hope your HTTP headers aren't really so dynamic that you need to build software that changes them so much, especially not for a RESTful application.

Re: Scala – 1 Star – Would Not Program Again

#98

Post by joelgrus »

eranation wrote: post #60

I tried learning Clojure, I really did, and I have to agree, the syntax is simpler, but I can't really read Clojure or code in Clojure the way I do in Scala, I don't know why. Whenever I read articles about Scala, I keep finding it amusing, prehaps this is because I had experience with Java, but for me Scala is a life saver, can't go back to Java after this. And I won't go back to Ruby, Python or JavaScript. So I can…

I feel the opposite regarding Clojure and Scala -- Clojure just makes sense to me, whereas Scala gives me a headache.

As an aside, insofar as you have some sort of willingness toward C#, you should check out F#, which is functional with really nice type inference and none of the syntactic woes that I have come to associate with Scala. (Not sure how portable it is, I have heard stories of people using it with Mono, but I haven't tried it myself.)

Re: Scala – 1 Star – Would Not Program Again

#100

Post by kazagistar »

lemmsjid wrote: post #49

I'd say a lot of the critiques are fair but quite exaggerated. I work on a large Scala codebase and yes, the compile times for a fresh start across the codebase are very long, but TDD-type loops are very short, because you're generally waiting for two files (your test target and your test code). Still, the compiler performance in Scala is perhaps my chief criticism, though hardly a show-stopper. As codebases in any l…

Languages like Ruby and Python allow for expressive, high-level customization, metaprogramming, and DSL creation. However, especially in the latter, the potential chaos is curbed by a strong culture and encouragement of self restraint, readability, and simplicity. From the sound of it, this is not so true for Scala.
Post reply on HN