3 ms·
We simply disagree on this. I would rather use almost anything else except the random DSL wasteland that is Scala. Even Ruby or Python (with the horrible GILs
by MetaCosm 13y ago
We simply disagree on this. I would rather use almost anything else except the random DSL wasteland that is Scala. Even Ruby or Python (with the horrible GILs) is preferable.
The groups I worked with made different determinations than your team, but if you guys love it, enjoy. Seriously, if you find a technology your whole team loves, you are KILLING it.
Both companies I worked with have since dropped Scala (after literally hundreds of thousands of dollars spent on the attempts) entirely internally due to maintenance and talent acquisition issues.
- trailfox 13y agoI would rather use almost anything else except the random DSL wasteland that is Scala In my experience very little Scala code uses DSLs. Learning Scala isn't that tricky for anyone who knows Java, which is a pretty big pool.
- pivo 13y agoThat was not my experience with Scala. Every library we used had its own DSL and that made the code really hard to read. Maybe things are different now, but I'll bet that was a lot of people's first experience with Scala. It's what turned me off to the language, even though I did like using the standard Scala library quite a bit. Edit: It was two years ago so other than Lift and some SQL DSL I don't recall which libraries we were using. I do recall wishing I hadn't taken that job.
- trailfox 13y agoThat's pretty odd. What libraries were you using?
- nimbix 13y agoMy "favorite" part of Scala was half a dosen DB libraries each re-implementing SQL as a DSL.
- trailfox 13y agoC# does that too. It's called LINQ and it's very popular.
- nimbix 13y agoAre there a number of slightly different and incomplete variants of LINQ, like there are SQL DSLs in Scala? Because if not, then LINQ is "the right way" of doing this kind of thing. And if I remember correctly, LINQ is also useful outside of the DB domain, for things like filtering arrays and so forth. I once read an article about how Java programmers can hold a conversation on the topic of upsides and downsides of multiple dependency injection containers while C# programmers only have one available and have nothing to say on this topic. That article concluded that having one "good enough" solution can often be better than having multiple slightly different and incomplete ones, even if each has its own strenghts, and I'd say the same is true when it comes to the C# LINQ vs. Scala SQL DSLs.
- trailfox 13y agoC# has various options (see: http://stackoverflow.com/questions/671231/linq-nhibernate-alternatives-equivalents http://stackoverflow.com/questions/671231/linq-nhibernate-al...) The Scala equivalent is called Slick, and it's the only SQL DSL that approaching anything near widespread use. I fail to see how incomplete projects on GitHub which happen to be written in Scala are relevent to this discussion.
- dennisgorelik 13y agoIt's NOT called LINQ in C#. You are probably referring to "LINQ to SQL" which is different and significantly less popular technology than LINQ.
- AKarimi 13y agoOr "LINQ to EF" which you can suppose it stable just when working with "MS SQL Server".
- oulu2006 13y agoInteresting, I'm from Sydney and we are seeing a large increase in Scala developers becoming available. Several large companies have been hiring them by the truck load and the local Scala meetup regularly gets 50-80+ people. I too suffered a bit from DSL hell, especially some of the more extreme examples like the library "dispatch" where you need a "element lookup table" to figure out which squiggly line to use. But once you have a stable set of dependencies the initial DSL influx subsides and you start to work with a fairly manageable subset of them on a day to day basis.
- dragonwriter 13y ago> Both companies I worked with have since dropped Scala (after literally hundreds of thousands of dollars spent on the attempts) Hundreds of thousands of dollars is on the order of, what, 1 engineer-year?