Confessions of a Ruby Developer Whose Heart was Stolen by Scala

https://speakerdeck.com/ryanlecompte/confessions-of-a-ruby-developer-whose-heart-was-stolen-by-scala

by YAFZ • 13 years ago

43 73 13 years ago

Stranger20136• 13 years ago

Well, of course a classic programming language is better then a script language for majority of tasks. Script languages like JS and Ruby just should not be abused and should only be used as a very thin layer on top. E.g. GUI scripting.

aaronbrethorst2• 13 years ago

I would recommend that you immediately inform Yahoo, 37 Signals, Hulu, GitHub, Penny Arcade, and every other Node, Rails, Sinatra, and EventMachine user of this fact!

Also, Tcl/Tk called and wants its use case back.

unono2• 13 years ago

Why do microsoft and google insist on static compiled languages?

Stranger20136• 13 years ago

Those companies are using it properly though, don't they?

csense7• 13 years ago

I go the other way -- I write in Python by default, then only go to another language if I specifically need it, for example these scenarios:

(a) Python isn't fast enough, and Pypy doesn't make it fast enough, or isn't a viable option in the target environment. So you write in C, OpenCL or assembly language.

(b) A vital library or other dependency can't talk to Python and you can't quickly find or write a reimplementation or bridge.

[1] Yes, yes, I know, things like Skulpt and Pyjamas exist. But I think those dependencies are too heavy for a lot of projects.

jitl• 13 years ago

As a Ruby developer, I can't get through these sorts of slides. My other languages are C, Go and JavaScript, and the Scala syntax is totally inscrutable to me. Isn't the point of slides presenting something that can be easily absorbed? And I can't just quickly look up these declarations either — Scala is too complex for that given my experience level. Is there a gentle introduction talk for Scala around so I can evaluate the language without putting in a week of learning?

vladev3• 13 years ago

You might try Venkat Subramaniam's Scala for the Intrigued [1]. He's a very good speaker.

Regarding Scala's complexity - some more advanced features are presented in those slides. Imagine watching a talk about Python where they talk about decorators and meta-classes.

[1] https://www.youtube.com/watch?feature=player_embedded&v=grvv...

Stranger20136• 13 years ago

Consider F# then.

trailfox3• 13 years ago

As a Scala programmer I find Ruby syntax complex and inscrutable, almost like Perl.

prollyignored3• 13 years ago

You have a tumor in your brain.

csense7• 13 years ago

As a Python programmer, I agree.

Here's a Ruby snippet. I don't want to pick on this particular project [1], rather, I've found that this is typical of Ruby code:

  state_machine :state, initial: :active do
    after_transition any => :blocked do |user, transition|
      # Remove user from all projects and
      user.users_projects.find_each do |membership|
        return false unless membership.destroy
      end
    end

My conclusion? Ruby's syntax is awful. There are colons, absolute value bars, implications, and who-knows-what-else flying everywhere! It gets worse, elsewhere in the same file there are messy lines like this one with single-arrow implications, question marks and ampersands [2] [3]:

  scope :not_in_project, ->(project) \
    { project.users.present? ?       \
    where("id not in (:ids)", ids: project.users.map(&:id) ) : scoped }

Simple, intuitive syntax? From where I sit, the syntax of Ruby is worse than C++, and approaches Perl levels of awfulness. In most languages, I can at least sort-of grok what's going on from the context when I see unfamiliar operators, but not so in Ruby.

This is a copy-paste of a comment I made [4] weeks ago on another article.

[1] https://github.com/gitlabhq/gitlabhq/blob/4caaea824cf51670d1...

[2] https://github.com/gitlabhq/gitlabhq/blob/4caaea824cf51670d1...

[3] I split the line and inserted backslashes because HN gives me a horizontal scrollbar when it's a single long line; apologies if this transformation isn't legal Ruby, or changes the meaning of the code.

[4] https://news.ycombinator.com/item?id=5784296

rogerbinns• 13 years ago

I'm a Python developer and find a lot of the Ruby criticism in those slides weird. For example you can also monkey patch in Python, but I only recall using it once in the last several years to fix a bug in one method in the standard library. Similarly it isn't a Python pattern to want to write 2.gigabytes.

Are the Ruby complaints in the slides real - do people do those sort of things often and expect other languages to behave like that too? Is that because of the standard library or innate to the language?

ldub2• 13 years ago

I don't know about expecting other languages to behave like [that] too, but the Ruby community certainly does a lot of monkey patching. When I was developing in Ruby I saw this often and it annoyed me a bit.

davidw• 13 years ago

The point of slides is to act as visual aids for a talk. So without the person talking, in many cases, they're perfectly useless.

bronxbomber92• 13 years ago

As other posters have noted, there are some advance Scala features being used here. It's almost important to note that this talk was given at Scala Days, a conference for Scala programmers, so presumably the target audience is all ready expected to be familiar with Scala (and its syntax). Additionally, given that the speaker appears to be giving reasons why Scala can be a better choice than Ruby, his intended audience may be even smaller: Scala enthusiasts working at a Ruby shop who are trying to convince their coworkers/management to transition from Ruby to Scala... :P

playing_colours• 13 years ago

The speaker pays a lot of attention to implicits in Scala. Well, it's a powerful tool, elegant solutions can be built with it, but you should be careful using them. Implicits bring its own magic and abusing them can pollute your project, make it difficult to understand the code. Maybe the speaker is so attracted to inplicits because they remind him of Ruby's / Rails' magic?

vladev3• 13 years ago

You are correct that implicits are a sharp tool. Thankfully, the Scala community knows that nowadays and they are used for a fairly small number of cases - pimp my library (add methods to Ints, Strings, etc.) and typeclasses.

trailfox3• 13 years ago

For those interested in learning Scala I'd recommend the free chapters from Scala for the Impatient:

http://logic.cse.unt.edu/tarau/teaching/SCALA_DOCS/scala-for...

pyvek• 13 years ago

Also, _Functional Programming Principles in Scala_ course on Coursera by Martin Odersky (Scala's designer) is very good.

https://www.coursera.org/course/progfun

dhugiaskmak• 13 years ago

I just finished the most recent session of this class and I found it incredibly frustrating that there was no discussion of the homework assignments after the due dates had passed. What's the point of having homework if there's no way to get the correct answers and get feedback on your solutions?

And take the "in Scala" part of the course title with a grain of salt. You're only taught enough to complete the exercises.

hejsna• 13 years ago

It seemed like most of his slides came down to the old typed/untyped flame war. Yes, in Scala you can look at your objects in an IDE and be told what type they are, in Ruby you can't. Some organizations and people need that, some don't. And yes, it's easier to optimize typed languages. Some applications need that extra speed, most don't.

I'm happy he found a language he enjoys working with, but I doubt this will change anyone's mind...

coopdog• 13 years ago

Somewhat true but I find Scala's inferred typing a surprisingly great compromise between the two.

For example:

val i = 1;

i = "some string" // throws a compiler error, because it knows i is an integer

It's great when you haven't declared the types, you change for example an int to a double or a class to some other class (eg swapping a data structure) and it just flows through the code base without problems like a dynamically typed language.

It can also be pretty useful to look up types when they get complex in the middle of some function, like a Map[List[(String,SomeObject)]] (a map of lists of (String,SomeObject) tuples). Allowing the types to get complex lets me focus on the problem while giving a crutch to quickly remember where it's at half way through (and while finding other methods/source of data) and keep moving towards the solution.

BonoboBoner• 13 years ago

Scala is a fantastic language, but my heart seems to resist due to things like this (slide 27/42):

  implicit class RichSeq[A, C[A] <: Seq[A]](underlying: C[A]{
    def cycle: Iterator[A] = {
      lazy val circular: Stream[A] = underlying.toStream #::: circular
      circular.iterator
    }
  }

vladev3• 13 years ago

This is very dense code, and takes some getting-used-to in order to read. What it achieves is beyond the reach of many languages.

All it does is convert a Seq (sequence) to a lazy stream that will infinitely cycle through the values.

    Seq(1, 2, 3).cycle.take(8).toList
    res3: List[Int] = List(1, 2, 3, 1, 2, 3, 1, 2)

It will work for any seq-like structure (including List. Vector, Queue, etc.)

If you try to use it with anything else, like a Map, it won't compile.

Also, note from my example that it's generic and the resulting List is of the correct type.

Just like novice JavaScript developers struggle with "Why 'this' changes here?", it requires some experience with the language.

Stranger20136• 13 years ago

Brainfuck language is even denser.

dons2• 13 years ago

This is very dense code, and takes some getting-used-to in order to read.

I don't think so. It is full of syntactic noise, for what is really just notation for building a cyclic structure.

* type annotations stated explicitly, not inferred

* type variables given multiple times

* too much non-verb, non-noun syntax e.g. `#:::`

* and the actual construction of the cycle is stated imperatively with great ceremony (despite it being an applicative)

It is the opposite of dense.

prollyignored3• 13 years ago

Attention to syntax is what ruby is good at.

Scala, Haskell treat syntax as a chore.

dons2• 13 years ago

You don't know Haskell.

take 8 $ cycle [1,2,3]

lucian1900• 13 years ago

Scala maybe, not Haskell (which barely has any syntax).

eloisant• 13 years ago

What makes it a bit more complex than it would be in Ruby is the typesafety (what comes after RichSeq). So it's a bit harder to write such a library, but once it's written it's a breeze to use for users because the compiler tells them right away if something is wrong with the type.

shangaslammi• 13 years ago

The same thing in Haskell:

    cycle seq = circular where circular = seq ++ circular

(or if you want to really golf it)

    cycle = fix . (++)

Ok, to be fair the Scala code is a bit more generic as it works for any abstract sequence, but still, Scala's syntax is awfully heavy compared to Haskell.

That's one reason I still prefer Haskell even though Scala is easier to sneak into enterprise projects thanks to JVM. Not to mention that Haskell gives stronger static guarantees and has a more sophisticated type inference system.

pja2• 13 years ago

oo. I'd forgotten about fix.

  cycleM = fix . mplus

gives a nice generic version that works on Lists & Sequences but falls afoul of the monomorphism restriction, so it needs a type:

  cycleM :: (MonadPlus m) => m a -> m a
  cycleM = fix . mplus

trailfox3• 13 years ago

That's not the sort of thing you'll commonly see in real world Scala code. It's the sort of thing that might be used internally by a library, but not likely something you will come across day-to-day in Scala code. Every language has examples of code where the syntax is hard to follow, but you need to look at common code rather than "ooh let's try some tricks" kind of code.

gizzlon2• 13 years ago

They way you'd build large systems in dynamic languages is to break it up into many smaller pieces that work together. This frees you to change parts without worrying about the rest.

To me, this type of development is much more natural and sane than the "one big clusterfuck" type of projects I've seen in Java et.al.

Edit: Also, dynamic languages let you make the tradeof between safety and speed. Sometimes you go slow and steady (simple code, tests..) and sometimes you just want to test something out.

mattquiros• 13 years ago

Hm, I don't know what you've seen but I'm pretty sure Java is about breaking up large systems into many smaller pieces that work together, instead of one big clusterfuck. Must be some really badly designed system, more of a programmer's fault than the language itself

gizzlon2• 13 years ago

True, but isn't it still one big program/project? What I mean was to break it up into many smaller programs and (possibly) projects (think unix process vs. classes =)

sandGorgon2• 13 years ago

Can someone comment on the current state of tooling in the Scala world. Last I had tried (some months back), SBT was extremely slow.

Googling about SBT came back with a lot of complaints about the state of scala tooling back then.

yareally7• 13 years ago

I've been using Scala on Android + Intellij IDEA for about the past month after wanting to try something new[1]. Other than having to run it through proguard first, the compile process in Intellij is comparable to how it is with just Java. Scala plays nicely with Android and I have loved using it so far. Makes Android development a bit more fun than with just plain old Java.

[1] https://github.com/yareally/android-scala-intellij-no-sbt-pl...

sandGorgon2• 13 years ago

ah - "Using proguard lets you build Scala without any extra plugins and sbt fiddling".

Seems like the tooling is still one of the more painful aspects of Scala. Kudos to Intellij, -1 to Scala.

dgregd• 13 years ago

I just wonder when someone will build a tool to annotate Ruby, Python source code with var types gathered during run-time.

If C has Valgrind then dynamic typed languages should get something for the types.

Erwin• 13 years ago

PyCharm does this. In addition to doing type inference while you have your project open, you can while debugging it run it and make it collect type information. That's quite a bit slower than usual, but once done you will get extra type hints of possible types passed to your functions.

http://blog.jetbrains.com/pycharm/2013/02/dynamic-runtime-ty...

yareally7• 13 years ago

Python 3.0 has the Gradual module[1][2].

[1] http://ecee.colorado.edu/~siek/gradualtyping.html

[2] https://pypi.python.org/pypi/gradual

garysweaver• 13 years ago

Ruby and Scala are for two different kinds of environments. One is an environment where having less code to maintain (that can also be highly legible) matters and where you have a lot of options. The other is an environment where an edge in performance is more important, but not important enough to write it in an even faster language/not run in the JVM at all.

I noticed a lack of a link to a 1:1 comparison of application code with realistic examples. I think such comparisons and related discussion are often the best way to convince someone to use a language.

And some slides were just blatantly wrong, like Mixin Abuse: apparently that is just a long list of module includes? I have never seen so many module includes in a single class in application code. But, assuming you did have that, you should show what it would look like side-by-side in Scala. In Ruby, there are a lot of options when it comes to including other code or defining code in a class, instance, etc. Those options can lead to much less and more legible code if used correctly.

I remember when people said Java was slow; they made it seem like it was a fad, and no reputable company would use it. And... we see where that went.

Confessions of a Ruby Developer Whose Heart was Stolen by Scala

Related Stories