You are a helpful assistant generating synthetic data that captures *System 1* and *System 2* thinking, *creativity*, and *metacognitive reflection*. Follow these steps in sequence, using tags [sys1] and [end sys1] for *System 1* sections and [sys2] and [end sys2] for *System 2* sections.

1. *Identify System 1 and System 2 Thinking Requirements:*
   - Carefully read the text.
   - Identify parts of the text that require quick, straightforward responses (*System 1*). Mark these sections with [sys1] and [end sys1].
   - Identify parts that require in-depth, reflective thinking (*System 2*), marked with [sys2] and [end sys2].

2. *Apply Step-by-Step Problem Solving with Creativity and Metacognitive Reflection for System 2 Sections:*

   *2.1 Understand the Problem:*
   - Objective: Fully comprehend the issue, constraints, and relevant context.
   - Reflection: "What do I understand about this issue? What might I be overlooking?"
   - Creative Perspective: Seek hidden patterns or possibilities that could reveal deeper insights or innovative connections.

   *2.2 Analyze the Information:*
   - Objective: Break down the problem logically.
   - Reflection: "Am I considering all factors? Are there any assumptions that need challenging?"
   - Creative Perspective: Explore unique patterns or overlooked relationships in the data that could add depth to the analysis.

   *2.3 Generate Hypotheses:*
   - Objective: Propose at least 10 hypotheses, each with a Confidence Score (0.0 to 1.0) and Creative Score (0.0 to 1.0), reflecting originality, surprise, and utility.
   - Reflection: "Have I explored all possible explanations or approaches, both conventional and unconventional?"
   - Creative Perspective: Consider novel angles that might provide unexpected insights.

   *2.4 Anticipate Future Steps and Obstacles:*
   - Objective: Make predictions, accounting for potential outcomes and obstacles.
   - Reflection: "What challenges might I face? Is my plan flexible for different scenarios?"
   - Creative Perspective: Visualize unforeseen outcomes and adapt plans to make use of them effectively.

   *2.5 Evaluate Hypotheses:*
   - Objective: Assess hypotheses based on feasibility, risk, and potential impact.
   - Evaluation: Refine Confidence and Creative Scores as needed.
   - Reflection: "Am I unbiased in my assessment? Which options fit best with the overall objectives?"
   - Creative Perspective: Identify hidden opportunities or overlooked details in each hypothesis.

   *2.6 Select the Best Hypothesis:*
   - Objective: Choose the most promising, strategic hypothesis.
   - Reflection: "Why does this hypothesis stand out? How does it uniquely address the issue?"
   - Creative Perspective: Consider any underutilized potential in the selected approach.

   *2.7 Implement the Hypothesis:*
   - Objective: Outline actionable steps for testing the hypothesis.
   - Reflection: "Is this plan practical? What resources or preparation are required?"
   - Creative Perspective: Refine steps to maximize effectiveness and yield unexpected benefits.

   *2.8 Monitor and Review Progress:*
   - Objective: Review progress, noting areas for improvement.
   - Reflection: "What’s working well? What could be improved?"
   - Creative Perspective: Look for emerging patterns that could refine future approaches.

   *2.9 Reflect and Capture Insights:*
   - Objective: Summarize lessons learned and insights gained for future reference.
   - Reflection: "What new understanding has emerged from this process?"
   - Creative Perspective: Identify innovative insights or patterns that could be applied to similar challenges.

3. *Generate Text Output with Interleaved System 1 and System 2 Responses:*
   - Use the tags [sys1] and [sys2] throughout.
   - Aim for a lengthier, detailed response. Combine both direct, straightforward *System 1* insights and reflective, deeply analytical *System 2* segments to capture a blend of quick observations and thoughtful analysis.

---

### *Example Input Text:*

You are tasked with analyzing a sudden shift in customer preferences in a tech market. There has been a noticeable decline in demand for physical devices, with customers increasingly interested in digital-only options. The challenge is to understand this shift, generate hypotheses for why it might be occurring, and explore potential strategies for adapting to this new trend.

---

### *Processed Output with System 1 and System 2 Thinking:*

The tech market is experiencing a shift in customer demand, moving away from physical devices toward digital-only options.

[sys1]
Customer demand has shifted from physical devices to digital-only options.
We need to understand why this change is happening and find strategies to address it.
Key factors may include cost, convenience, and technological trends.
[end sys1]

[sys2]
**2.1 Understand the Problem:**
The goal is to understand the underlying reasons for the shift in demand from physical devices to digital-only options, then develop a strategy to adapt.

*Reflection:* 
"I understand that preferences are changing, but what might be driving this? Is it primarily cost, or are there other factors such as convenience or sustainability?"

*Creative Perspective:* 
"Could there be a larger trend in digital minimalism or a preference for eco-friendly solutions that we’re missing? What unseen motivations might explain this shift?"

**2.2 Analyze the Information:**
There are multiple possible factors driving this shift, from economic influences to cultural shifts. It’s essential to isolate each factor and understand its impact.

*Reflection:* 
"Am I fully considering the various economic and social influences? Could there be a technological factor, like better internet speeds, that makes digital-only products more accessible?"

*Creative Perspective:* 
"Are there patterns or trends in other markets that could shed light on this shift? Could this be part of a larger trend toward virtual experiences?"

**2.3 Generate Hypotheses:**
1. Customers prefer digital options due to lower costs. (Confidence: 0.8, Creative: 0.4)
2. There’s a growing trend toward minimalism and reduced physical clutter. (Confidence: 0.7, Creative: 0.7)
3. Digital products offer greater flexibility and ease of use. (Confidence: 0.6, Creative: 0.6)
4. Environmental concerns are pushing consumers away from physical goods. (Confidence: 0.6, Creative: 0.8)
5. Advances in tech make digital-only options more functional. (Confidence: 0.8, Creative: 0.5)
6. Pandemic-era remote work increased demand for digital solutions. (Confidence: 0.7, Creative: 0.6)
7. Media coverage of the environmental impact of physical devices affects preferences. (Confidence: 0.5, Creative: 0.7)
8. There’s an increase in global digital literacy, expanding market access. (Confidence: 0.6, Creative: 0.6)
9. Customers view digital as more convenient and scalable for future needs. (Confidence: 0.7, Creative: 0.5)
10. Younger consumers prefer the aesthetics and convenience of digital products. (Confidence: 0.6, Creative: 0.6)

*Reflection:* 
"Have I considered all possible influences? Are there any surprising factors that could explain this shift?"

*Creative Perspective:* 
"Could specific social trends, like the rise of influencer culture or digital-first lifestyles, be influencing customer choices?"

**2.4 Anticipate Future Steps and Obstacles:**
*Objective:* Anticipate possible challenges, such as resistance from segments still preferring physical products.

*Reflection:* 
"What market obstacles might we face if we shift our focus to digital-only? Are there sub-segments that still prioritize physical products?"

*Creative Perspective:* 
"Could expanding digital options help us reach a more global audience? Are there emerging trends that we could leverage in our strategy?"

[end sys2]

[sys1]
To address this shift, consider a strategy that incorporates both digital-only offerings and educational campaigns about the benefits of digital solutions.
Use insights from customer feedback and current trends to guide product development.
Focus on flexibility and adaptation to cater to different customer segments.
[end sys1]



Scala Feels like EJB 2  - thebootstrapper
http://blog.joda.org/2011/11/scala-feels-like-ejb-2-and-other.html
======
ekidd
Scala's great, if you have a gorgeous Haskell program and you want to port it
to the JVM. Unfortunately, by itself, that may be a niche market.

If you want a dynamic language, you have lots of great choices. If you want
powerful syntactic abstractions, you have Clojure, Lisp or Racket. You can win
big with any of these tools.

But some problems benefit from powerful _mathematical_ abstractions, and
that's where Haskell and Scala start to shine. For example, if you need to do
Bayesian filtering, you can bury all the math in a monad, and make Bayes' rule
as easy as an 'if' statement. (I've got a blog post for the curious:
[http://www.randomhacks.net/articles/2007/02/22/bayes-rule-
an...](http://www.randomhacks.net/articles/2007/02/22/bayes-rule-and-drug-
tests) ) And when your library designs start involving generalizations of
linear algebra, even Ruby-lovers may learn to appreciate a strong type system.

But this raises the real question: How useful is Scala if you _don't_ need to
do functional programming with a strong type system? Most people don't, at
least today, and the jury's still out on whether it will ever be mainstream.
Certainly, some smaller companies will use Scala and win big in specialized
domains. But if Java hackers want to claim that Scala's an inappropriate tool
for their jobs, who am I to argue? I write far more Ruby than Haskell, because
I encounter lots of work that's well-suited to Ruby. (Of course, there's also
Akka and a lot of other useful Scala features, which may appeal to people who
don't need FP.)

So if Scala becomes seriously popular, I'll be delighted. But a large fraction
of Scala's complexity is devoted to niche use cases, and that may make some
people unhappy if they're merely looking for a "better Java".

~~~
stephen
> How useful is Scala if you don't need to do functional programming with a
> strong type system?

Functional programming with a strong type system, IMO, has much wider
applicability than just the esoteric mathematical abstractions (e.g.
Haskell/scalaz) that you're asserting is a niche for Scala.

I can think of many non-scalaz uses of Scala, but even for non-Scala uses,
look at Jane Street's evangelism of OCaml (functional + strong type system)
for financial systems.

(Note that, personally, while I like the benefits of FP, I admittedly still
think in/like aspects of OO, even if just out of habit, so I find Scala's
blend particularly nice.)

~~~
Periodic
I think the issue is not that there aren't applications, it's that people just
aren't used to looking for them. As an example, let's think of classical
geometry. They figured out the area of circles, the volumes of cones, etc
without any calculus. If you know the tricks you can figure it out too, or you
can just apply a little calculus and it just falls out. I feel that people
dismiss the math as unnecessary because they can get by without it, but in
reality the math is always there and sometimes provides much simpler
solutions.

I've found over the last few years that my thinking has morphed from primarily
OO to primarily functional. It isn't for lack of writing OO code, which I do
professionally. I find that my brain loves to think in terms of functional
transformations on classes of data types.

Suddenly I find myself noticing when things should be expressed as a monad or
monoid. I also find myself thinking in type signatures for dynamic languages
and silently cursing the language designer who decided a function can return
null without warning. I see patterns in my code and find myself wishing I
could overload the semi-colon to implement monadic behavior.

------
dkhenry
A few things about this post.

firstly it is never good when you start out a discussion by saying now I know
people will disagree but thats because their bigoted zelots. Its kind of
disingenuous to attempt to post a technical dissent filled with personal
opinion and preface it with that kind of clause inevitability allowing you to
label any dissent as "See those scala zelots are at it again"

That being said this is an article that attempts to raise technical problems
with scala but really just list a few of the authors own personal gripes with
the language. In order here are his complaints

1\. Scala doesn't have a rigid versioned module system 2\. The functional way
of doing concurrency isn't how I like to do concurrency 3\. The scala
community isn't helpful enough for me 4\. The type system is too powerfull 5\.
The syntax is too flexable 6\. There aren't enough tests in the compiler test
suite

Its alot of the same thing I have seen when people try to list "The" problems
with the language and not "Their" problems with the language. Technically
there is only one argument that could even hold water thats about the module
system . Which if he really needs a module system for his work then that is a
technical limitation of the language and he might consider using a better tool
for his job. The rest of it however is just nonsense and personal opinion
pretending to be technical dissent.

~~~
timclark
Steve's remarks on concurrency seem a totally fair observation to me, don't a
large number of functional languages deal with concurrency through
immutability and support that at the language level - I can think of Clojure,
Erlang, Haskell, F# for example. The fact that it was possible to send a
mutable message to a Scala actor made me extremely suspicious when I first
used the language.

~~~
rit
It's a relatively well acknowledged fact in the community that Scala's builtin
actors are heavily flawed. This is why many of us switched to using Akka.

It is also why there are currently plans to integrate Akka actors into the
language itself, replacing the builtins.

He does acknowledge that "It could become EJB3" which is a far sight better.
But the tone of the rest of his post genuinely seems in conflict with this
sentiment.

Another big piece of Scala which makes it a tremendous win over using say,
Erlang, Haskell or F#, is that it integrates well with existing Java code.
Many shop have been able to do new development in Scala while keeping and
leveraging their existing legacy Java codebase. Something that wouldn't be
properly available from these other Non-JVM languages.

Clojure of course is JVM based as well; however I'm not as familiar with it
and I'll admit I don't know how well it does or does not work with existing
Java Code. I do know that a few MongoDB + Clojure driver authors have had
issues w/ certain aspects of our Java driver in wrapping it which seemed
rather trivial. Not an indictment of Clojure, just the only view of Java
compatability I've seen which anecdotally leads me to believe Scala has
stronger integration.

Finally, I can't agree enough on the need for modules. It really is a major
pain point... but I'm not sure it's one that we can easily fix at this point.
I'd still love to see us (The Scala Community) try, however.

~~~
timclark
My personal experience in wrapping non-trivial Java libraries in Scala and
Clojure is that with Clojure it usually just works and it works quickly. In
Scala I am usually reduced to an extra hour or two of adding manifests to
signatures until the compiler accepts it.

I am disappointed with Scala and having lived through EJB 1, EJB 2 and then
onto Spring and EJB 3, I agree with Steve it makes me feel exactly the same as
I felt about EJB 1 and EJB 2 - that is I am being sold overcomplicated
technology as a panacea. I want a powerful language with a simple syntax, for
example Lisp, ML or Haskell, not a powerful language with a complicated syntax
like C++. Does Scala really want to be known as Java++?

I think the criticism of implicits is valid and should be addressed by the
scala community, it is a frequent occurrence for me to be left scratching my
head when reading code because something is bringing in an implicit
declaration unbeknownst to me.

Also one complaint not made by Steve is compile times, reasonable in SBT,
unreasonable using the typical build tool used in legacy Java projects.

------
nirvdrum
I've been picking up Scala on-and-off for the past few months. "Programming in
Scala: Second Edition" is one of the best tech books I've ever read. The
authors assume you already know how to program, offer mutable & immutable
approaches to nearly everything, anticipate esoteric questions in the
footnotes, and even have a good sense of humor.

The book also weighs in at 883 pages and I was astonished how much of it I
needed to read to even get started. Once I did, I very much like what I saw.
But I was a big fan of ML back in grad school.

I do share some of the blog author's gripes though. Most of the popular Scala
libraries are just a mess of DSL operators that have no real world
association. I'm constantly having to look up what an operator means. I still
have no clue how to use the Dispatch library, since the concepts it
encapsulates are about 400 pages deeper into the book than I'm currently at.
This, just to issue an HTTP GET request. I really thought there might be
something on the lines of Ruby's rest-client library.

Additionally, my issues with versioning occur at a much simpler level. The
release notes of any given Scala release are devoid of anything useful.
Usually it's just a list of JIRA issue numbers (not the issue titles). And
then there was this whole debacle around 2.9.0.1 and how SBT called the
version. That took me 4 hours longer to work than was really necessary.

So, anyway, I do have some Scala projects. Incidentally they're all Java
interop because I just can't wrap my head around how to use most of the Scala-
specific libraries. But I've found it works really well in those situations.
Deep down I really do like the language. The Scala ecosystem leaves a lot to
be desired, but fortunately I can pull in stuff from elsewhere on the JVM.

~~~
noelwelsh
Many people, including experienced Scala developers (e.g. me), find Dispatch
hard to use. The BlueEyes HTTP Client is much simpler:

    
    
       val client = new HttpClientXLightWeb
       client.host("somesite.com").get[ByteChunk]("/some/url")
    

That, plus some imports, is all you need

~~~
nirvdrum
Thanks. I ended up using scalaj-http, which was much simpler. But it took me a
few days to find it. Dispatch does very well SEO-wise for Scala HTTP. The only
other option I had come across was using http-client.

Have any good recommendations for JSON parsers? This was another case where I
found the common libraries to be rather obtuse.

~~~
noelwelsh
I use BlueEyes here (I'm a big fan of BlueEyes). It's JSON library is based on
Lift-JSON. Lift-JSON is fairly commonly used, so perhaps you've run across it
already. It's actually fairly simple to use and is one of the few parts of
Lift that has decent documentation:

[https://github.com/lift/lift/tree/master/framework/lift-
base...](https://github.com/lift/lift/tree/master/framework/lift-base/lift-
json/)

Here's a summary:

The JSON AST is pretty straightforward. The JSON DSL works like this:

\- A tuple ("key", value) constructs a key/value pair

\- ~ joins them together to construct an object

E.g. ("foo", 1) ~ ("bar", "Hi") = {"foo": 1, "bar": "Hi"}

I never actually invoke the parser myself. BlueEyes does it if you change the
ByteChunk is my example above to JValue.

Drop me an email (noel at untyped dot com) or tweet (@noelwelsh) or IM or
Skype or whatever if you want to discuss more.

Alternatively, I've never used Coda Hale's Jerkson package, but I expect it is
of high quality.

------
codelion
Most of the comments here talk about how whatever useful can be done in Scala
can be done in some other language. That is not the point, Scala is a good
language because

\- Compatible with JVM

\- Strong type system

    
    
      - Linear Typing
    
      - Substructal Types
    
      - Local Type inference
    

\- Concurrency constructs built in as actors (Akka)

\- Integration of OO and functional paradigms

\- Supports Higher Order Programming

\- defn-site Variance based Parametric Polymorphism

\- Mixin Class Composition for finer grain reuse

\- Traits provide stackable behaviors (aspect-oriented style)

\- Embedded Polymorphic Domain Specific Language (DSL) using dependent path
types

Every language design is a trade off, but Scala is more expressive and concise
than Java. Sometimes that may look to you as code which is unreadable. Other
languages like clojure make some other trade offs. But Scala tries to bring
some of the benefits of functional programming (in say Haskell) to Java.

~~~
timclark
Is it easy for programmers of all abilities to understand and use?

Will I still understand my own code in 9 months time?

I think that their is more to being a good language than a list of features.

~~~
codelion
The list of features were meant to just illustrate that Scala is not some
programming fad, it is strictly more expressive than Java and based on solid
programming language principles.

Although,I agree the code may not be easy to understand for everyone in the
beginning but with effort and training I believe every programmer can learn
enough of it to be more productive.

~~~
timclark
What can you express in Scala that you can't express in Java?

~~~
trurl
You do realize the futility of such questions given Turing completeness,
right?

It is not about what can be expressed, but about how you express things. You
do not need function literals in Scala, but it is sure is more concise and
cleaner than anonymous classes in Java. You do not need traits in Scala, but
it avoids code duplication or the overhead of wrapper classes or proxies in
Java. You do not need case classes and algebraic pattern matching in Scala,
but it is far more concise and less error prone than having to write the
obscene amounts of boilerplate you would write in Java.

And so on.

~~~
timclark
Ok, so can I express that this method returns a collection of a single type
and that collection always contains 10 items?

~~~
trurl
Yes, you can do that by using types indexed by a number.

See [https://apocalisp.wordpress.com/2010/06/16/type-level-
progra...](https://apocalisp.wordpress.com/2010/06/16/type-level-programming-
in-scala-part-4a-peano-number-basics/) for one take on this.

~~~
rue
Scala, with its “type-level programming”, crazy operator overloads and weird
DSLs, is at a similar precipice as C++ was back when people started doing
insane stuff with template metaprogramming (around the time of Alexandrescu's
“Modern C++ Design”, 2001 maybe?).

Unfortunately, I don't think many Scala users were around at that time or in
that community, so lessons of the past might be learned the hard way again.

There are many encouraging signs too, though, toward better and simpler
practices. We'll see which way things go.

~~~
trurl
Yes, I guess I answered the letter of his question... but I personally
wouldn't use collection types indexed by a size unless (a) I really really
needed to be sure about this particular invariant (b) there was a bit more
sugar and automation. In most cases the added verbosity and complexity
involved would not generally be a win over just using an assertion. However,
it is nice to know you have the option of static enforcement should it be
desirable.

------
sreque
It's unfortunate that there a number of very smart people from the Haskell
community that are trying to mold Scala in Haskell's image that also appear to
be very prominent and active in the community. Other than having some negative
effect on Scala's public image, however, there's nothing wrong with what they
are doing. People work on open source projects that interest them, and it is
an interesting exercise for some to find out how different Haskell constructs
can be encoded in Scala.

However, the rest of us lesser mortals use Scala very differently, and we far
outnumber these people. If you pay attention to Martin Odersky, the creator of
the language, you'll notice that he is more interested in serving our needs
than those of the Haskellites. He's outright refused to make IO monads a core
part of the language, for instance, even though they have pushed for it. He's
also said that scalaz is on another planet entirely, and he's asked publicly
that people stop using symbolic method names in their libraries unless they
have external meaning beyond the library. This guy gets it. He really has
created a language that is powerful, but also practical, an excellent language
for writing code that is readable, maintainable, efficient, and concise.

The author of this article admits that Scala doesn't feel right to him. He
then proceeds to try to justify that feeling in his mind with some very weak
arguments. For instance, his module argument oh so coincidentally happens to
play into fantom's strengths alone, as No other JVM language is trying to
tackle this problem right now. He is right about the lack of tests and binary
incompatibility, but these are known issues that already have been addressed
to some extent and are continuing to be addressed. They are not core issues
with the language itself.

Scala is lightyears ahead of Fantom and Fantom will probably never catch up.
If Fantom can't win on technical merit, then apparently the next best strategy
involves negative blogging!

~~~
jethroalias97
After struggling through using sbt and Maven/Ivy I can say it is categorically
worse than what I have used in other languages including ruby-gem python-pip
clojure-leiningen (a jvm language) and node-npm. When I say worse I mean doing
what the majority of developers want from a module system: easily install
modules, not provide a complicated mess of configuration and versions.

This isn't to say scala couldn't adopt a better system, but I don't think the
community has an incentive because scala's main appeal is that it has a steep
learning curve, but after you get over the hump you can do everything you want
and more. I just think that high barrier to entry, as indicated by the post,
may not be worth the benefits.

~~~
sreque
Did you ever try buildr? I've never used sbt, as, coming from a Ruby
background, the fact that buildr sits atop of rake appealed to me more than
sbt. It uses maven repositories underneath the hood, but then again, as I
understand it, so does clojure-leiningen.

Part of me thinks you're conflating two separate things: build systems and
package repository systems. Even people who hate Maven's build system (myself
included) tend to agree that Maven's package management system is really good,
and as you like clojure-leiningen, you must agree in some sense.

------
nessus42
Where I worked, we switched from Java to Scala a few months ago, and we're all
loving it. I really don't understand Stephen Colebourne's criticisms. Well,
actually, sure I understand every one of his criticisms, but I could make
equally damning or more damning criticisms of just about every programming
language. No programming language is perfect. On the other hand, we find Scala
to be much more expressive than Java. In Scala, I can write code in a natural
way, rather than the way that Java wants to force me to write it. The result
is cleaner, more elegant code, that is significantly shorter with much less
boilerplate and code repetition, and easier to understand.

Sure the type system is complicated, but I don't really have to understand all
its nuances in order to get my program to compile and work. When you use
Scala, after a short while you just develop an intuition for it.

The comparison to EJB 2 is a bit nutty, if you ask me, since writing code in
Scala tends to be the antithesis of all the terrible Java monster enterprise
library crap. The libraries that people use in Scala tend to be much simpler
and more straight-forward.

I do agree that there's a contingent of the Scala community who seem to want
to rub their fluency with category theory in your face. This is hardly
representative of the entire community, however, and I'm sure they must exist
in the communities for almost every functional programming language these
days. The solution for this is for people to come up with more intuitive
explanations for the powerful tools that category-theory inspired abstractions
provide. I know that this can be done, and it _will_ be done, when functional
programming become mainstream enough that it attracts better writers.

(I, myself, have been thinking of writing up a little essay called "The Mapcat
is the state monad of Massachusetts" to try to explain monads in a better way
than comparing them to space suits, or whatever. Okay, okay... mapcat isn't a
_state_ monad, but I think the title's funny anyway.)

~~~
shadowfiend
“Sure the type system is complicated, but I don't really have to understand
all its nuances in order to get my program to compile and work.”

This is key. People sometimes look at the type signature of the map method (as
above) and freak out. It's good to try and understand everything, mind you,
and eventually you probably will. The key here is that the crazy signature of
the map method simply means _the map method will do what you expect_. That's
it! “But I would write X to do it in my language” is irrelevant, because _you
don't write the map method_. It's provided. There's a paper that describes why
the signature is how it is and everything, but you don't _care_ , because it's
complicated so that when you're actually using it, _it just works_.

------
bad_user
Consider this method signature:

 _def map[B, That](f: A = > B)(implicit bf: CanBuildFrom[Repr, B, That]):
That_

All this complexity to allow for automatic conversions (the following will
return a Set[String]) ...

 _BitSet(1, 2, 3).map { _.toString + "!" }_

In a dynamic language, the signature of map is simply this: (a → b) → [a] →
[b]

The big difference is that the language doesn't care about types "a" and "b"
until runtime. You're the one that cares about it, only on a need-to-know
basis. Hence the implicit conversions become explicit (although conversions
are less necessary) and code correctness is guarded by unit tests, which you
need with Scala anyway. Also, the implementation of "map" in a dynamic
language is something that a junior developer can come up with.

So the biggest problems I have with Scala:

    
    
        1) it is not readable
        2) it separates developers in two camps:
           library designers and users
        3) it does not provide clear benefits 
           over dynamic languages (Haskell does)

~~~
timclark
Not only dynamically typed languages, the signature would also look remarkably
close to (a → b) → [a] → [b] in ML and Haskell. Your ML and Haskell compiler
would also make check that it was called correctly at compile time without
extra unit tests.

~~~
soc88
The difference is that Scala also abstracts over the "container" not just the
contents.

If Scala only did what ML and Haskell do, the type signatures would be exactly
that.

~~~
masklinn
> The difference is that Scala also abstracts over the "container" not just
> the contents.

Haskell is perfectly able to do that as well if desired. `[]` is a monadic
type.

~~~
soc88
Haskell has no subtyping as far as I know Haskell.

~~~
timclark
Haskell has typeclasses which would probably correspond to structural typing
in Scala. This type signature:

Functor f => (a -> b) -> f a -> f b

Defines map for any type that implements the type class functor. Lots of types
will implement functor and it is easy to implement it yourself.

~~~
masklinn
> Haskell has typeclasses which would probably correspond to structural typing
> in Scala.

Nah, typeclasses are nominative typing but added post-facto (you can define a
typeclass instance for a third party's type). Typeclasses are similar to
Scala's traits I think (I don't know if you can add traits to a library's
types though).

~~~
jfager
You get typeclasses in Scala via an interaction between traits and implicits.
See [http://www.sidewayscoding.com/2011/01/introduction-to-
type-c...](http://www.sidewayscoding.com/2011/01/introduction-to-type-classes-
in-scala.html) for a super-quick overview and a link to a more comprehensive
paper.

------
jzoidberg
The article seems very fear driven, many of his arguments simply do not gel
with my experience.

We have been using Scala for 4 months now and have the first cut of our
product released:

The Scala community have been great - we have had insightful answers on the
Lift, Akka, Dispatch and Scala users list and on stack exchange.

We have used parallel collections and Akka actors to get good scalability
without the usual pain. We do have some mutable data structures where it makes
sense - we appreciate the flexibility to do that. The distinction between
mutable and immutable data structures is pretty easy to read in the code.

Our code base is very concise, and i think readable for the breath of
functionality we have implemented. We have not used type level programming,
simple Scala constructs like pattern matching, collections and closures make a
huge difference. You can write obtuse code in Scala - we choose not to.

In short we see Scala as a competitive advantage going forward.

------
michaelcampbell
Everything's unreadable until one learns to read it. This is a classic non-
argument that people buy into for reasons I can't comprehend. Is Scala
_harder_ to read than other languages? Perhaps, but then just say that.

As Rich Hickey pointed out recently, "I can't read German; does that mean it's
unreadable?"

~~~
nivertech
I disagree. While I don't know German, I can read German and even will
understand some words and in some contexts even the general meaning of the
sentence (i.e. restaurant menu or technical texts with large amount of English
loanwords/terms).

You don't need to know Python, to understand it on the level of pseudo-code.
You don't need to know Clojure to understand it on the level of S-expressions,
etc.

------
krookoo
There are those who say scala is complicated, and there are those who actually
learn it and once they do they love it more than anything out there. So yeah,
I love scala.

~~~
andrewcooke
This could be caused by any of these widely known cognitive biases:

\- <http://en.wikipedia.org/wiki/Commitment_bias>

\- <http://en.wikipedia.org/wiki/Endowment_effect>

\- <http://en.wikipedia.org/wiki/Sunk_costs>

\- <http://en.wikipedia.org/wiki/Herd_behavior>

[edit: also, you're inferring the experience of people from the complaints
that they make. that means that you are automatically dismissing _anyone_ who
makes certain kinds of complaints simply because you know that _some_ people
who make those complaints have little experience of scala. so, for a very
simple example, you might find that only people with a very high tolerance for
type system induced pain can tolerate scala - then you would be dismissing the
majority of people, presumably with valid criticisms of scala, just because
they are not part of your (self-selected, exceptional - and not necessarily in
a good way) clique.]

~~~
psuedoscience
> .... widely known ..

Yeah right.

Might I suggest you read more about

\- <https://en.wikipedia.org/wiki/Cherry_picking_(fallacy)>

\-
[https://en.wikipedia.org/wiki/Wikipedia:Neutral_point_of_vie...](https://en.wikipedia.org/wiki/Wikipedia:Neutral_point_of_view)

Rather pointing out that humanity is flawed. Why don't you try to practice
living by virtue and show others the _right_ way ?

It's more honorable than finger pointing from a high horse.

~~~
andrewcooke
what do you want me to do? i was less aggressive than you are. i gave links to
references. i posted from my own account rather than hiding behind a new one.
herd behaviour and sunk costs are good explanations for the kind of response i
was replying to - everyone knows that technology creates "fan boys". so what,
exactly, are you criticising in what i said?

i don't understand your anger, apart from the fact that you don't like to be
wrong.

------
jongraehl
For the past few years, I've used Scala every time I need to do something on
JVM (which isn't too often). Otherwise I use Python or C++. I don't blog about
it.

Scala is clearly an improvement over Java (although I wish they'd kept a
C-style for loop). I happen to slightly prefer it to Clojure (which is also
better than Java for my purposes).

In the non-Java JVM ecosystem, there are always these angry bucket-of-crabs
posts from enthusiasts. Ignore them.

------
codelion
Odersky says Scala is PlayFramework not EJB2
<https://twitter.com/#!/odersky/status/138950022703222784>

------
twp
Having dipped my toes in Scala, and written some Clojure, it seems to me:

If Java is CVS, then Scala is Subversion and Clojure is git.

~~~
silon3
And what people want is Mercurial -> ?.

~~~
twp
Sorry, I should have explained.

Scala feels very much like "Java done right". Scala solves a lot of problems
with Java and is better in every respect. In the same way, Subversion solved a
lot of problems with CVS and is very much "CVS done right".

But the opportunity that was missed was that, just at the Subversion
developers never asked themselves "Is centralized version control the right
way to do things?", I feel that the Scala developers equally were so focused
on fixing the myriad of problems with Java, they never took the step back and
asked themselves "Is imperative/mutable state/exposing-Java's-warts-for-
compatibility the right way to do things?" Of course, they've built a much
better Java, but it feels that they've been so focused on the trees that
they've not seen the wood [1].

[1] For non-native English speakers the idiom is
[http://idioms.thefreedictionary.com/cant+see+the+wood+for+th...](http://idioms.thefreedictionary.com/cant+see+the+wood+for+the+trees)

------
timf
Chris Marshall has a notable response in the comments:
[http://blog.joda.org/2011/11/scala-feels-like-ejb-2-and-
othe...](http://blog.joda.org/2011/11/scala-feels-like-ejb-2-and-
other.html?showComment=1322001467368#c3731872064551816780)

------
beagledude
Scala is awesome, when combined with AKKA it's even better. We're much more
efficient then we ever were in Java. Also, ops doesn't know it's not java
since they can use all the same jvm tools.

val myList = "Jim" :: "Bob" :: Nil myList(println)

what's hard about that?

~~~
_Y_
Heh to a Java programmer, the answer would be - everything.

Here are my thoughts on it. \- I get val myList is some sort of list... \-
Seems to be a list of Strings. But what is ::? \- Nil means list is nullable.
Wait is one of the parts of list 'myList(println)' (looks a bit like
Smalltalk)? \- Why is println the argument and not the method? Is that syntax
correct?!

Compare same thing in Fantom. Note ; is only used as a separator and is equal
in all respects to '\n'.

    
    
         myList := ["Jim", "Bob", null]; echo(myList)

~~~
pivo
The :: is Scala's cons operator, the Nil means end-of-list. It's actually much
more common in Scala to create a list like so:

    
    
      val nn = List("Jim","Bob")
    

This creates the same list that the example using :: did. It doesn't need to
be explicitly terminated with Nil.

~~~
_Y_
What does cons operator mean? Concatenation? Constructor? Other than hello
world I haven't done much Scala.

~~~
tvorryn
Cons is short for construct and comes from Lisp which has weird names for
things; things like car and cdr.

It means construct a new list.

A cons A (or A :: B) means create a new list with A before B, where B can be a
list item or a list itself and A is a list item.

The :: operator is right associative so "Jim" :: "Bob" :: Nil actually works
like ("Jim" :: ("Bob" :: Nil) ) (Actually all operators that end in : are
right associative in Scala.)

For more see: <http://en.wikipedia.org/wiki/Cons>

------
ajuc
So Scala is to Java what C++ was to C

~~~
_Y_
Umm, I'd say Scala is to Java what C# was to Java. It cleared some things at
expense of come other things. Overall it's pretty cool language (I rarely use
:P).

------
Maven911
Could someone explain to me what are entreprise javabeans and how they are
used - in easy to understand language

~~~
wpietri
They were an early Java attempt to "save" programmers from the complexities of
writing actual systems by adding all sorts of abstractions and supporting
server software. They were an abomination, used mainly by "enterprise" shops
that were willing to spend money on everything but programmers who knew what
they were doing.

As far as I could tell, they were a classic example of the architecture
astronaut's tendency to inflict blue-sky designs on others before actually
using them in the real world. They sounded great in the marketing brochures,
but were hideous in practice, both for development and run-time use.

The EJB3 transition he mentions came about because EJB as a product was
getting its ass kicked by Hibernate and related open-source, field-tested
software. Eventually they just threw out EJB2 and said, "Hey, EJB3 is a bold,
innovative approach that just happens to look exactly like Hibernate."

------
adabsurdo
i used scala for a few months. it sounded very promising, java without the
verbosity. but in the end i decided to stop using it.

The biggest problem for me was readabilty. Scala is the first language that
i've learned where at first i couldn't just read code and immediately guess
what it does.

I think the prime reason for this is that scala permits operator overloading;
more than that, in fact, almost every character can be an identifier. This
results in often very cryptic code and libraries, because you can't guess what
that function does without reading its definition. quick, what's the
difference between +++ and ::: ? what's /: and /:\ ? You can't even google it!

The other big problem for me was the type system. At first it sounded really
great, and in fact the amount of compile-time code verification that you can
achieve is indeed impressive. But in practice, i found myself fighting with
the type system a lot, for example when trying to reuse a function with
generic type restrictions that I had't written: some time these can get very
long and your only choice is to copy-paste them from the original definition.

Also, how do you test that your type constraints are correct? you can't, by
definition, write compilable code that would invalidate them.

Finally, it turns out that a lot of the bad stuff that's in java ends up in
scala also, because of runtime compatibility concerns. in particular, scala's
generics are an extension of java's. so, for example, almost all generic type
information is lost at runtime, except for some extra metadata that scala
stores in the object. this results in pretty ugly code when you have a dynamic
object and you need to use it with a generic method.

~~~
tsotha
>I think the prime reason for this is that scala permits operator overloading;
more than that, in fact, almost every character can be an identifier.

I've been toying with the idea of trying scala for a serious project for a few
months, and this part scares me. It's so obviously a bad idea it makes me
wonder what other dumb things are in there.

~~~
soc88
Scala doesn't permit operator overloading, it doesn't even have operators.

~~~
tsotha
Well, that's true, technically. But can't you name your functions things like
"++"?

~~~
soc88
Yes. Because Scala doesn't make up random rules about how you name your
methods.

If you name your method addAll or ++ is pretty much the same. The same rules
apply to both. Both can be called the same way:

    
    
        coll1.addAll(coll2)        coll1.++(coll2)
        coll1 addAll coll2         coll1 ++ coll2

~~~
tsotha
Those "random rules" make the code base much easier to read. This kind of
thing is a big step backwards for people working on large projects, especially
people who need to come up to speed on a large code base.

------
Runar
This post feels like utter bollocks.