Live data from Hacker News

Scala – 1 Star – Would Not Program Again

overwatering.org

41–50 of 324 posts

Re: Scala – 1 Star – Would Not Program Again

#41

To be honest with you, I use Scala as a better Java. Which means I still code imperatively (and use null instead of None) but with less noise (semi colons etc). But, esp when working with collections, I take advantage of Scala's features. It's not perfect, but it works wonderfully. I can always revisit/refactor my code again later.

Using null instead of None means you are more at risk of hitting a NPE.

Here are a couple examples:

myVar match {

  case Some(val) => doSomething(val)

  case None => handleNone()
}

myVar.getOrElse("else")

In both of these cases, we eliminated the possibility of a NPE through the use of a language feature. :)

(edited for formatting)

Re: Scala – 1 Star – Would Not Program Again

#42
My problems with Scala:

1) src/main/scala/com/thingy/actualthingy JUST to get to the root of your code. 2) Recompiling/restarting is slow because liftweb and other frameworks are overly complex. 3) I'm 90% sure it would be possible to create a PRY-like debugging tool that runs your code in interpreted mode and drops you into the REPL at a certain point in your code. And yet, it'll never get built because Scala hackers are stuck in the halcyon java days of 1998. 4) Variable names first, types second = okay, now you're just being different for the sake of being different.

That said, it seems like if you use scala as a more concise java with some handy functional syntax thrown in, you can make something that isn't terrible for future maintainers.

Re: Scala – 1 Star – Would Not Program Again

#43
post #23

I started learning Scala almost a year ago at my latest job - we use it for production systems at a large multinational investment bank. Coming to Scala from experience including C, Java and Haskell, I intially found Scala quite difficult. It is true that there are some things in Scala that are not obvious to newcomers, and that are difficult to discover for yourself - such as the use of Implicits, and the strange pr…

I'll echo all of this (minus scalaz, we don't use that). I'll give an example of the power of Scala's type system. When I first convinced one of our founders to give Scala a try, he used it to write the first pass of our analytics service. He'd never written Scala before but once it compiled, it ran correctly on the first try, that's the power of its type system.

Not to be too big of an ass, but this could just be the skill of your founder. Or do you believe it is impossible to have compiling code that does not do as its author intended?

Re: Scala – 1 Star – Would Not Program Again

#44

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…

IMHO, libraries like this should always have an easy "out", where the default is strongly typed, but the user of the library can explicitly escape the known behavior if need be.

As a (albeit poor example), I once inherited a click tracking system that uses Java Jersey. The standard response object has a .redirect(URI uri) method. Unfortunately, many "URI"s we receive from the world are not actually value, and the java URI object refuses to build URI objects from the string. Fortunately, one can simply call .setHeader(String, String) and be done with it.

Re: Scala – 1 Star – Would Not Program Again

#45

My problems with Scala: 1) src/main/scala/com/thingy/actualthingy JUST to get to the root of your code. 2) Recompiling/restarting is slow because liftweb and other frameworks are overly complex. 3) I'm 90% sure it would be possible to create a PRY-like debugging tool that runs your code in interpreted mode and drops you into the REPL at a certain point in your code. And yet, it'll never get built because Scala hacker…

As for number 4, this is because many of the type annotations are optional.

Re: Scala – 1 Star – Would Not Program Again

#46
post #14

I've been using Scala just to learn Play framework (I know I could use Java but I thought I'd be adventurous). I think in truth, though, if there were a web framework in Clojure as well received as Play I would be bounding down that path instead. Clojure seems to be where a lot of the JVM interested is heading yet we're not there yet for some reason.

I've been wondering - having never used a web framework except for some RoR - what people miss in the idiomatic Clojure way of doing web (composing libraries like Ring, Compojure, Enlive etc). Care to share?

I was a full-time Rails developer until a crescendo of disillusionment finally cajoled me to learn Clojure.

I don't really know that I miss anything. The things I might've thought I'd miss are the things that ended up souring the taste of Rails.

Having to come up with my own abstractions or recreate familiar conventions or set up a database were areas where I had to cut my teeth, but I also had to cut my teeth on Rails when I was learning it.

Rather than missing anything from Rails, I find myself using Rails' conventions as a loose model and then simplifying it. For example, my "templates" are now just functions that render html. My "layouts" are just functions that get applied to templates. I don't need to read Rails' template rendering guide to come up with a hack. Instead, modifying my templating system is trivial and obvious.

Re: Scala – 1 Star – Would Not Program Again

#47
post #30

Earlier quoted context omitted.

I've been wondering - having never used a web framework except for some RoR - what people miss in the idiomatic Clojure way of doing web (composing libraries like Ring, Compojure, Enlive etc). Care to share?

Honestly I haven't used Ring/Compojure/Enlive beyond tutorials so at this point I'm very intrigued but don't have much to say yet. My belief though is that there is some peace of mind that comes from the idea of what you might call "page composition" -- that this piece of data sits in this template, that it rides on top of this simple model, that it is in ORM from database. There is a huge amount of linearity and con…

Maybe check out http://pedestal.io/

"Clojurists looking for a standard way to build internet applications will love Pedestal. Rather than composing art out of found objects, they will now be able to mold a single, consistent form to match their vision.

Pedestal may also appeal to developers who have been nervously approaching a functional language but who haven't yet mustered the courage to ask it out on a date. It provides a sterling example of how to use the Clojure ecosystem to its best advantage, reducing the friction usually associated with a language switch."

Re: Scala – 1 Star – Would Not Program Again

#48

My problems with Scala: 1) src/main/scala/com/thingy/actualthingy JUST to get to the root of your code. 2) Recompiling/restarting is slow because liftweb and other frameworks are overly complex. 3) I'm 90% sure it would be possible to create a PRY-like debugging tool that runs your code in interpreted mode and drops you into the REPL at a certain point in your code. And yet, it'll never get built because Scala hacker…

1) You don't have to do that, Scala doesn't enforce the folder/package hierarchy that Java does. Moreover, you can use any folder hierarchy you want.

2) Compiling Scala is slower than Java (sometimes much slower) but that's not the frameworks' fault. scalac is just slow, though getting better.

3) This does exist. In fact, it's built into the language. You can also use "sbt console" to load a REPL with your entire project in the classpath.

4) As the other reply said, type annotations aren't required. In that light, Scala's syntax for type annotations makes sense.

Re: Scala – 1 Star – Would Not Program Again

#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 language grow, you tend to have increasing challenges in the time it takes to fire up your environment.

The critique about excessive and opaque operator use in libraries is fair, though I think it actually exposes an interesting philosophical issue. Scala is unabashedly written to be a flexible language. This is in opposition to Java, which was written to be a very strict language in terms of expressiveness on the part of the developer (it's perhaps the most strict of the languages I've worked with, hence it being my example). I personally think a lot of criticisms leveled against Java's verbosity and inflexibility are unfair, by virtue of the following: Many incredibly successful and complex open source projects are written in Java. While you could say this stems from Java's enormous popularity, one interesting property of huge Java open-source projects is that I can usually crack open the code and quickly get a sense of how I could contribute to the system without breaking it. While other languages often do a better job of giving me a sense of how the system works, I generally have much trouble with extensibility unless it's Java. This I believe is because Java was designed from the ground up with the goal of limiting individual developer expressivity in favor of imagining large development teams with limited cross communication.

So--I am far less anti-Java than most. But I am a big fan of Scala. Unlike Java, Scala was written to maximize developer expressivity. While writing Java can feel like putting together a legal contract, writing Scala can feel like creating a poem. I'm not making a value judgement in either direction there--I feel that poetry is a good metaphor, because things in Scala tend to fall apart in the reading department. One of the easiest things to do in poetry is to lose the reader--a great poet can put an incredibly complicated multilayered concept onto a small amount of paper--and require a graduate-level understanding from the reader to understand it. Similarly, one can very easily make Scala into an exercise in unpacking

So isn't that a bad thing? Why am I a Scala fan? Going back to my initial praise of Java--Java is so simple and predictable that it's really easy to see how the plumbing works. But because the plumbing must be laid out so meticulously and in every situation, it is often hard to see how things work at a high level. You can't see an architectural sketch in Java, you can only see endless classes in endlessly nested subdirectories. This is a very low level of abstraction, and helps the layperson (such as someone approaching a new open source project) build up an understanding from the base elements. But what's lacking is the high level abstraction.

Outside of programming languages, almost every knowledge discipline has a high level abstraction language--sometimes multiple languages. Usually the abstraction language is opaque to newcomers, and frustratingly so. Examples are the mathematical notations of various disciplines, the jargon-laden meta-language of historical theory/literary criticism, and what is popularly known as 'legalese'. But even less high falutin' fields have similar languages--listening to sports fans talking about what's happening can be quite mystifying to me, given all of the shorthand they're using. Similarly people talking about pop culture in areas I'm not familiar with.

These ubiquitous high level languages usually share two important facets: first, in a few lines of text/speech, you can pack in many books' worth of concepts. Second, unless someone has read those books, they will have no idea what you're talking about (or in the case of pop culture jargon, having spent the requisite hundreds of hours watching movies). Scala is trying to provide a language that can express the low level plumbing as Java can, but also that can express the high level meta-language. In doing so, it opens itself to the same type of criticism that mathematical notation can receive--opacity.

The pitfall, then, of Scala library developers is to create a high level meta-language (a DSL), that doesn't have industry acceptance. This is tantamount to mathematicians who create their own notation to establish proofs--such proofs can be completely unreadable to their colleagues. But this isn't a criticism that should be leveled at the idea of notation period--it's a matter of people learning to accept useful obfuscation (where jargon can reduce textual size and increase understanding) and reject useless obfuscation (inventing your own dialect of shorthand and forcing your readers to learn non-transferrable knowledge to understand what you wrote).

Because they are working with such a flexible language, and one that is targeted at building high abstraction languages, Scala library developers need to think of their audience--terseness by itself is not useful, unless you're writing throwaway code. If you're going to unleash a DSL on your reader, make sure it's in a real dialogue with the reader's expected level of knowledge with regards to how such a DSL should be structured in terms of what the symbols should mean and how they fit together.

I don't know how the Scala story will end, but I do believe that it is one of the few languages that reaches for an expressivity goal that needs to be achieved by at least some future language. Its reaching opens it to much criticism, and rightfully so, but I appreciate it for its ambition.

Re: Scala – 1 Star – Would Not Program Again

#50

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…

What does your library do if someone sends invalid data? For example what if the date header is not a valid HTTP-formatted date?
Post reply on HN