Archive

Posts Tagged ‘scala’

Episode 44 – David Pollak: Scala’s not for the Proletariat, HP TouchPad is resurrected, RSS is poisonous & JavaOne winner!

September 9th, 2011

In today's episode we cover a wide range of topics from David Pollak's (creator of Lift) view that "Scala is only for a certain class of developer", the HP TouchPad gets a second chance(?) and RSS may be extremely poisonous to your productivity (duh?)

Congratulations to Brent Watson!
You are our JavaOne 2011 Conference Pass giveaway winner!

Listen here:

 

Download


Enjoy!

Podcast , , ,

Scala Language Tour ( Tutorial )

November 26th, 2010



As a follow up to previous posts on Scala (Scala, a cursory glance and Scala and Akka an Interview with Jonas Boner) I've put together a Scala Language Tutorial.

This was presented on November 25th 2010 at the Winnipeg Ruby User Group (Winnipeg.rb) and the agenda covered is listed below the video.

If you have any questions, comments or corrections please leave a comment!

Agenda - any inaccuracies in the screencast are noted below

  • Object Oriented Programming - 00:33:44
    • object vs class - 00:39:15
      • Chris Marshall emailed to say I should have been more explicit about the fact that when a constructor parameter is marked as private the accessor method(s) are still generated by Scala, they just aren't visible to users of the class.
    • Option, Some, None - 00:43:01
      • Chris Marshall emailed to say the coverage for this slide was pretty shoddy. I agree, at the time I hadn't much experience with Option outside of the O'Reilly book. There are many ways to deal with Option, specifically with the None type. One of the best ways, when you have a list of Options, is to use flatMap(x=>x). It will generate a list of the Option's underlying values, and disregard None all together. When dealing with a single Option, getOrElse works nicely as a guard against None.
    • generics (parameterized types) - 00:44:57
    • covariant(+), contravariant(-) and invariant notation - 00:47:15
    • duck typing - 00:50:16
    • traits - 00:51:44
    • mixins - 00:52:11
      • Chris Marshall emailed to say I missed stating you must first cast the wolfMan to a Canine before being able to call howl(). As pointed out, WereWolf is spelled wrong (spelled WhereWolf in the cast). I need a spell checker for vim :)
    • case classes - 00:55:09
    • Implicits - 00:58:33
    • Common Complaints about Scala - 01:01:18
    • Scala tools - 01:02:47
    • Scala Resources - 01:04:40
      • Scala Mailing List
        • http://listes.epfl.ch/doc_en.cgi?liste=scala-user
      • O'Reily Scala Book (free)
        • http://programming-scala.labs.oreilly.com/
      • #scala on Freenode IRC
  • Craig, General ,

    Scala, a cursory glance

    April 8th, 2009
    Recently, the Scala language was brought to my attention.

    Now, I've been around the language block a few times, having seen my share of languages. I'm aware and suspicious of the siren-like call new languages have for programmers. They tickle our programming curiosities to the core, offering silver-bullet, paradigm-shifting opportunities for increased productivity. Unfortunately, they require lots of commitment, community, support libraries and momentum to become useful, so one has to be pragmatic when adopting new languages. I tend to error more on the conservative side, but Scala beckoned me to have a closer look. These are my cursory observations.

    What first drew me to Scala was its offering of type-safe and concise programming models, based on generics and functional programming. Although the key reason I use C++ is performance, it's the type safety and concise power of templates that keeps me there. I find type-safe languages provide for more readable and maintainable code bases, something that is critical for large and aging projects. Scala seems to push for some of these same ideals.

    The first benefit of Scala is immediate: it compiles to Java byte code and is able to utilize Java libraries. This means you can integrate with your existing Java code, use the plethora of existing Java libraries and reuse the man-centuries of work that went into Java VMs. This is somewhat analogous to how C++ can use C. However, C code can (mostly) be compiled as C++ code, Scala code is not anywhere near valid Java code. Although this affords the Scala designers more freedom, it creates another learning curve for Java programmers.

    I may have overestimated Scala's intended integration with Java though, as they also have a preliminary link up with .NET working. This could be interesting, or it could split its community focus.

    The language itself is very functional and recursive. Functions are first class objects, specialization/type searching is handled via a powerful pattern-matching system and generics seem to be on the right track. This kind of stuff lets you build very interesting DSLs (domain specific languages), something that I think will vital for the future. This means you can build stuff like C#'s LINQ SQL query system into a programming language, without having to update the language -- all done as a library. New web presentation mark-up languages, mini-programming/scripting languages, XML query/processing, etc. could all be done as libraries. Neat stuff.

    My very cursory inspections with "javap", the Java class disassembler, shows that Scala is not doing the type specific in-lining I thought it would be (for example, instantiating functions for each specific type T that is used). This means I won't get my performance wishes out of Scala, which is too bad, since that would be more interesting that providing yet another deferred-to-runtime type system (even if it has a nice type-safe compile time checker).

    It's an interesting project, and I wish them the best of luck. Programming languages require large investments in time, community and libraries, and they're just beginning this long road and still have a ways to go before I'd commit any large projects to them. This segways into my final, not-really-Scala observation:

    Why are the Twitter guys all hot for it?

    Twitter (via programmer Alex Payne) seem to be claiming that their notorious problems with scalability and reliability can be traced back to Ruby on Rails. RoR haxxor Obie Fernandez attempts to refute this. Whether RoR can handle the load or the Twitter programmers just don't know how to use it, I don't know or care. What I do know is that if you're going to switch to something else, especially for your critical messaging queuing core, don't jump to something even more obscure and untested.

    Alex Payne says Scala is fun and gives him the fuzzies, which is all fine and dandy, but for god's sake man, think about the business here and not the Scala book you're penning. You need something scalable and tested, which usually means old and boring. That's just business. Make Twitter work, sell it, and get (even more?) rich.

    Alex, General , , , ,

    Support Wikipedia