Scala as an SOA Platform? How can we start making Scala business viable?

[kraythe]

Greetings, let me introduce myself. My real name is Robert Simmons and I am a very Senior Java Developer who has been doing Java since 1.0. I have written two books on the language (namely "Hardcore Java" in 2003 and more recently "Maintainable Java" which is eBook only). So I know my way around the Java language. I have seen Java go through a lot of iterations, growing pains and so on. I know its strengths and its weaknesses. This is what brought me to the Scala Language. I have done a couple of projects in Scala but I wouldn't say I am an expert, at least not yet. ;)

So I wanted to bring you all into my latest brain storm and solicit input from the community. Lets try and keep it professional even though I will start by throwing a bomb. Well, a debate bomb. :) 

Scala has a lot of promise in the future but I see a couple of current problems. 

1) You can be a mediocre dev and handle Java (albeit not well) but you cant handle Scala unless you have a good grounding in Computer Science. Unfortunately the IT industry subsists on a large number of mediocre developers and that is just a practical reality that has to be faced. As the language matures this issue might abate due to accumulated knowledge and good API development. 

2) The Scala community needs a standards approach rather than just a rapid agile environment. What I mean by this is that when you constantly break binary compatibility with previous releases, it makes it a tough sell to executives. Furthermore, if I go to sell using Java to a company, I can point out standards bodies and other respected business entities. With Scala, the sell is much tougher. 

3) The reason for my post, is that Scala needs a viable SOA platform. 

Lets take some well known frameworks in Scala and look at them from a business point of view. Now I know there are actual businesses using Scala and that is beside the point. Early adopters have to be set aside in this debate and we have to tackle the concept of getting Scala into well established businesses and that has a lot more to do with business than code. 

Lift: Great for development of web apps if you already know Scala. Horrid, if you are a newbie. Beyond that it needs more to be viable for business. 

Play Framework: Again, great for development of Web Apps and easier to use than Lift but still missing a lot of things a business needs. 

So if we were to develop a perfect business SOA platform with pure Scala, what would it look like? What would be the essential features. This is the brainstorm that I wanted to bring you all in on. If I think about J2EE platforms (Glassfish, JBoss as well as the standards under them) I am driven down some paths of thought. 

1) The platform has to have an API to work with that accommodates medium and low skilled developers. If you MUST be an A player to even use it, it wont work in business. You may need to be an A player to extend it, but development should be a snap. 

2) The platform cannot be purely web focused. Although web apps are a big part of modern business, any business with a sufficiently complicated domain needs much much more. Lift and Play do web well, but not other things. 

3) The platform can probably do without the features of IIOP and CORBA. Interoperability with those two old technologies can be accomplished much better through the use of SOAP and REST services. 

4) Yes, we have to do SOAP. RESTful is great for small things but when the domain models get complicated soap is a necessity. There is little point screaming about it. Also if the platform can't talk SOAP, it can't interoperate with existing Business applications and that is a deal breaker. 

5) The platform has to be standards based. Although one can be implemented in scala without doing a waterfall standards approach, the standards should be developed in an agile manner so that there is the possibility of more than one vendor in the space. Businesses hate being locked into only one platform without competition. 

6) The platform has to define better separation of business logic and presentation than all prior platforms to give it a great selling point. The promise of true UI / Service separation should be finally realized. This is an odd thought perhaps but what if the platform didn't do web at all, it didn't do templates (groovy, scala or otherwise), didn't do anything except the back end SOA. If we freed the platform from all of those issues, then true separation could happen. Bear with me here: 

Lets say we were developing a big product with a big back end and some Administration console with a customer UI; the amazon model (aka the E-Superstore). We have a UI for customers, also for shipping and administration of products and so on. So we propose our new ScalaSOA as the main bus for this system and the business asks us how the UI will be built. We reply that it will be AJAX based, served on an Apache Web Server. The only involvement ScalaSOA would have is to serve JSON or XML documents to the front end UI. Everything else is handled with static HTML, AJAX or similar mechanisms. Our users will then have a rich front end that can be built by UI designers and graphic artists and they let the devs know what data they need. 

7) The platform would have to implement concepts of clustering, componetized deployments (think EAR files without all of the annoyances of EARs) and so on. 

8) The platform would be able to reload classes at runtime enabling the developer to change apps on the fly such as is possible in play framework. 

9) The platform would be componetized and designed to be extended. With the evolution of J2EE, they had to massively retool the various platforms to comply with standards. Each standard should, instead, be designed to be a component that can be mixed and matched. The vendor develops the backbone bus and can even drop in components for other vendors. Something akin to the OSGI model of providing services. Think of this in the context of an EAR deployment. If there is a standard for SSA (Scala Service Archive) of 1.0 version and it gets updated with 1.1, the old 1.0s should still work if the SOA Platform possesses the component to load the old style. The new one may have more features but the old will still work. 

Anyway, I don't want to just drone on. I would be interesting to hear comments from the other readers of this list even though I have many more ideas. The next step, of course, is to organize the effort. In conclusion i would just like to say that Scala is a great concept, perhaps the next Java. But it needs to pull itself out of R&D and get practical. That means making it business viable. Currently there are few tools on the market for scala that accomplish that. But with youth comes opportunity. :) 

[Raul Raja Martinez]

Not sure if you are serious but I believe you just outlined all of the reasons why many Java devs even experienced ones leave Java, JEE... and all those enterprisey frameworks and world behind. Even in Java all of those are in desuse. The raise of Spring, lightweight containers, etc. are proof of that. Seriously you describe a world that is far away from what devs and dev teams and new companies are all headed to.

--
You received this message because you are subscribed to the Google Groups "scala-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-user+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[kraythe]

Oh I am quite serious and you are quite incorrect. Although there are a lot of academic efforts and dev driven efforts to flee from SOA, the fact is that many businesses need them, despite the annoyance of their devs. I can name 12 MAJOR companies off the top of my head that I have contracted for that have and NEED SOA platforms. 

The problem of Spring is that it locks you in and is not so "lightweight" after all. Once you pull in the spring stack you get mountians of code. I will also point out that spring and all the Lightweight alternatives you pointed out run in .... wait for it ... a servlet container. Spring is just a way to wire together servlets and even if you do Spring MVC, the separation of design and development is minimal at best. Spring's best contribution has been the realization of the concept of IOC injection. And even that is of debatible value. Sure it makes things easy to test but its used WAY too much and in places where it isnt needed at all. Many spring engineers wont even static bind 2 classes at all, nevermind that the concept of "configuring" them is ludicrous because they are so interrelated.

Now when we get out of the realm of "I am a dev and know better" the network engineers running the system need reliable ways of bringing things up and down, alerting on things, monitoring, reporting, clistering, load balancing and so on. The "lightweight" stuff you refer to runs on, yes, a J2EE stack. Tomcat, Jetty and so on.

And I disagree with you about "running from Java J2EE." Java J2EE will be here for a long time, you underestimate its entrenchment in modern business. You cant simply walk up to an exec, say "Im a dev and your current platform is garbage and I will build a new one for you, I just need 6 months to get back to what you already have running in production." "What do you mean no? That code irks my programmer sensibilities!!" You would be at best told to shove off and at worst told to find a new job. 

This is what I mean by the post. Practical business is not Academic development. The two have different goals. The head of amazon could give a darn less about whether the code running the system is PHP, Basic or Scala. All he cares about is supporting his business model. Too many devs get lost in code and their coding worlds and don't see the big picture. 

If there was an SOA platform for scala that would consider the deployment and network engineering as well as interoperate with Java and J2EE, then when you approached the executives on doing a new project and said you want to use scala and explained it would all interoperate fine, then they would shrug and say *whatever* (assuming they can staff a maintenance team.)  But that SOA platform has to go beyond the academic and has to be in the realm of business. Businesses dont care about closures, or structural inefficiencies in writing java code. They care about how fast can you build it, can it work with the rest of my stuff, how hard is it to maintain, how hard is it to deploy and monitor, how can it handle load. 

Which means Lift and Play are just .. not enough. 

-- Robert

To unsubscribe from this group and stop receiving emails from it, send an email to scala-user+unsubscribe@googlegroups.com.

[Oliver Ruebenacker]

Hello,

On Fri, Feb 1, 2013 at 11:13 AM, kraythe <kra...@gmail.com> wrote:
> 1) You can be a mediocre dev and handle Java (albeit not well) but you cant
> handle Scala unless you have a good grounding in Computer Science.

Don't think so. If you can do Java, you can do Scala, as almost any
Java code can be translated on-to-one to Scala.

> 2) The Scala community needs a standards approach rather than just a rapid
> agile environment. What I mean by this is that when you constantly break
> binary compatibility with previous releases, it makes it a tough sell to
> executives. Furthermore, if I go to sell using Java to a company, I can
> point out standards bodies and other respected business entities. With
> Scala, the sell is much tougher.

It wasn't a tough sell to our CTO. In fact, he was one of those who
promoted Scala.

The Specs process for Java is essentially opaque and controlled by Oracle.

> 3) The reason for my post, is that Scala needs a viable SOA platform.

Most Java frameworks work with Scala. I inserted Scala code into a
Java Server Faces app and deployed it to Tomcat. But now my company
switched to Play. Can't identify a need for SOAP.

I suspect when you say businesses, you mean big, old companies.

Take care
Oliver

--
IT Project Lead at PanGenX (http://www.pangenx.com)
The purpose is always improvement

[Raul Raja Martinez]

Surprisingly devs lost in their own worlds are those at big stuffy companies some times. I have worked in one of those and now part of my own company with many other devs. I have plenty of experience with many clients that you can't  sell JEE anymore because their dev's team are growing  tired of it. There is a big tendency in the Java world to go away from JEE whether you like it or not and it has been my experience for the last 5 years. As for Scala it's mostly interoperable with Java and you can mix it in as you may see fits. True that many companies are invested in SOA, SOAP..., false that new ones are even considering it. 

--
You received this message because you are subscribed to the Google Groups "scala-user" group.

To unsubscribe from this group and stop receiving emails from it, send an email to scala-user+...@googlegroups.com.

[Oliver Ruebenacker]

Hello,

On Fri, Feb 1, 2013 at 11:56 AM, kraythe <kra...@gmail.com> wrote:
> Now when we get out of the realm of "I am a dev and know better"

Would you prefer the "I am a manager and I know better" realm? ;)

> If there was an SOA platform for scala that would consider the deployment
> and network engineering as well as interoperate with Java and J2EE, then
> when you approached the executives on doing a new project and said you want
> to use scala and explained it would all interoperate fine, then they would
> shrug and say *whatever* (assuming they can staff a maintenance team.)

Yes, it does interoperate fine. Scala can do JavaBeans, if needed.

[Simon Ochsenreither]

Hi kraythe,
 

1) You can be a mediocre dev and handle Java (albeit not well) but you cant handle Scala unless you have a good grounding in Computer Science.

I would completely disagree with that. I'd say that generally, everything you can do in Java is easier in Scala. I think it is important to not confuse familiar with difficult.

2) The Scala community needs a standards approach rather than just a rapid agile environment. What I mean by this is that when you constantly break binary compatibility with previous releases, it makes it a tough sell to executives. Furthermore, if I go to sell using Java to a company, I can point out standards bodies and other respected business entities. With Scala, the sell is much tougher.

Well, Java has forward-compatibility, Scala has backward-compatibility. Scala would be Java if it hadn't the option to continuously improve all aspects of the language and its backend. Nobody needs a second Java.

Especially in times were Java-on-the-Desktop is practically dead, I would say that dealing with compatibility issues became easier, because you can upgrade the appropriate components instead of having to wait until all customers use the latest version of the JRE. You have to be aware of it and be prepared to handle it, but that's no surprising, unexpected matter.


But generally, I think that every company which approaches Scala with those two assumptions, should stay away from it. Those things are self-fulfilling prophecies. If you tell developers (or pupils, or students) “X is hard”, X will be hard for them no matter what.


Regarding 1) to 9):

I think it was the right decision to choose Play instead of Lift.

There is a lot of work still to be done in Play and the developers of Play acknowledge that.

I agree that the separation between services and UI is important. Actually, the approach to rich client-side JavaScript has done more to further that than any other technology in the last 5 years (at least on the web).
The focus has moved and now we have a different (or additional) problem: How to handle JavaScript gracefully? How to move functionality from the server to the client (or the other way around) without having to reimplement things in a different language? The Scala-JS stuff shows a lot of promise, let's hope that this approach works out. In the Java world, there is pretty much only GWT, which worked on a similar problem. GWT seems to be dead.

Akka addresses many issues concerning large-scale, distributed systems. The next version will get clustering support, as far as I know.

Being in line with all JavaEE standards is hard and sometimes not viable. Example: Play handles HTTP asynchronously. No Servlet spec or implementation supports that at the moment. You can still run Play as a Servlet, you just loose all the benefits related to handling requests asynchronously.
Other standards are just plain horrible. Take the whole JPA/JPQL/CriteriaAPI/Hibernate/... mess. I just don't want that anywhere near me. But apart from that, you can still write Scala applications which use these standards.

I'm not even sure whether the “press F5 to reload”-approach can be implemented when following JavaEE.


In the end, I think that one can't expect innovation and improvements to the state of the art, when everything needs to be done the way it has to been done the last ten years.
Additionally, Scala doesn't solely exist to make Java people's lifes nicer. There are a lot of Python, Ruby, Perl, Haskell, OCaml, C#, ... out there as well as people who never programmed before, which would never ever consider in their life to use Java. Those have very different requirements which also want to be addressed.


Just my few cents,

Simon

[kraythe]

Greetings, thanks for the thoughts, I do have to disagree with you on a number of points. 

First of all if you take java code and translate direct to scala, you are missing the point completely of functional oriented programming. Imperative programming is a different thought model and easier to grasp for those on OO on traditional languages. Functional programming is poweful but requires a certain about of conceptual knowledge. So yes, Java can translate right to scala, but NO, it wont be as good as pure scala. 

Specs process is not necessarily controlled by Oracle or Sun before it. They have a lot less input than you might imagine. If they controlled it completely, companies like IBM, BEA, Apache, JBoss and so on would walk away from the table rather than give Oracle their IP. Its a lot more cooperative than you think and it must be or it wouldnt be of any value for non-Oracle companies to be involved. 

As for running scala on J2EE, sure, you can do that. But I think that misses the true power of Scala. Hence the other playforms like lift and Playframework. 

As for your CTO being a driving force, thats cool .They are early adopters. Im talking about getting it into mainstream business. You can call it "old business" in a derogatory fashion if that is in your political proclivities, however, I am a practical person and I am aware that such vitriol accomplishes absolutely nothing. The sun is what it is, there is little point in screaming at it for rising. 

-- Robert

[kraythe]

Managers make the decisions. That is the way it is. You can either rage against it, or work with it. Raging against it just gets you unemployed and / or your scala goals unrealized. 

And like I said, I want to make a pure scala system to leverage the power of scala, running on JBoss or Tomcat, while possible of course, misses the point. 

-- Robert

[Kevin Wright]

1) You can be a mediocre dev and handle Java (albeit not well) but you cant handle Scala unless you have a good grounding in Computer Science. Unfortunately the IT industry subsists on a large number of mediocre developers and that is just a practical reality that has to be faced. As the language matures this issue might abate due to accumulated knowledge and good API development. 

Scala allows you to do more than Java, to tackle problems you wouldn't have otherwise considered.  Many people discovered this fact and publicised their solutions.  Similarly, simple things are SO simple that it's not even worth talking about them - the potential for describing a simple "Hello, World!" in Scala is non-existent, there's no need to explain what a class is, why you use static, etc. etc.

Which means that the base of publicly visible Scala code on the net is heavily skewed towards "advanced" examples.  This is absolutely not representative of day-to-day usage of the language.

2) The Scala community needs a standards approach rather than just a rapid agile environment. What I mean by this is that when you constantly break binary compatibility with previous releases, it makes it a tough sell to executives. Furthermore, if I go to sell using Java to a company, I can point out standards bodies and other respected business entities. With Scala, the sell is much tougher. 

 We have Typesafe, they're taking binary compatibility VERY seriously.  They offer support contracts.  Exactly what standards do you feel are lacking?

3) The reason for my post, is that Scala needs a viable SOA platform. 

 

No, it doesn't.  Though it would certainly benefit from *libraries* to support SOA features for some users.  But not a "platform" or "framework".  Spring went down that route, it became a monolith and cause a lot of unhappy lock-in.

Lets take some well known frameworks in Scala and look at them from a business point of view. Now I know there are actual businesses using Scala and that is beside the point. Early adopters have to be set aside in this debate and we have to tackle the concept of getting Scala into well established businesses and that has a lot more to do with business than code. 

Lift: Great for development of web apps if you already know Scala. Horrid, if you are a newbie. Beyond that it needs more to be viable for business. 

Play Framework: Again, great for development of Web Apps and easier to use than Lift but still missing a lot of things a business needs. 

So if we were to develop a perfect business SOA platform with pure Scala, what would it look like? What would be the essential features. This is the brainstorm that I wanted to bring you all in on. If I think about J2EE platforms (Glassfish, JBoss as well as the standards under them) I am driven down some paths of thought. 

1) The platform has to have an API to work with that accommodates medium and low skilled developers. If you MUST be an A player to even use it, it wont work in business. You may need to be an A player to extend it, but development should be a snap. 

 

That would be Akka then.

2) The platform cannot be purely web focused. Although web apps are a big part of modern business, any business with a sufficiently complicated domain needs much much more. Lift and Play do web well, but not other things. 

Still Akka.

 

3) The platform can probably do without the features of IIOP and CORBA. Interoperability with those two old technologies can be accomplished much better through the use of SOAP and REST services. 

REST can cover everything, except for interop with legacy systems.  Any SOAP library on the JVM should be fit for purpose.

 

4) Yes, we have to do SOAP. RESTful is great for small things but when the domain models get complicated soap is a necessity. There is little point screaming about it. Also if the platform can't talk SOAP, it can't interoperate with existing Business applications and that is a deal breaker. 

"If you can't talk SOAP then you can't interact with other SOAP apps".  This is a truism, but it doesn't really cover any inherent benefit of SOAP (unless you class its use in legacy systems as an advantage)

 

5) The platform has to be standards based. Although one can be implemented in scala without doing a waterfall standards approach, the standards should be developed in an agile manner so that there is the possibility of more than one vendor in the space. Businesses hate being locked into only one platform without competition. 

The JVM and JSON are two of the biggest standards going.  and Scala loves 'em!

 

6) The platform has to define better separation of business logic and presentation than all prior platforms to give it a great selling point. The promise of true UI / Service separation should be finally realized. This is an odd thought perhaps but what if the platform didn't do web at all, it didn't do templates (groovy, scala or otherwise), didn't do anything except the back end SOA. If we freed the platform from all of those issues, then true separation could happen. Bear with me here: 

More Akka then :)

 

Lets say we were developing a big product with a big back end and some Administration console with a customer UI; the amazon model (aka the E-Superstore). We have a UI for customers, also for shipping and administration of products and so on. So we propose our new ScalaSOA as the main bus for this system and the business asks us how the UI will be built. We reply that it will be AJAX based, served on an Apache Web Server. The only involvement ScalaSOA would have is to serve JSON or XML documents to the front end UI. Everything else is handled with static HTML, AJAX or similar mechanisms. Our users will then have a rich front end that can be built by UI designers and graphic artists and they let the devs know what data they need. 

7) The platform would have to implement concepts of clustering, componetized deployments (think EAR files without all of the annoyances of EARs) and so on. 

Akka…

 

8) The platform would be able to reload classes at runtime enabling the developer to change apps on the fly such as is possible in play framework. 

OSGi, we already have some nice wrapper DSLs available.  Jigsaw may also help in this space once it's (finally!) released.

 

9) The platform would be componetized and designed to be extended. With the evolution of J2EE, they had to massively retool the various platforms to comply with standards. Each standard should, instead, be designed to be a component that can be mixed and matched. The vendor develops the backbone bus and can even drop in components for other vendors. Something akin to the OSGI model of providing services. Think of this in the context of an EAR deployment. If there is a standard for SSA (Scala Service Archive) of 1.0 version and it gets updated with 1.1, the old 1.0s should still work if the SOA Platform possesses the component to load the old style. The new one may have more features but the old will still work. 

Still OSGi & Akka

[Geir Hedemark]

On 2013, Feb 1, at 6:08 PM, Oliver Ruebenacker <cur...@gmail.com> wrote:
> On Fri, Feb 1, 2013 at 11:56 AM, kraythe <kra...@gmail.com> wrote:
>> Now when we get out of the realm of "I am a dev and know better"
> Would you prefer the "I am a manager and I know better" realm? ;)

I can add myself to that list if that helps. Oh, and I can also happily say "I am a dev".

--
Geir Hedemark
Development manager
Basefarm AS

[kraythe]

I disagree, there are certain problems that are not applicable to the standard Web App solution. Not everything running on JBoss is a web app. There are some large systems that have components that do things not even remotely applicable to a user interface. There are systems that work on timers, others that handle service to service efforts in a componetized manner and so on. SOA is not SOAP. The difference is that SOA means Service Oriented Architecture. This doesn't necessarily mean SOAP or IIOP. There are other ways to communicate. If you don't do SOA and put everything in one big server, you have just walked back 20 years in technology. In the current contract I am working, there are at least 50 EJBs in one platform that implement 25 or so services. This platform doesnt have a UI at all. There is no web interraction, no JSP, no templates and so on, its just services talking to services. If someone suggested we throw all that into one project, I would conclude they are nuts. 

-- Robert

To unsubscribe from this group and stop receiving emails from it, send an email to scala-user+unsubscribe@googlegroups.com.

[Oliver Ruebenacker]

Hello,

On Fri, Feb 1, 2013 at 12:18 PM, kraythe <kra...@gmail.com> wrote:
> Managers make the decisions. That is the way it is. You can either rage
> against it, or work with it. Raging against it just gets you unemployed and
> / or your scala goals unrealized.

Who's raging? Yes, I did notice that as a manager, I make decisions.
Of course, middle management listens to senior management, who listens
to the board, who listens to owners. So decision-making is really very
relative.

It is interesting that you consider "big, old company" vitriol.

> And like I said, I want to make a pure scala system to leverage the power of
> scala, running on JBoss or Tomcat, while possible of course, misses the
> point.

To me, sometimes writing imperative code in Scala or using Scala
with traditional Java technologies sounds perfectly reasonable. So I
guess I don't see the point.

Any case, businesses want solutions, not tools. What problem are you solving?

[kraythe]

Some interesting observations and on the point (rather than evangelism). I had not heard of AKKA but I am checking it out now. I appreciate that you are grounded in business practicalities. Please see my other replies inline.

On Friday, February 1, 2013 10:22:58 AM UTC-7, Kevin Wright wrote:

1) You can be a mediocre dev and handle Java (albeit not well) but you cant handle Scala unless you have a good grounding in Computer Science. Unfortunately the IT industry subsists on a large number of mediocre developers and that is just a practical reality that has to be faced. As the language matures this issue might abate due to accumulated knowledge and good API development. 

Scala allows you to do more than Java, to tackle problems you wouldn't have otherwise considered.  Many people discovered this fact and publicised their solutions.  Similarly, simple things are SO simple that it's not even worth talking about them - the potential for describing a simple "Hello, World!" in Scala is non-existent, there's no need to explain what a class is, why you use static, etc. etc.

Which means that the base of publicly visible Scala code on the net is heavily skewed towards "advanced" examples.  This is absolutely not representative of day-to-day usage of the language.

I disagree. To do Java moderately well you need a certain set of skills which is much smaller than doing Scala well. Sure anyone can write Hello world, and people can write imperatively in Scala. That misses the large advantage of Scala. 

 

2) The Scala community needs a standards approach rather than just a rapid agile environment. What I mean by this is that when you constantly break binary compatibility with previous releases, it makes it a tough sell to executives. Furthermore, if I go to sell using Java to a company, I can point out standards bodies and other respected business entities. With Scala, the sell is much tougher. 

 We have Typesafe, they're taking binary compatibility VERY seriously.  They offer support contracts.  Exactly what standards do you feel are lacking?

3) The reason for my post, is that Scala needs a viable SOA platform. 

 

No, it doesn't.  Though it would certainly benefit from *libraries* to support SOA features for some users.  But not a "platform" or "framework".  Spring went down that route, it became a monolith and cause a lot of unhappy lock-in.

As for SOA libraries, its an interesting thought. I would think there needs to be a standardized bus to manage those. Akka again?  

 

3) The platform can probably do without the features of IIOP and CORBA. Interoperability with those two old technologies can be accomplished much better through the use of SOAP and REST services. 

REST can cover everything, except for interop with legacy systems.  Any SOAP library on the JVM should be fit for purpose.

The problem i have with JSON may be one of ignorance. I wonder if there is a schema language for JSON. As a developer I dont want to be surfing maps, I want static bound objects that I can pass around to bypass the need for worrying about the underlying transport protocol. That is also a critique of REST. I know WADL is in development but it isnt widely used which leaves me messing with raw HTTP calls which is annoying. I want to call that remote object and not give a darn that its remote. The libs should take care of that for me. 

As for XML bindings for scala, the scalaxb project seems to be unfortunately dead, so I don't know how I could do those bindings without again reading and writing raw XML which is not an efficient option

 

 

4) Yes, we have to do SOAP. RESTful is great for small things but when the domain models get complicated soap is a necessity. There is little point screaming about it. Also if the platform can't talk SOAP, it can't interoperate with existing Business applications and that is a deal breaker. 

"If you can't talk SOAP then you can't interact with other SOAP apps".  This is a truism, but it doesn't really cover any inherent benefit of SOAP (unless you class its use in legacy systems as an advantage)

When we talk B2B cooperation SOAP is a reality of life. Its like trying to avoid Microsoft Office. If you are a business and deal in many domains, you have to stomach the old monstrosity. 

 

[kraythe]

I mean many people have subtle vitriol impleid by "big old companies" that is not productive. Perhaps I misinterpreted your comments as that notion. 

As for your views, you are an early adopter, that is great. The case has to be made though in those stuffy old companies. I have to be able to convince a dev manager with a massive EJB system to do something new. Thats a harder sell. I will have to look into Akka then. 

-- Robert

[Nils Kilden-Pedersen]

I've tried to follow this thread, but I still don't get why you need a _Scala_ platform, when any old JVM (Java) platform/library/framework will do. It's not like we actually want to evangelize monstrosities, is it?

 

 

--
You received this message because you are subscribed to the Google Groups "scala-user" group.

To unsubscribe from this group and stop receiving emails from it, send an email to scala-user+...@googlegroups.com.

[Clint Gilbert]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

You appear to be shifting the goalposts. In your first message, you wrote

> You can be a mediocre dev and handle Java (albeit not well) but you
> cant handle Scala unless you have a good grounding in Computer
> Science.

That's not true, as Oliver pointed out. Low-to-medium-skilled devs
can crank out Scala that looks just like the Java they used to write,
just without semicolons. (In my experience, these people take quite
easily to map()ping over collections, too.)

Now you say that's not sufficient because those devs will still be
programming imperatively. Sure, but so what? You originally implied
that mediocre devs couldn't learn or write Scala - which they can -
not that the couldn't use an idiomatic, functional style.

On 02/01/2013 12:15 PM, kraythe wrote:
>
> First of all if you take java code and translate direct to scala,
> you are missing the point completely of functional oriented
> programming. Imperative programming is a different thought model
> and easier to grasp for those on OO on traditional languages.
> Functional programming is poweful but requires a certain about of
> conceptual knowledge. So yes, Java can translate right to scala,
> but NO, it wont be as good as pure scala.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAlEMBsIACgkQ0GFaTS4nYxsCBwCeKmdhjNr5BYbyJCTDTamLNVbk
+zMAn2pT13Ra/kcLxcYWLMmSfr5Yhap8
=7HeO
-----END PGP SIGNATURE-----

[Tim Pigden]

I may be talking out of ignorance here, but is it realistic to compare Akka and SOAP? If you're building your own systems and you're building them all in the same language and have access to the relevant source code, then Akka is a great way to go. But what if I've got to talk to the servers written by the .NET team in my foreign subsidiary, or the corporate ERP system? In these cases surely Akka is not really applicable.

REST is platform independent. If we abuse the "REST" label and talk about it as a means of sending stuff around - possibly xml with proper schema identification then perhaps we have something more equivalent to SOAP - but we can easily host with Play! or one of the lightweight engines like Blue-eyes or Spray

Raw json or non-schema xml is not typesafe but xml + schemas can be pretty good in that respect. What more would the SOA require? Obviously if you keep having to talk to SOAP legacy systems you've got to use a SOAP client - but then you can use existing Java libraries and we get back to "why reinvent a legacy system in Scala?"

--
Tim Pigden
Optrak Distribution Software Limited
+44 (0)1992 517100
http://www.linkedin.com/in/timpigden
http://optrak.com
Optrak Distribution Software Ltd is a limited company registered in England and Wales.
Company Registration No. 2327613 Registered Offices: Orland House, Mead Lane, Hertford, SG13 7AT England 
This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Optrak Distribution Software Ltd. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error.

[kraythe]

Platform is perhaps a bad choice of words on my part. An interesting point was made earlier about the advantages of libraries over platforms. However, deploying scala on Tomcat or JBoss strikes me as using a lawn mower engine to run a Ferrari. Sure, it can be done but its far from optimal. A pure scala platform will have advantages over the large legacy monstrosities that are today's J2EE web servers.

Asfor myself i plan to look into Akka today. If I can use it for a clustered SOA then that will address many of my concerns. Now if I could find the JSON equivalent of XSD and the ability to do data bindings back and forth then I would be delighted.

-- Robert

[kraythe]

I am not totally up to speed on Akka as well. However, from what i gather its a deployment platform like JBoss rather than a spec like SOAP.

I agree that JSON has the problem of tight type binding but there is the age old question of whether that type binding actually got us anywhere iwth XSD. An XSD is amazingly complicated and difficult to grasp in many ways. Superficially it is massively verbose. With JSON there is the limitation of not having any type of Schema though. Thats not such a problem for simple things but when passing back complex objects, you need ot have a way to get them into static type classes that bind well to the JSON and there is where JSON needs work IMHO. So XSD is big and bulky and JSON needs a schema and serialization tools to generate from the schema.

As for SOAP interoperability, I entirely agree. In any business of sufficient size you will talk to other businesses and SOAP is the language of choice for that. Trying to avoid it is like trying to avoid taxes. You can get away with it for a while but it will eventually catch up with you.

-- Robert

[Nils Kilden-Pedersen]

On Fri, Feb 1, 2013 at 12:30 PM, kraythe <kra...@gmail.com> wrote:

Platform is perhaps a bad choice of words on my part. An interesting point was made earlier about the advantages of libraries over platforms. However, deploying scala on Tomcat or JBoss strikes me as using a lawn mower engine to run a Ferrari. Sure, it can be done but its far from optimal. A pure scala platform will have advantages over the large legacy monstrosities that are today's J2EE web servers.

Personally, I use Jetty, which I don't consider a J2EE monstrosity (which of course depends on one's definition of both J2EE and monstrosity) with Scalatra veneer, but there are plenty of "pure" Scala alternatives (if "pure" means written in Scala), such as Play!, Spray, Unfiltered, and more if I'm not mistaken.

It's no wonder you have a hard time convincing managers if you're trying to introduce a replacement of the entire stack at once. Starting with the language while keeping the existing infrastructure is a good first step, IMO.
 

[Oliver Ruebenacker]

Hello,

On Fri, Feb 1, 2013 at 3:43 PM, Nils Kilden-Pedersen <nil...@gmail.com> wrote:
> On Fri, Feb 1, 2013 at 12:30 PM, kraythe <kra...@gmail.com> wrote:
>>
>> Platform is perhaps a bad choice of words on my part. An interesting point
>> was made earlier about the advantages of libraries over platforms. However,
>> deploying scala on Tomcat or JBoss strikes me as using a lawn mower engine
>> to run a Ferrari. Sure, it can be done but its far from optimal. A pure
>> scala platform will have advantages over the large legacy monstrosities that
>> are today's J2EE web servers.
>
>
> Personally, I use Jetty, which I don't consider a J2EE monstrosity (which of
> course depends on one's definition of both J2EE and monstrosity) with
> Scalatra veneer, but there are plenty of "pure" Scala alternatives (if
> "pure" means written in Scala), such as Play!, Spray, Unfiltered, and more
> if I'm not mistaken.
>
> It's no wonder you have a hard time convincing managers if you're trying to
> introduce a replacement of the entire stack at once. Starting with the
> language while keeping the existing infrastructure is a good first step,
> IMO.

What does "pure Scala" even mean - any one not using java.lang.String?

Play is using JBoss Netty, which is, like Tomcat and Jetty, a server
based on J2EE's Java Servlet API (BTW, all these servers are written
in Java). But is there anything wrong with Java Servlets? Any
alternative?

[pagoda_5b]

Hi Robert,

first thing that comes to my mind reading this thread, is that it was better suited for scala-debate.

But let's get on.

I might be mistaken but I suspect that there are basically two different perpectives adopted by people discussing here, and that's because the object of the discussion is not clearly defined.

What is the goal of your proposed platform? Are you looking for a viable solution to replace the whole existing Java enterprise stack in the "old big-size companies" business?

That is: what customers are we talking about here? Banks, Public Administration, International Manufacturers, Telecoms...

I mean, to me this is a specific target in the business, and it's not the whole picture at all.

Scala is gaining traction on a totally different market share, in my opinion, and that's mainly in internet-based services that need high throughput of data, real-time response, big-data analysis and storage, to say a few (I'm thinking Twitter and the like, but it doesn't ends there).

The requirements and goals of this kind of business are not the same as those "old companies" we were addressing before. There's a whole world of internet start-ups making good use of lightweight solutions, that have no need for a platform, as I see it, but still know how to make money for their business, if you get my meaning.

So let's focus on the big-olds corps.

Your platform sounds to me like a re-engineering of the java SOA, based on scala.

But where's the gain for this kind of customers from such a solution, when java does the job already and it's fairly accessible from scala?

I would argue that in this scenario, you best integrate new scala solutions with the existing platform, without any need for an entire rewrite.

It's the path of least resistance, as I see it, and it could also ease the developers' journey to the new language.

In fact one of the main strength of scala is that it can leverage both the existing java ecosystem and the imperative style of programming, creating the possibility, and thus the opportunity, of a gentler slope to adoption.

What's the point of creating a huge (for huge it need be) substitute to replace an already running solution in its entirety? Service-based is already the keyword here, you don't need to rewrite the platform, but just to adapt your scala services to the existing communication protocol and bus.

If the need for pure functional solutions was so evident in the industry, then everyone would already be using haskell or lisp today...

And anyway how does this vision cope with the issue of mediocre programmers?

Should this platform be a complex system underneath (complex not meant to be bad here) hidden behind a interface "familiar" to java programmers?

I say familiar, because I don't think that "easy" or "simple" is the correct word here. Even scala is easy when you're familiar with it...

To me it seems that most of the usefulness of the functional approach would be lost to the end user of the platform.

Talking about schema-less protocols: you suggest, if I understand, that there's a need for a standard and well-encoded way of converting back and forth between json/soap and static typed classes. I would argue that an emergent trend in the functional side of (business) programming is on focusing more on data-structures and less on javabean-like conversion. Sometimes there's nothing to be gained from using a full-blown object instead of raw data collected in a standard structure (maps, lists, trees...).

Talking from experience, I see that the value of bidirectional object binding (from database, json, xml...) is often overweighted by the associated and unavoidable "ceremony", especially when there are many communicating systems, and the type of data exchanged evolves frequently.

That said, I don't think that your idea is inherently bad or useless. Certainly it could be useful to have a "light-weight", functional, service-oriented backend solution. It could be done pretty well starting from Akka and a few other projects.

But for me the main issues are:

- the cost of building such a platform

- the need to propose it as some sort of scala "standard", since in my opinion there's quite a number of people that won't have any need for that, other than to sooth the worries of "high-level management"

- the effort to define a more structured protocol that clients would need to implement to integrate with the platform (along the tracks of what soap was meant to be, but less cumbersome, in the fashion of json)

If you think that such a product would be adopted in the share of industry that you were referring to, I encourage you and anyone who cares to go for it.

If it's good, I'll probably try to make my company use it.

But I see it just as a possible alternative for one aspect of the modern IT business (mainly backward compatibility), and not as the standard accepted solution for back-end systems. Just because I dont' believe in the need for another "Spring-like" lock-in.

I see a solution to a specific problem, just like many frameworks have done: Lift, Spray, Play!, Scalatra, and so on...

As a final note, you made some critique to Play! and Lift, but more as some guts-feeling on your part than as a documented analysis.

Could you please elaborate some more on the reasons of your evaluations?

Sorry for being so verbose,

bye

Ivano

[Alec Zorab]

In defence of banks (oh god, I didn't think I'd ever write that...)

I know of several banks and at least one hedge fund that use scala, so I'd actually lump them more into the high throughput cool kids than the big old dinosaur group.

Government, telecoms etc. definitely tend to be inclined to lock themselves into enormous platforms though.

As far as the need for an underlying platform goes, I've yet to see a problem that the Akka guys haven't already either addressed or are in the process of doing so.

[Yagiz Erkan]

Hi all,

This has been an interesting debate. On certain areas I'm having a hard time to follow Robert (partly due to one of my pet peeves: "using J2EE instead of Java EE"). He touches on a few points that have been in my mind nonetheless.

I think a majority of the Scala code that we see floating around break one of the most important principles that I believe in:

"Code must be written for people to read".

It feels like being able to demonstrate that "this piece of code would have taken twice or thrice more lines in Java" has become one of the biggest goals or one of the biggest selling point of using Scala. And this, IMHO, at the peril of alienating the language completely from the ones who are not familiar with it (other developers, technical and non-technical management, etc). The problem is not so much that the average developer won't be able to write Scala but that she won't be able to *read it* in the first place. Part of it is our intellectual self-indulgence. Another part is Scala's less-rigid syntax in certain areas. But we just have to keep in mind that we're not trying to write the shortest quine every time we write a piece of code.

 -- Yagiz --

[Kevin Wright]

It's interesting that you should say that.  I see the exact same things that you appear to be seeing, yet I find myself coming to drastically different conclusions… Such is the subjective nature of personal opinion.

I agree, 100%, that code must be readable.  After all, people are going to spend far more time and effort reading it than computers ever will.

However, familiarity and readability are not the same thing at all.  For example, the syntax for Scala's case classes will be initially unfamiliar to a Java developer, but that doesn't mean it'll be less readable *once they have learned the syntax*

It's a classic case of those demonstrations where (compared to Java) Scala can be written with fewer lines of boilerplate.  The lack of explicit properties may initially confuse a newcomer, but there's far less ceremony and potential for error around the way the underlying concept is expressed.  It makes little difference to the compiler, but other programmers will certainly have less pain understanding the intent of your code.

I have yet to find anyone with more than 2 days exposure who genuinely believes that the Java equivalents are 

more readable than case classes, or mapping over a collection, or using Futures in a for-comprehension.

Reducing lines of code, when not taken to an extreme, is a Good Thing™. It's the very basis of "elegance", perhaps the most praiseworthy quality that any engineer can use to describe an others work.

Kevin Wright
mail: kevin....@scalatechnology.com
gtalk / msn : kev.lee...@gmail.com

quora: http://www.quora.com/Kevin-Wright

google+: http://gplus.to/thecoda

twitter: @thecoda

vibe / skype: kev.lee.wright

steam: kev_lee_wright

"My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger" ~ Dijkstra

[Yagiz Erkan]

Kevin,

IMHO the path to language popularity is built on intuitiveness and simplicity. I agree that familiarity is a major factor so is the paradigm shift but I still believe that it is going to be hard to convince the so-called "average :)" developer.

 -- Yagiz --

[Tim Pigden]

imho the problem is too much stuff on one line

an intermediate and well named val can make things a lot clearer with no significant loss of efficiency.

If I find myself putting more than 3 functions with complex args on one line I will split it up and take a temporary val. Coming back to it, it's so much easier to read quickly.

Tim

--
You received this message because you are subscribed to the Google Groups "scala-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-user+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Stephen Boesch]

The original posting here is useful to address:  encouraging consideration of the present limitations of scala in terms of its attractiveness to large corporate/government environments.  I agree with postings along the lines of " this is not the industry / segment best addressed by scala".  Also "scala best addresses faster moving internet driven businesses that require high throughput, scalability and programmer productivity."  

But even so, it is useful to consider "moving the needle" as far as scala usability  for "in-the-middle" type of environments.   There are not just two camps:  cutting edge internet startups and old-school insurance/government/other conservative institutions.    For projects that fall in -between could derive the most benefit from the types of items mentioned.

Typesafe has been taking a lead on  providing key work along the lines of making scala adoptable by corporations.  Yet they and other scala OSS developers  are mostly over-subscribed and would unlikely be able to drive additional items suggested by the OP.  So it may be a matter of "who will build this" . When /if that happens will not be much question that will provide more options and strength for proposing introduction of scala to these "in-between" shops.

2013/2/2 Tim Pigden <tim.p...@optrak.com>

[Kevin Wright]

That's the fault of programmers, not the specific language they use.  I've seen single line monstrosities in Java as well!  It's generally accepted good engineering practice to factor out behaviour like this, either into intermediate values or into separate methods.

If anything, I would argue that Scala helps encourage this even more by having functions as a first-class citizen and by not requiring the return keyword or curly braces around every single method definition.  It's far less painful to break functionality into smaller parts if you know it's going to be easier to then compose those parts.  For-comprehensions are a great case-in-point here.

My gut feeling is that lambdas in java will only make this more obvious.  In the examples I've already seen, the use of "return" already looks far too cumbersome and boilerplatey - it's guaranteed to make lines longer. 

[Kevin Wright]

Coming back to the OP :)

Akka is perhaps *the* framework on Scala.  Although typically seen as an actor library, it's so much more.  Akka is a fully-fledged concurrency framework, dealing with Actors, remote actors, supervisor hierarchies, asynchronous processing, clustering, etc. As well a the tools to integrate, test, and monitor all these features.

More recently, large parts of Akka have been integrated into the Scala standard library (version 2.10), and the rest is available through the type safe stack.

For plugins (or dynamically updated components) you could use a library such as scala-osgi (https://github.com/kiip/scala-osgi).  OSGi is already a well established and robust standard on the JVM, with several implementations available.  A more contemporary approach is to distribute functionality over several virtual or cloud-based machines and have them interact via restful interfaces or Akka remote actors.  Scala has no shortage of solutions for exposing a REST interface!

SOAP is, frankly, bloated.  It's mostly of interest for interfacing with legacy systems or .NET, and even .NET seems to be moving towards REST nowadays.  If you want SOAP then there are already several solutions available on the JVM, and Scala can talk to them quite happily, albeit with a Java-esque level of boilerplate.  A nice DSL would certainly help here if the demand was high enough, it's the sort of thing that I could imagine someone offering as a commercial product.

They key message here is that Scala is, first and foremost, a JVM language that put a premium on strong interop with Java.  Anything that can already be done with a Java library/framework can be done with Scala, the cost of that interop depends on the idioms adopted by the library and whether or not a Scala wrapper already exists.

As for the language itself (as opposed to the platform), that's already being covered elsewhere in this thread :)

--

You received this message because you are subscribed to the Google Groups "scala-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-user+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Jun Yamog]

I don't think its the language that matters.  Its just common sense and who is doing the code.  Nothing to do with Java or Scala.

For scala we have a few things we follow as guidelines (not rules).  Some of them are:
- Its not a competition for the shortest code, if there is one then its the best readable code.
- each line must be one intent, if there is more then break it down to more lines.

In fact on Java the opposite is true.  Some devs tend to make the code bigger than it is.  Example some Java code tend to just make methods that returns nothing (void) and just mutates the parameters send in.  This is no better than having the code in 1 big method.  Refactoring it to methods that return things made the code significantly smaller and each part isolated from one another.

What I like about scala is the ability to start somewhere small and go full on.  You can use existing Java library, frameworks, idioms, tools.  You can even start putting scala in an existing java code base.  Then on greenfields part you can use FP, play + akka.  The range of scala usage is bigger, which is a plus and minus as the style varies from one case to the other.

I guess some common sense will go long way.

[Ken Scambler]

"Too much stuff on one line" is *not* idiomatic Scala. 

I have to try so hard to write Java that is readable, so hard.  It is really not straightforward.

It really bothers me then when people who have the ample blessings of Scala syntax *still* write unreadable code. Such a wasted opportunity!

[Geir Hedemark]

On 2013, Feb 2, at 10:04 PM, Kevin Wright <kev.lee...@gmail.com> wrote:
> That's the fault of programmers, not the specific language they use. I've seen single line monstrosities in Java as well! It's generally accepted good engineering practice to factor out behaviour like this, either into intermediate values or into separate methods.

It is, but the scala ecosystem is also partly to blame for this. We - as a group - still have a nerdy "ooo-shiny" reaction to language constructs, and the more complex the construct, the bigger the reaction is. I guess this is not that strange after having waited for java to develop for so many years.

I work with some really talented programmers, and I know a guy who is perhaps the best scala programmer in Norway. They have all lost their way in oo-shinyness at some point or other. Which feature is the culprit changes, so this probably is not caused by the language.

The big idea is to write readable, maintainable code that is as lucid as possible. If we have to resort to higher-order kinds or macro skullduggery to do it, ok, but for the most part, these features are simply not needed. There is still a need to learn how these things work so they can be used where needed - and keeping the mistakes done while learning out of the production code.

As a manager of a team of scala developers I have frequently thought about creating some kind of lab project(s) that is not part of our production code repository where we can try out new stuff like macros. I still haven´t found the time to get it started, but sometimes, I really see the need to do something like this.

YMMV

Geir

[Robert Wills]

On Sat, Feb 2, 2013 at 5:07 PM, Yagiz Erkan <yagiz...@gmail.com> wrote:

IMHO the path to language popularity is built on intuitiveness and simplicity. I agree that familiarity is a major factor so is the paradigm shift but I still believe that it is going to be hard to convince the so-called "average :)" developer.

 

Intuitiveness and simplicity are often conflicting goals.  See Rich Hickey's talk on Simple vs Easy.  A concept will often 

appear intuitive only because it has some sort of  metaphorical connection to an everyday but fuzzy idea.  I think it's much

more important for a concept to be simple than it is for it to be intuitive.

 

[Yagiz Erkan]

On Sun, Feb 3, 2013 at 10:01 AM, Robert Wills <wrw...@gmail.com> wrote:

Intuitiveness and simplicity are often conflicting goals.  See Rich Hickey's talk on Simple vs Easy.  A concept will often 

appear intuitive only because it has some sort of  metaphorical connection to an everyday but fuzzy idea.  I think it's much

more important for a concept to be simple than it is for it to be intuitive.

So you really believe that things can't be made intuitive and simple, and that those two things are incompatible?

I don't care how complex and/or sophisticated a piece of technology/machinery/tool is as long as I'm presented with an intuitive and simple interface. I need to be able to figure some things out by intuition and I need to be able to remember the things I learned easily. If things don't make sense, one just has to learn them by heart. If the number of those things increase then the barrier of entry gets higher. 

There's nothing intuitive about "::" or ":::" or #::". You can't just look at them and guess their purpose or even where they differ. You have to learn them by heart and remember them. But we're all smart people here, we know we can do that, don't we? However, looking at ":::" or "concatenate()", one can get a fair idea what the second one does even if you are not a developer.

I'm just being the devil's advocate here. But, in my opinion, Scala's barrier of entry is higher because of those immediate symbolism or rules. 

And, on a more generic note, it doesn't have to have all the possible features in the world. Hasn't it had a roadmap that looks a little kitchen-sink-esque? Does nobody think that it's a dangerous tendency?

 -- Yagiz --

 

[Simon Ochsenreither]

There's nothing intuitive about "::" or ":::" or #::".

I guess every developer coming from a functional language would disagree.

And, on a more generic note, it doesn't have to have all the possible features in the world. Hasn't it had a roadmap that looks a little kitchen-sink-esque?

No.

 

Does nobody think that it's a dangerous tendency?

Yes, that's why the opposite happens and people push hard for it. See all the cleanup in the language and the standard library over the last few releases.

[Yagiz Erkan]

My point was off-topic so I don't want to stretch an unnecessary side conversation.

I guess time will tell how much Scala will be popular. 

FP is powerful and has certainly brighter days in the horizon but IMHO Scala is not *the* language to make the masses FP-infected.

Until then, business as usual.

 -- Yagiz --

On Sun, Feb 3, 2013 at 1:42 PM, Kevin Wright <kev.lee...@gmail.com> wrote:

I'm with Rob (and Rich) here, intuitiveness and simplicity are orthogonal concepts.

They can often occur together, they can sometimes be wildly different.  Just consider something like general relativity which is fairly simple in execution and has the advantage of matching real world observations, but is not at all intuitive unless you're well versed in physics.

Simplicity always wins - so long as it's actually correct :)

--

[Kevin Wright]

Back in the day, people said that C++ (a hybrid) was not *the* language to bring OO to the masses.  It was seen as too complicated, inaccessible to mediocre programmers, polluting the OO ideal with its procedural C heritage.  Great hope was still being held out for smalltalk.

C++ *did* succeed, and wildly!  The C++ model went on to spawn Java and C#, which also became wildly successful.

Java then spawned Scala (another hybrid) & others.  Many say that Scala is not the language to bring FP to the masses, just as C++ was not the language to bring them OO.  It's too complicated, not accessible to mediocre programmers, and its Java heritage pollutes the pure FP ideal.

Time *can* still be cyclic, even if the world *didn't* end with the mayan calendar...

[Yagiz Erkan]

The great thing about this type of argument is that it can apply to any language. Just replace Scala with Kotlin or Ceylon and it still reads smart but it does not make it right.

 -- Yagiz --

[Geir Hedemark]

On 2013, Feb 3, at 12:16 PM, Yagiz Erkan <yagiz...@gmail.com> wrote:
> There's nothing intuitive about "::" or ":::" or #::". You can't just look at them and guess their purpose or even where they differ. You have to learn them by heart and remember them. But we're all smart people here, we know we can do that, don't we? However, looking at ":::" or "concatenate()", one can get a fair idea what the second one does even if you are not a developer.

+1 for this.

Symbolic operators are extremely powerful, but only if I actually use the API often enough that I am willing to invest the effort to become fluent in the new "language". For common math operators, this is the case, and the same applies to sending messages through Akka.

There is something really, really wrong with the world if I have to spend enough time in SBT to learn what the various brackets do without thinking.

We learnt this 25 years ago in Modula-2 and Ada. We seem to have lost something along the way.

Geir

[Michael Ekstrand]

On 02/01/2013 11:10 AM, Simon Ochsenreither wrote:
> 1) You can be a mediocre dev and handle Java (albeit not well) but
> you cant handle Scala unless you have a good grounding in Computer
> Science.
>

> I would completely disagree with that. I'd say that generally,
> everything you can do in Java is easier in Scala. I think it is
> important to not confuse familiar with difficult.

For a nontrivial number of developers, unfamiliar is (perceived to be)
difficult. Even if it is not actually difficult in some objective sense,
for someone used to doing the familiar repeatedly just doing something
unfamiliar can be difficult, and perception is often reality (even more
so when the perception is about difficulty).

- Michael

[Robert Wills]

I was talking about concepts rather than language syntax. In that realm, I do believe that intuitiveness and 

simplicity are usually incompatible.  

Rich Hickey has a bunch of nice contrasts (interestingly putting actors on the side of "complex" at one point).

One of my favourite examples is objects (we have an intuition what they are, but that intuition is quite complex) vs 

monads (a very simple concept).

With regard to syntax, it's more of a question of taste than simplicity vs complexity.  I agree with what Kevin said a

couple of posts back that reducing lines of code and line length can help make code reading easier -- up to a point of 

course.  Symbolic operators sometimes make it easier to see the shape of the code.

--

[Jan Vanek]

Thanks Mayan gods its more of an upwards spiral in this particular case...

I like your analogy C -> C++, Java -> Scala, there is true in it, I asked myself whether type macros will be as pervasive as C++ templates, once you start, your whole application tends to become template based. I have no insight in it.

My perspective with regard to Erkan's comments was this. The simplicity of Java was one of the factors that gave rise (made possible) to multiple of complex pieces of software, which were previously unmanageable in C++. But when these structures emerged it became apparent that some patterns repeat and are written over and over because you do not have enough expressive power to do otherwise. So the complexity (of the structures) is already there, and I mean the intrinsic complexity, and it is made worse by the inexpressive language, which (if I am not very wrong) gave rise to it. So by speaking about making it simple we actually speak about reducing the complexity close to the intrinsic level. And this is where Scala helps. You can argue it is not simple, it can be debated, but I argue that it helps to make complex systems simpler, and perhaps giving rise to (make manageable) even complexer systems, same as Java did. As you say, time will tell.

Regards,
Jan

[Rex Kerr]

On Sun, Feb 3, 2013 at 10:32 AM, Jan Vanek <j3v...@gmail.com> wrote:

My perspective with regard to Erkan's comments was this. The simplicity of Java was one of the factors that gave rise (made possible) to multiple of complex pieces of software, which were previously unmanageable in C++.

Wait, what?  There are multi-million-LOC C++ projects _all over the place_ that nonetheless still get managed quite handily.  For example, Google Chrome is written in C++ (and C) and Google doesn't seem to have a great deal of trouble managing it.  Firefox?  Ogre3D?  OpenOffice?

Let's not sell C++ too short here.

  --Rex

[Simon Ochsenreither]

For a nontrivial number of developers, unfamiliar is (perceived to be)
difficult. Even if it is not actually difficult in some objective sense,
for someone used to doing the familiar repeatedly just doing something
unfamiliar can be difficult, and perception is often reality (even more
so when the perception is about difficulty).

Well, in one way or another we want to speak with at least a small amount of objectivity thrown in.
That's why I try to distinguish between familiarity and simplicity in the first place.

Otherwise, the only worthwhile recommendation would be to learn only a single language and never even look at anything else.

Regardless of that, I don't care much about that particular group of developers. Most people coming from Ruby, Python, C#, Haskell, C, C++, OCaml, F#, JavaScript and a lot of other languages seem to pick up Scala perfectly fine although the whole OO part might not be “familiar” to C or Haskell developers, or the FP part to C++ or Python developers.

If only these “senior Java experts” claim that X is hard for mediocre Java developers, it is maybe more of a structural issue of their ecosystem/community. It's amusing how at the same time every Java developer seems to consider himself to be a Java expert and pretty much no one identifies himself as a mediocre Java developer.

[Jan Vanek]

I'm sure you also thought about the Hotspot JVM itself; although I don't know how many LOCs it has.

 

Let's not sell C++ too short here.

Apologies, my words were not correct, please replace "unmanageable" with "not readily manageable". I acknowledge and agree C++ was/is wildly successful as Kevin said already. What I tried to express is my understanding of why Java became successful and especially why I believe Scala is becoming successful. Do you disagree with this hypothesis, and what is your view?

Also, by speaking about a spiral I indicated I see Scala above C++. I should have spare it. Let's stay with circle.

  --Rex

Regards,

Jan

[Geoffrey S. Knauth]

I used Scala in a Java shop.  It freaked out the Java developers when my 3-line methods frequently reduced to one functional line.  I sometimes had to expand that one line back to 3 or 10 so they could see the 10 lines it would take to do the same thing in Java.  Sometimes they would ask me, "How do you debug that?", and I had to expand my one line to three lines of Scala to show intermediate values.  After they were satisfied all was well, I'd reduce the 3 Scala lines back to 1.  Since then I've thought of Java as a kind of assembly language compared with Java.  You want to see registers?  I'll show you registers.  What I wanted myself was an IDE trick that would automatically do the 1-to-3 expansion or 3-to-1 collapse automatically, not because it was a burden to me, but because it would make the Java developer's demand easier to fulfill in an instant:  "I want to see the inner workings of that functional magic you just did."

Geoff

[Rex Kerr]

On Sun, Feb 3, 2013 at 1:19 PM, Jan Vanek <j3v...@gmail.com> wrote:

 

 

Apologies, my words were not correct, please replace "unmanageable" with "not readily manageable". I acknowledge and agree C++ was/is wildly successful as Kevin said already. What I tried to express is my understanding of why Java became successful and especially why I believe Scala is becoming successful. Do you disagree with this hypothesis, and what is your view?

I don't think Java is _any_ more manageable than C++ for large projects.  But it _is_ much more robust against sloppy coding, mostly because you can't point pointers at any random thing and destroy it, but also because it handles the most error-prone part of pointer manipulation, memory management, for you.  And it's cross-platform by default, whereas C++ is only if you are exquisitely careful not to use the most central data types (like int).

My sense--though I can't say that I was in a position to know at the time--is that it was the robustness, portability, and shallowness (of the language itself, if not APIs) that made Java successful.  You don't need to know very much about Java before you can be moderately productive in it, and anyone who doesn't trust you can safeguard themselves against any foolishness you commit.  In C++ it is more common to not be able to even get off the ground until you understand the details of a giant templated mess that does wonders once you understand it.  So with Java you can switch hardware and your development team and you're still good to go.  With C++, not so much.

Scala retains all of Java's robustness and portability, but adds back the capability to do wonders at the price of losing some shallowness; Scala is deep, even if it's not complex in some sense, because the consequences of the rules it has are more profound than of Java's.

  --Rex

[Geoffrey S. Knauth]

I meant: Since then I've thought of Java as a kind of assembly language compared with Scala.

Geoff

[Yagiz Erkan]

> It's amusing how at the same time every Java developer seems to consider himself to be a Java expert and pretty much no one identifies himself as a mediocre Java developer.

Because as opposed to average Scala developers, average Java developers cannot remember their passwords. ;)

 -- Yagiz --

--

[Stephen Boesch]

ouch . I  can't remember my password (again).    guess I better hang it up on scala

2013/2/3 Yagiz Erkan <yagiz...@gmail.com>

[Michael Ekstrand]

On 02/03/2013 11:45 AM, Simon Ochsenreither wrote:
>
> For a nontrivial number of developers, unfamiliar is (perceived to be)
> difficult. Even if it is not actually difficult in some objective
> sense,
> for someone used to doing the familiar repeatedly just doing something
> unfamiliar can be difficult, and perception is often reality (even more
> so when the perception is about difficulty).
>
> Well, in one way or another we want to speak with at least a small
> amount of objectivity thrown in.
> That's why I try to distinguish between familiarity and simplicity in
> the first place.
>
> Otherwise, the only worthwhile recommendation would be to learn only a
> single language and never even look at anything else.
>
> Regardless of that, I don't care much about that particular group of
> developers. Most people coming from Ruby, Python, C#, Haskell, C, C++,
> OCaml, F#, JavaScript and a lot of other languages seem to pick up Scala

> perfectly fine although the whole OO part might not be �familiar� to C

> or Haskell developers, or the FP part to C++ or Python developers.

Have you read Paul Graham's essay from a few years back about Python
expertise being a signal for "good developer", even if you don't need
them t code Python? Basic idea, people who (at that time) learned Python
tended to be the kind of developer who didn't have a problem with a
cluster of development skills including learning new languages.

Even more so for Haskell, OCaml, and F# developers. And I would expect
people who want to pick up Scala to be far less likely to have a problem
picking up Scala. The segment Robert is talking about seem to largely
be ones who have no inclination to voluntarily pick up something like
Scala; in his experience (which is consistent with what I have seen from
the outside), the enterprise development environments that he is
interested in introducing Scala to have many of these developers.

I have seen people terrified by the COBOL -> Java transition. Java ->
Scala seems likely to be at least as intimidating, if not more.

You may not care about this group of developers, but Robert does and
seems interested in building a bridge between them and Scala. It seems
to me to be much more productive to help build that bridge, or ignore
it, than to dismiss such efforts and reject his concerns.

> If only these �senior Java experts� claim that X is hard for mediocre

> Java developers, it is maybe more of a structural issue of their
> ecosystem/community. It's amusing how at the same time every Java
> developer seems to consider himself to be a Java expert and pretty much
> no one identifies himself as a mediocre Java developer.

Sure there are structural problems. As in any community. But if we
look at Robert's concerns as attempting to introduce heavy enterprise
development to the benefits of Scala without first constructing a magic
wand to fix all perceived structural and developer quality problems,
there might be things (in language/library design, training, messaging,
etc.) that can be done to mitigate some of the problems (perceived or real).

I find Robert's concerns to be credible, even if I don't have any
particularly good ideas as to how to address them.

Best,
- Michael

[Oliver Ruebenacker]

Hello,

On Sun, Feb 3, 2013 at 5:01 AM, Robert Wills <wrw...@gmail.com> wrote:
> Intuitiveness and simplicity are often conflicting goals.

My favorite example of simplicity versus intuitive:

You have a map and a key. If there is a value in the map for that
key, do something with it. Otherwise, do nothing. Here is a popular
simple Scala solution:

for(value <- map.get(key) { value.doSomething() }

Since the ancient days of Basic, for is a loop, and loops are to
repeat things. At least under some circumstances. Above for loop, on
the other hand, only knows zero or one iterations, using the brilliant
Scala feature that Options are collections of zero or one element. So
this is really a conditional masquerading as a loop.

To be more intuitive, I usually prefer to write:

map.get(key) match {
case Some(value) => value.doSomething()
case None => Unit
}

More bulky, but in my mind more clear in describing what is being done.

That Options are collections comes in very handy with flatMap.

Take care
Oliver

--
IT Project Lead at PanGenX (http://www.pangenx.com)
The purpose is always improvement

[Rex Kerr]

On Sun, Feb 3, 2013 at 3:51 PM, Oliver Ruebenacker <cur...@gmail.com> wrote:

     Hello,

On Sun, Feb 3, 2013 at 5:01 AM, Robert Wills <wrw...@gmail.com> wrote:
> Intuitiveness and simplicity are often conflicting goals.

  My favorite example of simplicity versus intuitive:

  You have a map and a key. If there is a value in the map for that
key, do something with it. Otherwise, do nothing. Here is a popular
simple Scala solution:

for(value <- map.get(key) { value.doSomething() }

Wouldn't the idiomatic version be more like

map.get(key).foreach(_.doSomething)

(use point-free style if you prefer)?  Isn't this both intuitive and simple (once you understand what foreach does, which is probably not more difficult than understanding what Some and None are in a match)?

  --Rex

 

[Kevin Wright]

Or even

map get key foreach {_.doSomething} 

Though I don't like calling *anything* idiomatic when it so clearly relies on side-effect.

 

[Nils Kilden-Pedersen]

All this bypasses Oliver's real point, which was that "for" and "foreach" are poor names for conditionally doing something on Option content.

 

[Gilberto Garcia]

I think there is a misconception of what an Option and for comprehension are. Option is not a collection of zero or one element. Option does not hold a Some or a None inside of it. An Option can be a Some or a None. None is an object that extends Option and Some is a case class that extends Option.

The reason we can use for/foreach/map on a Option is that it supports filter, map, and flatMap operations. (I'm not sure, but I think this is what it takes to be a Monad)

And everything that supports these operations can be used in a for comprehension.




"Comprehensions have the form for (enums) yield e, where enums refers to a semicolon-separated list of enumerators. An enumerator is either a generator which introduces new variables, or it is a filter. A comprehension evaluates the body e for each binding generated by the enumerators enum and returns a sequence of these values."

So, in the case of Some(...) the for comprehension will generate a bind and it will not in case of None. This seems to be that we are conditionally doing something. 

The way I see, for and foreach are not poor names for condionally doing something. If one thinks that for and foreach "are just replacements for an if statement" then, I think, there is a problem of understanding what a for comprehension is.

By the way, the 'for' we are talking about here is not a 'for loop' in the classic sense of the word. for in Scala is a sequence comprehension. See here -> http://www.scala-lang.org/node/111

Once I stopped seeing "for as a loop", things started to be clear and brighter :)

[Jan Vanek]

I've sent that to Nils only, reposting.

On Mon, Feb 4, 2013 at 3:14 PM, Nils Kilden-Pedersen <nil...@gmail.com> wrote:

On Mon, Feb 4, 2013 at 2:34 AM, Kevin Wright <kev.lee...@gmail.com> wrote:

On 3 February 2013 21:59, Rex Kerr <ich...@gmail.com> wrote:

On Sun, Feb 3, 2013 at 3:51 PM, Oliver Ruebenacker <cur...@gmail.com> wrote:

     Hello,

On Sun, Feb 3, 2013 at 5:01 AM, Robert Wills <wrw...@gmail.com> wrote:
> Intuitiveness and simplicity are often conflicting goals.

  My favorite example of simplicity versus intuitive:

  You have a map and a key. If there is a value in the map for that
key, do something with it. Otherwise, do nothing. Here is a popular
simple Scala solution:

for(value <- map.get(key) { value.doSomething() }

Wouldn't the idiomatic version be more like

map.get(key).foreach(_.doSomething)

(use point-free style if you prefer)?  Isn't this both intuitive and simple (once you understand what foreach does, which is probably not more difficult than understanding what Some and None are in a match)?

Or even

map get key foreach {_.doSomething} 

Though I don't like calling *anything* idiomatic when it so clearly relies on side-effect.

All this bypasses Oliver's real point, which was that "for" and "foreach" are poor names for conditionally doing something on Option content.

Only if you read that code as a programmer, which, unfortunately, mostly only programmers do :-). Read as english sentence, it looks nice. Is it a conditional masquerading as a loop, or a loop masquerading under the ancient word "for"? But I too still have to make this mental jump, if not loop.

[Kevin Wright]

On 4 February 2013 15:38, Jan Vanek <j3v...@gmail.com> wrote:

I've sent that to Nils only, reposting.

On Mon, Feb 4, 2013 at 3:14 PM, Nils Kilden-Pedersen <nil...@gmail.com> wrote:

On Mon, Feb 4, 2013 at 2:34 AM, Kevin Wright <kev.lee...@gmail.com> wrote:

On 3 February 2013 21:59, Rex Kerr <ich...@gmail.com> wrote:

On Sun, Feb 3, 2013 at 3:51 PM, Oliver Ruebenacker <cur...@gmail.com> wrote:

     Hello,

On Sun, Feb 3, 2013 at 5:01 AM, Robert Wills <wrw...@gmail.com> wrote:
> Intuitiveness and simplicity are often conflicting goals.

  My favorite example of simplicity versus intuitive:

  You have a map and a key. If there is a value in the map for that
key, do something with it. Otherwise, do nothing. Here is a popular
simple Scala solution:

for(value <- map.get(key) { value.doSomething() }

Wouldn't the idiomatic version be more like

map.get(key).foreach(_.doSomething)

(use point-free style if you prefer)?  Isn't this both intuitive and simple (once you understand what foreach does, which is probably not more difficult than understanding what Some and None are in a match)?

Or even

map get key foreach {_.doSomething} 

Though I don't like calling *anything* idiomatic when it so clearly relies on side-effect.

All this bypasses Oliver's real point, which was that "for" and "foreach" are poor names for conditionally doing something on Option content.

Only if you read that code as a programmer, which, unfortunately, mostly only programmers do :-). Read as english sentence, it looks nice. Is it a conditional masquerading as a loop, or a loop masquerading under the ancient word "for"? But I too still have to make this mental jump, if not loop.

 

Which is exactly Oliver's point.  The main reason that people keep seeing "for as a loop" in the first place was the fact that's it's named "for".

The Haskell naming convention, "do", makes this far easier. 

[Alec Zorab]

I've also seen people who are plenty smart get caught up on the whole "for isn't a loop" thing. I'm entirely sure we're too committed to the current way to change it, but the false familiarity with Java is certainly confusing for people when first encountering it.

That said, the container intuition of monads will get you surprisingly far, so maybe it's a good way to educate people without having to have the "monoids on endofunctors conversation"...

[Kevin Wright]

It's historic.  The convention of re-using "for" was to make it look familiar to Java converts, long before mainstream Scala users were seriously thinking in terms of monads, applicatives, etc. and back before we had Futures, Agents and and large swathes of scalaz available out of the box as non-collection monads.

It's easy to see how things might have been done differently in hindsight, but you can say that of any language.  It's my experience that scala has less than the language average number of legacy hangups like this :)

[Haoyi Li]

Agreed that the naming "for" is problematic. It's hard to get over a decade of experience that says "for is a loop". I don't like programming in an entirely monadic style, not because I don't want like monads, but somewhere inside my brain starts freaking out "why is everything a for loop!?!".

I think there is a way out of the for{}-loop hell in the delimited continuations plugin, since it lets you turn weird for-loopy-monadic code into more "normal" looking code

1. val usingFor = for { 
2. v1 ← f1; 
3. v2 ← f2 
4. } yield v1 + v2
5. 
   
6. val usingFlow = flow { f1() + f2() }

For some non-trivial subset of monadic code (Maybe all monadic code? I'm not very sure). Unfortunately, my experience using it wasn't very pleasant (Doesn't play nicely with higher-order-functions, messes up implicit pimping, causes weird ClassCastExceptions, etc.) and i've concluded that it probably isn't ready for prime time yet.

[Alec Zorab]

Someone needs to write a tutorial about this - "How I learned to stop worrying and love the for comprehension".

[Kevin Wright]

One of the biggest problems I see in a lot of code is what I call the "scava" syndrome.

People start out with the best of intentions to use a brave new language, but end up falling back on old bad habits.  Using nulls, not being aware that you can map/flatMap/comprehend over options, using Java threading primitives instead of actors or Futures, rarely a recursion in sight, etc. etc.

This happens a lots in some big name open source projects from big name people (I won't name names).  As people get more familiar with Scala though, the situation is definitely improving.

I'd advise anyone against judging Scala on the basis of such a monstrosity though!  If anything, these examples serve as a far stronger criticism of Java and some of the bad habits engendered by that particular language.

[Andreas Joseph Krogh]

På mandag 04. februar 2013 kl. 18:47:00, skrev Alec Zorab <alec...@gmail.com>:

Someone needs to write a tutorial about this - "How I learned to stop worrying and love the for comprehension".

 

I think it nicely sums up to "for this do that". Then it's not (only) about loops anymore.

 

--
Andreas Joseph Krogh <and...@officenet.no>      mob: +47 909 56 963
Senior Software Developer / CTO - OfficeNet AS - http://www.officenet.no
Public key: http://home.officenet.no/~andreak/public_key.asc

 

[pagoda_5b]

If the f-word (i.e. "for") is the culprit of all possible misunderstanding and confusion, wouldn't it be possible to alias it through a macro definition in the standard library?

This way you can use whatever word is preferred (unfortunately the "do" is already a keyword and so can't be reused...)

Ivano

[Naftoli Gugenheim]

Macros can't create new keywords. (Although an implicit conversion, with structural typing or a macro, could define an alias for foreach.)

In any case it wouldn't allow removing for or foreach. Although I don't really see the need.

[pagoda_5b]

I didn't meant to create a new keyword, I's thinking about a method implemented as a macro, which internally uses a for, with the inner part of the for definition passed as a closure.

But I essentially agree that I don't see a true reason for all this.

I also think that we're all getting way out of the main discussion's topic... 

bye

Ivano

[Naftoli Gugenheim]

Oh yes that is possible, but I think it needs untyped macros, IIRC.

[Detering Dirk]

> Is it a conditional masquerading as a loop, or a loop masquerading under the
> ancient word "for"? But I too still have to make this mental jump, if not loop.
>

Ever thought that a loop is a masqueraded condition with goto?

BTW: For a Java 1.4 programmer the "for" (the one which resembles scala's look) is a
masqueraded "while" over an iterator ...



BITMARCK Software GmbH
Firmensitz: Paul-Klinger-Strasse 15, 45127 Essen
Geschaeftsfuehrer: Andreas Strausfeld
Registergericht: Amtsgericht Essen HRB 20680


***********************************************************************

Die Information in dieser E-Mail ist vertraulich und ist ausschliesslich
fuer den/die benannten Adressaten bestimmt. Ein Zugriff auf diese
E-Mail durch andere Personen als den/die benannten Adressaten ist
nicht gestattet. Sollten Sie nicht der benannte Adressat sein, loeschen
Sie bitte diese E-Mail.