6 ms·

Java.next() - Scala: The Revenge of the Static Typing

• Egregore 15y ago
  Can you please give some examples of real world applications in scala?
  • DavidMcLaughlin 15y ago
    Foursquare[1], Twitter[2], LinkedIn[3] and The Guardian[4] use Scala. If you are looking for code examples, you can explore here: https://github.com/languages/Scala https://github.com/languages/Scala I have been using Scala lately for some personal stuff and I've really fallen in love with it. [1] - http://www.scala-lang.org/node/5130 http://www.scala-lang.org/node/5130 [2] - http://www.artima.com/scalazine/articles/twitter_on_scala.html http://www.artima.com/scalazine/articles/twitter_on_scala.ht... [3] - http://www.scala-lang.org/node/6436 http://www.scala-lang.org/node/6436 [4] - http://www.scala-lang.org/node/7808 http://www.scala-lang.org/node/7808
    • jordibunster 15y ago
      Yammer also uses Scala for many of its backend services.
  • jzoidberg 15y ago
    Novell developed Vibe in Scala: https://vibe.novell.com/ https://vibe.novell.com/ BankSimple is building on Scala: https://banksimple.com/ https://banksimple.com/ Nasa uses Scala in production: http://www.scala-lang.org/node/6605 http://www.scala-lang.org/node/6605
  • dwhitney 15y ago
    Trust Metrics is being built primarily with Scala
  • thisisfmu 15y ago
    afaik the Rapportive back end is built in scala.
  • digicyc 15y ago
    SendOutCards, a Web to Print company uses Scala for their complete production printing backend and the generating of Card Data. We are even currently writing a Web Dashboard using Lift which will use our Scala CardPrinting API. https://www.sendoutcards.com https://www.sendoutcards.com
  • pchiusano 15y ago
    We have been using Scala pretty heavily since 2008 at Capital IQ (capitaliq.com) and ClariFI (http://clarifi.com/ http://clarifi.com/) - check out this writeup - http://pchiusano.blogspot.com/2009/08/scala-success-story-commercial-usage-of.html http://pchiusano.blogspot.com/2009/08/scala-success-story-co.... Since then we've only increased our usage and it's been working out extremely well.
  • chrisx 15y ago
    All of our core services are being built in scala at bookish http://newsbreaks.infotoday.com/NewsBreaks/Bookish-Wants-to-Help-You-Find-Your-Next-Book-75461.asp http://newsbreaks.infotoday.com/NewsBreaks/Bookish-Wants-to-...
  • vdichev 15y ago
    Remember The Milk, the online todo web application, uses Scala (http://www.rememberthemilk.com/ http://www.rememberthemilk.com/). Disclaimer: I work at Remember The Milk and I think Scala is a great fit for the problems we're solving.
• lloeki 15y ago
  Worthwhile article, if only for reading one of the less biased dynamic vs static typing pros an cons.
  • thesz 15y ago
    I should note that author added some unneccessary cons to static types. He said that metaprogramming is hard. The area of metaprogramming is partially covered by higher-order functions. The coverage is big, in my opinion, I haven't missed metaprogramming in Haskell for ten years, at least (I missed it for first two weeks with Haskell). He also said that there's no mechanism to compensate for the absence of duck typing. In Haskell, at least, there are type classes which allow you to make your types as duck as you would wish, maybe slightly less. I think that some Scala mechanisms provide that power.
    • dan00 15y ago
      "He also said that there's no mechanism to compensate for the absence of duck typing. In Haskell, at least, there are type classes which allow you to make your types as duck as you would wish, maybe slightly less." I think that type classes are the way to go. Duck typing is mostly popular because multiple inheritance sucks, and because inherting a class to only overload a method sucks. Languages like Ruby, Python or Perl are so popular because they are less verbose than Java or C++, with the disadvantage, that the compiler can't help you that much. Haskell is a language that combines the advantages, less verbosity with a helping compiler, and a static type system that rocks.
      • rit 15y ago
        While this is a statement in some ways of preference it is a reasonable comment; not sure why it's getting downvoted. However, can you clarify why you would argue for type classes over duck/structural typing? You indicate that 'type classes are the way to go' but don't explain why. Scala of course does have a form of Type Classes and while they tend to be what I reach for more often than Structural Types in Scala, it doesn't obviate Structural Types completely and I'd be interested in analysis of the diffs.
• TheBoff 15y ago
  This is a good article, but I must take issue with "Static typing allows you to generate the optimum bytecode/binary", simply because whilst you generally get faster binaries, you can't know that it's optimum. Just a nitpick, though.
  • bad_user 15y ago
    Another nitpick -- static languages on top of the JVM are indeed able to generate faster binaries. But that's only because the JVM was optimized for Java. And the fastest language around, X86 (or MIPS) assembly, is completely dynamic and loose. I don't think it's a secret that commercial Smalltalk VMs kicked ass while executing one of the most dynamic languages in existence ... where performance was (and still is) comparable (even better in some tests) to the JVM or .NET
• st0p 15y ago
  Interesting article, but I did wonder what he means with this: Duck typing allows to reduce immensely the coupling between your classes Can anybody explain?
  • js2 15y ago
    Let's say that I have a list of objects of mixed type, and I only care that they implement a given method. With duck typing, the types of the objects need not be coupled via a common base class (or even interface). For example: # Less coupled class A: def foo(self): print "A" class B: def foo(self): print "B" for x in (A(), B()): x.foo() vs: # More coupled class Base: def foo(self): pass class A(Base): def foo(self): print "A" class B(Base): def foo(self): print "B" for x in (A(), B()): x.foo()
• orangecat 15y ago
  I don't get the claim that dynamic typing requires more unit tests. Sure if you pass a string to a Python function that expects an int it will blow up at runtime, but is there any value in testing for that?
  • snprbob86 15y ago
    If you are doing TDD and are aiming for near complete specification and coverage, then dynamic languages and static languages will pretty much require the same number of use cases. However, most people don't do TDD. With a dynamic language, your compiler isn't doing entire categories of checks for you. You're putting more responsibility on the tests, so you wind up writing more of them sooner and running them almost as frequently as static language users run their compilers! Since people generally stop long before 100% coverage, you wind up with far more tests for the average dynamic project than the average static one.
    • jhpriestley 15y ago
      Complete specification is impossible with tests, except for functions with finite domains. Testing is about reducing bugs to a certain level. Entirely different techniques - namely formal proofs - are required to eliminate bugs. Strong static typing is more effective than tests, in terms of cost/benefit, at reducing bugs.
  • jhpriestley 15y ago
    Static types can encode a lot more information than that. For example, suppose that you are compiling an AST. You start with an AST whose leaves are of type String (identifiers). You want to slot in something else, like pointers to a link table, or values, etc. Maybe some identifiers are builtins which will modify the AST, or user-defined macros, so the transformation will be non-trivial. In a static language, this transformation would be typed as `AST Identifier -> AST Value`, or the like. This guarantees that you haven't missed any identifiers. The guarantees provided by static typing tend to be somewhat orthogonal to the guarantees provided by testing. Testing ensures that, in some particular cases, the function works exactly as it should. Types ensure that, in every case, the function satisfies some properties that it should. The ideal would be every case and every property, but this is only possible with complete proofs. In my experience, types catch more bugs with less effort than tests.
• bkudria 15y ago
  What's a well-designed statically-typed language whose syntax resembles more Ruby than Java/C/etc. I'm thinking something like SML. Any others?
  • primodemus 15y ago
    CLU comes to mind. http://en.wikipedia.org/wiki/CLU_programming_language http://en.wikipedia.org/wiki/CLU_programming_language A hello world sample: http://hopl.murdoch.edu.au/showexample.prx?exp=59 http://hopl.murdoch.edu.au/showexample.prx?exp=59
    • bkudria 15y ago
      I was hoping for something a bit more ... modern. A real language used in production systems.
  • zacharypinter 15y ago
    Perhaps mirah? http://www.mirah.org/ http://www.mirah.org/
    • bkudria 15y ago
      My problem with Mirah is that it combines Ruby semantics and design with basic type checking. Mashing two wildly different things together does not a good design make. (Usually.) I want a well-designed statically-typed language, designed that way from the ground up, with a well-thought-out type system, and no insecurities about appealing to C/Java "braces or death!" types So far my list includes: Eiffel, Haskell, and ML. Note, I have nothing against dynamic languages - I'm a Rails programmer.
  • timclark 15y ago
    Fantom - http://fantom.org/ http://fantom.org/
    • bkudria 15y ago
      Aaargh! So many braces! My eyes! (Seriously, though, what does this have over Scala?)
• smcj 15y ago
  Scala 2.9 was released as well as Akka 1.1 today. The companies behind have been merged to a new company called Typesafe which offers Training, consulting, support and a tool stack containing Scala, Akka, Eclipse and SBT. The persons behind it read like a who-is-who of the JVM world: http://typesafe.com/company/team http://typesafe.com/company/team