Win a copy of Svelte and Sapper in Action this week in the JavaScript forum!

Josh Suereth

Author
+ Follow
since Jan 24, 2013
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Josh Suereth

@Ivano -

That's exactly what I see happening. Lift focuses on server-side owning "state" of a client's experience. The rest of the web is moving the other direction. Right now, if you compare Play vs. Lift I think Play embraces the notion that it is just a data-munger to a greater extent than Lift, hence my concern for Lift.

Lift was highly opinionated, and they met their objectives well. Unfortunately, I haven't seen the general web embrace heavily-server-side frameworks, with GWT being the one that comes to mind as having the most success. It seems there's been a division between programmers who work on the server, and those that work on the client. GWT suffers the "Server side developers love it, because they aren't comfortable in the client side" and "client side developers hate it, because they want access to the browser + javascript". Granted, that's a simplification, but I think the same split will work against Lift in the long run. More and more web-designers are learning Javascript, JQuery, Angular, Backbone, Ember, etc. These frameworks are driving the state of the art for client-side *AND* are more comfortable for web-designers. While Lift/GWT will always have a niche they fill well, I think the more mainstream web development will continue to push for client-side frameworks and servers that data munge. Heck, even PHP tutorials I've seen recently are all about generating JSON which really seems wrong (given how PHP was designed...).

So yeah, I agree with you, the web is moving towards client-side heavy, stateful, powerful apps. Anyone not riding the current will be struggling to stay mainstream, regardless of the merits of their underlying technology.
7 years ago
That's exactly the answer I think.

Play is *stateless* MVC based webframework.

Lift is *stateful* "View-First" component framework.


Lift does a lot with saving "continuations" on the session to execute on later requests. You code components that tie to views and then set up your pages by stringing together a set of HTML components on the page.

Play takes "stateless MVC" to an art-form. It's a very lightweight framework with a set of minimal conventions to get up and running. Play has really good support for asynchronous programming and pulling together a bunch of disparate data and streaming it as a result. It also focuses heavily on *developer experience*, providing their own SBT project defaults, along with a customized plugin that redoes the experience for developing a Play application.

I think they both have compelling use cases. However (opinion warning), with the push of HTML5 and ever faster javascript engines, the web continues to move in the direction of "Heavier clients" where the client does rendering, stores cached data, and controls flow of the application. Heck, in some modern browsers, the page can alter the URL itself (not just the hash) without a page refresh. While Lift has some really neat/compelling features, my concern is that the Javascript/Front-End developers are running the other direction.

Again, it remains to be seen what happens in the long term, but that's my view of things.
7 years ago
I know lots of people coming to scala to define DSLs. There's even a research group using Scala as a host language for highly-parallel C++ backends -> Delite.

I've done quite a few DSLs in scala. I'm starting to think less of them as "DSLs" and more "Well written libraries". A good library should be as close to the domain (and the mindset of the person in the domain) as possible. Scala's flexible syntax makes this easier. However, sometimes people go overboard to make everything look like english. I personally feel there's a line between "Elegant library/DSL" and "Overboard on the syntactic sugar".

In any case, yes, Scala is a great langauge for DSLs. My first 20% projects at google was a Scala DSL around MapReduce/Flume that I was quite proud of: Scala Distributed Parallel Collections
7 years ago

qunfeng wang wrote:Hi Author,

I took the coursera course Functional Programming Principles in Scala by professor Martin Odersky. It's a great learning experience. In the course, professor Martin Odersky mainly focused on functional programming. I'm wondering which paradigm to choose in the real world programming with Scala.

Thanks,
Qunfeng




You should choose the paradigm that works for the problem you're solving. A lot of teaching/training we do in Scala is *forced* to be functional style, because we assume students are unfamiliar/uncomfortable with functional-style and the only way to really learn is to force them to immerse themselves.

You will notice that Scala has more powerful OO features than Java (traits, self types, early initializers, etc.) and also pulls in much of the functional concepts. It is a blend, and therefore in *practice* most of my code is blended as well. In my current project, I find myself using 3 paradigms:

Akka/Actors for the backend server, OO for exposing interfaces and Services, Functional Programming style inside Play for munging data around and sending it to the client.

When it comes down to it, each paradigm has different strengths, and is suited to different tasks. If you use the right paradigm in the right spot, it will serve you well.

For example, one frustration I have with a lot of FP languages is the lack of namespacing and "module systems". Scala actually provides a pretty nifty way to namespace functional code -> Objects. You can even extend full-on packages if you use nested objects/classes in traits. Some of the most advanced FP users in Scala are doing wonders with its OO system for packaging their software: Bake Me A Cake - Precog.

7 years ago

Raymond Tong wrote:Would that be any advantage if I learn Haskell before Scala?



There's always advantages to learning new languages that are far outside the paradigm you're familiar with. Haskell is a nice elegant language that pushes you into a particular direction when coding. While learning ML may be more helpful for using Scala, you won't be disappointed learning Haskell, and you can apply a lot of things you learn inside Scala.

However, don't feel you need to learn Haskell before entering Scala. There's enough in Scala that's comfortable to make the transition without having to dive into the deep end of new concepts. I do recommend wading over to that end eventually, but it's not necessary.
7 years ago

Rogerio Kioshi wrote:

Bear Bibeault wrote:Concurrency is the major thing I've heard bandied about.



Concurrency, like threads programming?



Actually no. A fundamental idea in Scala is that threads programming is rather more difficult than worth it for most shops.

As an example, Scala has added "Futures and Promises" to the language. I recently gave a talk on multi-thread asynchronous programming that I think highlights the kinds of *different* things you can do with concurrency in scala: Functional Programming Patterns for the Asynchronous Web

Most of the code i their is pseudo-code, but it highlights the features of Scala that enable asycnhronous & concurrent programming to be far more elegant than Java.
Language features that make this style programming easier:
* For-expressions (monadic style)
* Closures

As already stated, "Akka" provides a different model of concurrency known as Actors. Actors are a simple way to express *concurrent processes* in such a way that very little actual machine locking occurs. It helps you design a concurrent application in many different ways, but is by no means a silver bullet. Essentially, akka views the world as a set of objects that can only communicate through asynchronus messages and each one has its own conceptual thread.
Language features that make this style programming easier:
* Closures
* Pattern matching

If you take a look at Scala's Future class vs. Java's, you'll notice that Scala's is far more powerful (and IMHO more useful) for actually gaining asynchronous concurrency and chaining together a set of tasks. Java's Future is more about "fork-join" style concurrency, where you *have* to join back on a future to get its result.

7 years ago
One thing I'll say about play and learning it:

They use some more advanced Scala-isms. If you're learning it the way I learned rails, you'll look at things and think "MAGIC". After you're comfortable with Scala, the API will start to look just like a convenient library of stuff. The Java api, by extension, tries to be as similar to the scala version. This involves a lot more "actual magic" vs. "good language". Grails is similar, in that Groovy does the heavy lifting to make the usual spring APIs nice and simple.

As far as the future of Play, it's heavily hitting the Asynchronous-style development, trying to simplify that style to the point it's as "easy" as synchronous-style code.

We're using Play 2.1 and Akka in a project I'm working on now. Slinging together some Async calls and feeding them out a socket for HTTP is pretty dang simple. While the Akka-Actor -> Play Enumerator bridge isn't as nice as it could be, it's not too many lines of code to accomplish everything you need.

Having used both Grails and Play, I think I'd pick Play at this point because it gets out of the way of what I need to do *even more* than Grails. Again, I may be biased. However, when I first saw Play I was wholly unexcited. It wasn't until using it in anger, that I learned i liked it.
7 years ago
Funny enough, the original proposed title for "Scala In Depth" was "Effective Scala", however we had to change the flow of the book due to need. Basically, it's hard to talk "Effective Scala" when a large portion of the audience still needed to understand implicits, type systems and the styles and conventions more common in functional programming.
7 years ago

Bear Bibeault wrote:Two thoughts:
They're locking themselves out from a lot of existing enterprises that aren't going to change their deployment strategies anytime soon. And even small guys -- like the one I'm doing some work for -- that don't have a dedicated IT staff, aren't going to risk moving off something that they know works and is up and running. If I tried to get him to adopt heroku or something similar, he'd think I'd gone crazy.

But that balances with new and upcoming companies that are looking to use the latest bleeding edge stuff. It remains to be seen how all that will shake out.



That's the case with a lot of "cutting edge" software. Eventually if young hip new projects keep picking it up, it'll be the older safer technology in a few years. Yes, some enterprises aren't going to pick it up immediately, but some enterprises are still successful using COBOL. Different organizations have different needs, and Play is targeting a different market for now.

IIRC, someone has adapted play to work within WARs and JEE. I think you could definitely have such a thing, but most likely if you're the same organization that is unwilling to move from JEE containers, you may also have issues moving frameworks. I think these kinds of backports are probably a better way to go for larger adoption than to veer the central core of the framework.

The practical bit, is we're seeing clients pick up and use Play *beside* their JEE applications, even large more conservative organizations. Perhaps the path to success is longer, but hopefully the *life* of the framework is also longer because it's forward thinking.

Bear Bibeault wrote:

Josh Suereth wrote:I'm not certain it'll block *scala* adoption.


But Scala adoption is, in my opinion, most definitely tied to the "killer app" that's going to make people want to use it. It's not going to go much of anywhere just because developers think it's cool. Given the relatively minor foothold that Play has attained, and the general dissatisfaction I hear with Lift, it doesn't exist yet.

I hear a lot of "Scala is the next Java" from a lot of its fans, but few that I know are actually using it for anything but play-ware (small 'p').

What, in your mind, is the compelling use case that's going to make corporate decision-makers allow Scala into the enterprise (big or small)? The enthusiasm of the developers for the language isn't going to count for much in any company except the very small or startup where developers are calling the shots. And those are not the companies that will wag the dog.



I think we may be able to agree to disagree here. I don't see Scala as requiring a killer app. It's powerful enough to compelling *on its own*. Play migrated to an all scala-backend *from* a java/scala backend. Why? Because of the language. Akka is implemented in Scala *because* of the language (although is supports a Java API).

SO here are what I see Scala's killer features *for corporate decision makers*

1. Reduced code size in general. Helps limit the number of bugs just by virtual of having less code (statistical correlation)
2. Improves the development code speed of the "top-tier" programmers (circumstantial evidence)
3. "lower-tier" programmers code abilities/speed *appears* unaffected (circumstantial evidence)
4. Multi-core program is easier in Scala, not because Java can't handle it, but because Scala embraces patterns and defaults that work well with lots of threads. Its libraries take a similar approach. So, while Scala's future's APi can be used in Java, it's far more elegant (and harder to screw up) in Scala. This means on *average* using Scala and its paradigms should help leverage more power from your machines.
5. Type safety. Unlike dynamically-typed languages, Scala can help a large team maintain a code-bases (refactor safely, etc.) and write less testing code for similar levels of coverage. This means better working code with less effort. It also means, IDEs can be far more helpful.

Basically, Scala helps improve developer speed, reduce codes (through reduced code size) and push developers towards multi-core friendly paradigms (taking better advantage of hardware).


In terms of the killer *language* features for *developers* (more concrete) -> In order of how important I find them on a daily basis.

1. expression oriented/typeinferred syntax. Everything returns something. The compiler attempts to figure out what, if it can.
2. Pattern matching (A lot of languages fail to have this, and it's be far the most used language feature for me on daily code)
3. Closures (This is less compelling as other languages add them, however the way they exist in Scala is fairly elegant and simple to understand).
4. Collections library. Scala's standard collection library is *WAY* better than any other language I've used in terms of being productive and getting info out of data. Once you learn it, you wont' want to use another.
5. Implicits. Scala's implicit system allows you take the "edge" off an API by allowing defaults to be specified once within a scope and not again until configuration is necessary.
6. traits. Scala allows a limited form of mutliple inheritance, that among some surprising things, allows an encoding of virtual/extension classes that works well with FP code. See "cake" pattern as used by Precog.
7. type system - Scala's type system is more advanced than a lot of other languages. It features the union of some really-tough-to-join ideas. In certain tricky situations, Scala can express some nice behavior that would be rather ugly in "more popular" statically typed languages (like C#/Java).



Of course, this is my opinion and some of the points are "circumstantial" in my experience. Would love to hear your thoughts.

7 years ago
I'm not certain it'll block *scala* adoption. My first production app with Scala was a JEE JBoss application where we started using Scala (and the loan pattern) to handle some tricky transaction atniques with JMS messages.

You are correct that Play not running as a WAR means you can't deploy it to a traditional app server. However, I think in this case the benefit is definitely worth it. It's taken the JEE specs a while to cope with emerging technologies and evolving hardware, while Play was able to pick up the best-of-bred HTTP JVM server technology (Netty) and directly use it. While some web servers were supporting alternative APIs (like Jetty), it was a long time before all the rest of the containers caught up. Forcing users to use Jetty to take advantage of features isn't much different from just using *one* hosting technology and given that your full effort.

So yeah, I understand there's a lot of tools and such out their for WARs. You can still use Scala with JEE technology. Play itself decided to go a more opinionated route. My opinion, is that Java itself may be moving this direction as well. At least, the things I saw in the Jigsaw branch lead me to believe "standalone java application" will become a far more conventional, and easy to manage, deployment option. Granted, we're taking far down the road, but Play! is a forward thinking web-application framework.

7 years ago
I don't think Typesafe is aiming to release something quite so heavyweight as either Spring or JEE. If you look at our offerings, you'll see that Play is a webframework designed to get out of the way of other technologies, like front-end JS frameworks, or back-end server processes. Akka is similar in that, for the domain it solves, it does it very well, but can still interact with existing services.

I gave a talk at Spring One this year about leveraging akka *with* spring, embedded in a way that you could take advantage of both "frameworks".

For the most part, The Typesafe 'stack' aims to be a loosely coupled affiliation of well-maintained libraries that cover as many aspects of development as we can. Akka focuses on concurrency, Play focuses on moving data around in HTTP servers, and SLICK focuses on getting data into and out of RDBMS or NoSQL stores.

Really, the goal is to be a lightweight stack. For Example, Play comes with "anorm" out of the box, but it's quite easy to insert your own ORM.

Rather than issue "Standards", ala JEE, or require a full on container, ala Spring, the Typesafe stack aims to be a set of building blocks, with a default foundation you can use, or toss out, depending on your needs.


Hope that helps!
- Josh
7 years ago
I think Scala is doing better with greenfield projects, but we're seeing it venture into existing ones as well. As far as domain, I've seen a whole gambit, from trading to "webapp is the product" to health care.
7 years ago
Another one you may be missing is Juniper Networks.

While I can't just list the set of clients that typesafe has, I will say that Scala *is* seeing increased adoption in larger corporations. At this point, it's still the kind of thing that's hush hush, and not public. SO the ones most people know about are the ones that were non-public a while ago, and are now announcing.

Having been in the scala community since 2006/7-ish, I'll say that we're seeing a *lot* of companies taking serious looks at scala. In particular, Akka has been a prominent driver of adoptions for folks who already have large JVM systems and are looking add new services.

In any case, from what I can see in my neck of the woods, Scala adoption is on the rise. More conservative organizations are in the evaluate/prototype stage right now. Once a few them are successful, I think we'll see how many more announce public Scala usage/projects.


That's my $.02, would love to hear others.
7 years ago

Matthew Brown wrote:(Is it all the books all week, or are they on specific days?)



Specific books on specific days. You can see the list of which books on which days here: Typesafe Blog: Week of Scala
7 years ago

Daniel Sobral wrote:So the Scala in Depth promo is out, and I've RT it. I wonder if Josh thinks Scala in Depth needs to be updated with Scala 2.10's new features -- or, perhaps, Scala 2.11, as they won't be experimental at that point anymore?



I think the books stands pretty well for Scala 2.10. However, I will be (trying) to release an updated version around the time 2.11 comes out. By then, there should be enough changes that I can alter certain portions of the book.
7 years ago