class scala[A] { def apply[B](f: (A) => B) = directly to forehead }

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > class scala[A] { def apply[B](f: (A) => B) = directly to forehead }

Steve French: Sep 8, 2003

triple sulk posted:

The shortest answer for this is that it isn't worth it for companies to bring on developers who don't already know Scala incredibly well. It's not a language worth using in 2015 and you'd be better served by sticking with C# or trying out one of F#, Haskell, or Clojure.

I was hired to write scala having not written a line of it.

Sedro posted:

JDBC isn't async so slick can't be async (of course you can still wrap the code in Future { ... }).

I'd be careful with that http://stackoverflow.com/questions/22169757/asynchronous-transaction-causes-illegalstateexception/27263242#27263242

# ¿ Mar 16, 2015 20:26

Adbot: ADBOT LOVES YOU

# ¿ May 10, 2024 12:32

Steve French: Sep 8, 2003

Cryolite posted:

Are you in the Bay area, or a more normal city/place?

What did you do before? Lots of Java?

The Bay Area. Before this, a lot of ruby, and before that, a lot of C. Basically, what sarehu said. If you are working in a relatively obscure language and looking for language experts rather than very smart people who can learn, you are doing it wrong. If it is a popular language, then maybe you can afford to be picky and only look for experienced people because there will be a lot more of them to choose from.

If my situation is unique to the Bay Area, it's because everywhere else has gotten it wrong, not the other way around.

# ¿ Mar 20, 2015 16:41

Steve French: Sep 8, 2003

pigdog posted:

I don't even know Scala but you sold me on that operator.

+ is indeed a handy operator; you may find however that it is hardly unique to scala.

# ¿ Mar 31, 2015 17:45

Steve French: Sep 8, 2003

KernelSlanders posted:

+ isn't really an operator in scala, just an infix notation method call. (_+_) is syntactic sugar for (a, b) => a.+(b)

I was mainly pointing out that the expression (_ + _) is not itself some single operator but rather a composite of multiple things.

I know that scala doesn't have "operators" in the same sense as some other languages, but still in languages where "operators" are just methods with those names they're usually still referred to as operators. However, it is not quite the case as you imply that + and other "operator like" methods are just normal methods. Scala defines "operator characters". There are still special cases. Specific to your comment, there's a reason why 1 + 1 * 2 == 2 * 1 + 1
+, -, *, and the like are handled specially when periods and parentheses are omitted to maintain expected operator precedence.

Some other special cases:

methods that end with : (e.g. ::, +:) are right associative (e.g. 1 :: list is list.:: (1)) (I'd love to know a way to get smilies not to render in fixed bbcode tags)
the only valid unary prefix operators (I believe) are +, -, !, ~
otherwise alphanumeric method names ending with operator characters must have an underscore before the operator character (butts_!, not butts!)

Steve French fucked around with this message at 16:33 on Apr 2, 2015

# ¿ Apr 2, 2015 16:30

Steve French: Sep 8, 2003

I've experimented some with the cake pattern and really struggle to come up with solid justifications for doing so. Has anyone done much with macwire, or used it as outlined here?

http://di-in-scala.github.io/

I have to say I like the high level idea: start with dead simple constructor injection, and then make use of more advanced techniques and tools as you need them. Sharp contrast with the cake pattern, which is more "all boilerplate all the time", and makes things often very difficult to construct dynamically based on configuration.

# ¿ May 10, 2015 04:50

Steve French: Sep 8, 2003

DholmbladRU posted:

Running into an issue with Slick and am unsure how to troubleshoot. Have a database table with a column which is of type Time. When I attempt to query this column I receive the above error message. Has anyone encountered this issue before? I know its an issue with the type because if I change it to integer or something else the query works perfectly.

Below is the DAO

code:


protected case class SomeRow(id: Int, companyId: Int, someTime: Option[DateTime] = None)

protected implicit def GetResultRow(implicit e0: GR[Int], e1: GR[Option[DateTime]], e2: GR[Byte], e3: GR[DateTime]): GR[SomeRow] = GR{
prs => import prs._
  SomeRow.tupled((<<[Int],<<?[DateTime]))
}

protected class LU(_tableTag: Tag) extends Table[SomeRow](_tableTag, "SOME_TABLE") {
def * = (id, allotedTime) <> (SomeRow.tupled, SomeRow.unapply)
/** Maps whole row to an option. Useful for outer joins. */
def ? = (id.?, someTime).shaped.<>({r=>import r._; _1.map(_=> SomeRow.tupled((_1.get, _2.get)))}, (_:Any) =>  
throw new Exception("Inserting into ? projection not supported."))

/** Database column ID DBType(INT), AutoInc */
val id: Column[Int] = column[Int]("RECORD_ID", O.AutoInc)

/** Database column SOME_ROW DBType(TIME), Default(None) */

}
}

query

code:


DAL.SomeRow.filter(_.id === 1).firstOption

I see no above error message

# ¿ Jun 16, 2015 03:39

Steve French: Sep 8, 2003

Fill in the blank:

code:

def justDoingSomeThings(mapping: Map[Int, Int], key: Int): Int = mapping(key)

...

justDoingSomeThings(m, 1)

to make this throw:

java.util.NoSuchElementException: key not found: wut

(verbatim)

Steve French fucked around with this message at 03:01 on Sep 12, 2015

# ¿ Sep 12, 2015 02:58

Steve French: Sep 8, 2003

Steve French posted:

Fill in the blank:
code:
def justDoingSomeThings(mapping: Map[Int, Int], key: Int): Int = mapping(key)

...

justDoingSomeThings(m, 1)
to make this throw:

java.util.NoSuchElementException: key not found: wut

(verbatim)

Here's a hint / secondary challenge. Same method definition, but different code in the blank and instead of the last line, this:

code:

assert(justDoingSomeThings(m, 1) == justDoingSomeThings(m, 1))

to make the assertion fail.

# ¿ Sep 12, 2015 03:14

Steve French: Sep 8, 2003

Sedro posted:

Sure, just change the default value

code:

val m = Map[Int, Int]().withDefault(_ => throw new NoSuchElementException("key not found: wut"))
val m = Map[Int, Int]().withDefault(_ => Random.nextInt())

Hrm, I suppose the question was a bit underspecified, since clearly there are other ways than I had in mind to get that behavior.

This came up due to some surprising behavior of mapValues, which actually creates a view under the hood, even though its type signature doesn't really indicate that (e.g. you can't call force on its result).

code:

val m = Map(1 -> "wut").mapValues(Map("oh" -> 2))
val m = Map(1 -> "wut").mapValues(_ => scala.util.Random.nextInt)

# ¿ Sep 12, 2015 03:54

Steve French: Sep 8, 2003

KernelSlanders posted:

Has anyone used Ammonite? What did you think of it?

The creator of it gave a (really good, entertaining) talk about it at Scala by the Bay a few months ago and I have been meaning to try it since then (the repl, not the shell), but haven't gotten around to it yet. Looks really promising. I'm on vacation for the rest of the month but plan to give it a shot afterwards; I will report back.

# ¿ Oct 18, 2015 16:57

Steve French: Sep 8, 2003

FamDav posted:

it is for the dumbest of reasons - providing a className to a logger instance that is mixed in as a trait.

edit: the logger trait isnt the trait being mixed in at instantiation time.

If whatever logging library you're using works the way I'd expect, it seems like the right thing to do is to just mix the logging trait in with the parent class. If you're using the class name as the identifier for the logger, any anonymous class that extends the parent class is going to use the same logger anyway. Instead of:

code:

class Foo

new Foo extends Thing with Logging {
  ...
}

do:

code:

class Foo extends Logging {
  ...
}

new Foo extends Thing {
  ...
}

# ¿ Nov 5, 2015 22:17

Steve French: Sep 8, 2003

Hughlander posted:

I'm working in an existing code base with a horrible method with 18 arguments, along the lines of:
code:
def Foo(bar: Bar,
        moo: Moo=null,
        zoo: String=null,
        bleh: String = null,
        <repeat 15 times>)
I'd like to partially apply the function so that you specify the Bar as expected, but the zoo is fixed, while the callers could still apply moo/bleh et al. IE something like:
code:
val myFoo = Foo(_: Bar, zoo="gently caress you")
val Something = myFoo(thisBar, bleh="Such poo poo")
Is there a way to do so or what would the approach be if I can't touch Foo?

I don't think there's a way to do that without either losing or repeating the default values of null.

# ¿ Nov 10, 2015 20:42

Steve French: Sep 8, 2003

Tarion posted:

After using scala for about a year...

The good:

1. for comprehensions definitely can make using futures for async programming nice.

The bad:

1. Linked List as the default data structure.
2. Implicits make reasoning about things hard.
3. Cake really should be called spaghetti.

The ugly:

1. 'return' statement.
2. Collections libraries.

Overall, my impression is that it's a nice research language that various people at big companies decided to use in production because it was cool rather than because it was ready.

You mean linked lists as the default ordered collection. I don't see that as much of a negative. It's quite easy to use something different if need be, though there are a lot of warts (hidden or otherwise) in the collections library. I still prefer it to any other language's standard collections though.

Implicits, if used excessively or improperly, can be tough, but it also enables some really great general patterns and simplifications if used well (see: typeclasses)

I agree about the cake pattern. Gave it a try, do not like it. I much prefer the gradual and pragmatic approach outlined here: http://di-in-scala.github.io/

What about the return statement? You don't like that it exists? (I rarely use/encounter it)

For what it is worth, I fully believe it is a production ready language, and use it as such. There are a lot of really high quality tools built with/for it. Finagle, in particular, I find to be excellent.

# ¿ Dec 18, 2015 04:59

Steve French: Sep 8, 2003

Where have you found that every interface uses lists? (what libraries, etc)

That has not been my experience.

# ¿ Dec 19, 2015 17:29

Steve French: Sep 8, 2003

I can't really speak to much regarding Akka, as I have limited experience with it.

However, consuming Twitter streams is probably the most common example project that I've seen for Storm, so maybe take a look at that.

# ¿ Dec 21, 2015 23:48

Adbot: ADBOT LOVES YOU

# ¿ May 10, 2024 12:32

Steve French: Sep 8, 2003

WINNINGHARD posted:

If you're interested in messing around with apache spark and scala, databricks has a free community edition.

https://databricks.com/try-databricks

Unfortunately, databricks configures the spark cluster to their own specs, so optimizing lower level stuff is out of the question

I use it at work and I wish we'd bit the bullet and configured it ourselves. The shell access is a little borked and exploring the filesystem is a pain too. That being said, getting a handle on spark pays dividends - it's really fascinating all the things you can do.

Does anyone here have ideas for scala projects for learning the language better? I do webdev and ETLs at work and I really did not like the Play framework.

If you didn't like Play but would like to do app/service development in Scala, I'd take a look at the Twitter stack stuff. I've been working with it for just about 3 years now and have been pretty happy with it. Check out finagle/finatra.

# ¿ Jun 11, 2016 07:04

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > class scala[A] { def apply[B](f: (A) => B) = directly to forehead }