Complexity of Scala versus Kotlin/Ceylon

Having been in a lot of projects, I would agree that a team who can't handle more powerful features should not be expected to use them. You end up with an really terrible mess. If all you need to do is something simple like transform database rows in to HTML tables, you probably don't need a powertool to get it done.

The "simplicity" argument, though, definitely is a red herring. If you want simplicity, why not just use BASIC? Maybe there's a even a "visual" form of BASIC that would be even better, where you could program by just dragging and dropping items around?

I find well-designed Scala DSLs just so powerful, as are DSLs in other languages. But when you add typesafety? Oh my gosh -- I just don't want to go back to anything unexpressive or weakly typed. To me it just  feels childish to do so -- like I'm playing with popguns where I was firing live ordinance before.

Brian Maso

On Thu, Jul 21, 2011 at 8:39 PM, Eric Pederson <ericacm [at] gmail [dot] com> wrote:

One of the big claims that Kotlin and Ceylon are making is that Scala is too complex and that these other languages are simpler.   They don't really back up these claims yet, but the general idea seems to be that they get their simplicity through a intentionally limited feature set.   (It remains to be seen if they will ultimately resist the temptation to get feature parity with Scala.)  
My initial reaction to the simplicity argument was that it was FUD - your Scala code can be as simple or complex as you want -- that is part of Scala's nature being a "Scalable Language".   However, a good point was made on the Kotlin wiki (http://confluence.jetbrains.net/display/Kotlin/Welcome?focusedCommentId=40703726#comment-40703726):
"When you're coming to a project of legacy code (that hundreds different people written several years), you [can't] ignore all of scala's overcomplicated features. You'll have to understand all of them."  
This is a pretty interesting argument that enterprise management types would find compelling.  Being the sole Scala developer in my typically enterprise dev group I often reflect back on my code wondering if I made it too clever/concise/etc for whoever is going to have to maintain it.
What do we do about this?   For Scala to go mainstream it has to address the "too complex" issue.  One idea is to use profiles or levels to tell the compiler to reject certain language features.  Conservative development shops could turn off "dangerous" stuff in regular app code.
Thoughts?

-- Eric

--
Best regards,
Brian Maso
(949) 395-8551
Follow me: @bmaso
brian [at] blumenfeld-maso [dot] com

What is the problem with complexity? If the problem is the learning curve, then "what will happen if I need to work on a project with legacy scala code" is not an issue: the answer is, if by then you haven't gotten far enough along the learning curve, then you'll have to deal with it at that point and learn what you're still missing. The bottom line is that yes, scala is simple enough that you can jump right in and start gaining from it, and and keep learning more ways to gain from it.

On Thu, Jul 21, 2011 at 11:39 PM, Eric Pederson <ericacm [at] gmail [dot] com> wrote:

One of the big claims that Kotlin and Ceylon are making is that Scala is too complex and that these other languages are simpler.   They don't really back up these claims yet, but the general idea seems to be that they get their simplicity through a intentionally limited feature set.   (It remains to be seen if they will ultimately resist the temptation to get feature parity with Scala.)  
My initial reaction to the simplicity argument was that it was FUD - your Scala code can be as simple or complex as you want -- that is part of Scala's nature being a "Scalable Language".   However, a good point was made on the Kotlin wiki (http://confluence.jetbrains.net/display/Kotlin/Welcome?focusedCommentId=40703726#comment-40703726):
"When you're coming to a project of legacy code (that hundreds different people written several years), you [can't] ignore all of scala's overcomplicated features. You'll have to understand all of them."  
This is a pretty interesting argument that enterprise management types would find compelling.  Being the sole Scala developer in my typically enterprise dev group I often reflect back on my code wondering if I made it too clever/concise/etc for whoever is going to have to maintain it.
What do we do about this?   For Scala to go mainstream it has to address the "too complex" issue.  One idea is to use profiles or levels to tell the compiler to reject certain language features.  Conservative development shops could turn off "dangerous" stuff in regular app code.
Thoughts?

-- Eric

On Thu, Jul 21, 2011 at 11:39 PM, Eric Pederson <ericacm [at] gmail [dot] com> wrote:

One of the big claims that Kotlin and Ceylon are making is that Scala is too complex and that these other languages are simpler.   They don't really back up these claims yet, but the general idea seems to be that they get their simplicity through a intentionally limited feature set.   (It remains to be seen if they will ultimately resist the temptation to get feature parity with Scala.)  

I think they're fooling themselves.  With very few exceptions, I think Scala is only as complex as necessary in order to allow programmers to solve difficult problems clearly and compactly.

If their selling point is that they can solve easy problems even more easily than in Scala, and that people wouldn't really dare to tackle a hard problem, so you don't have to worry about that either, that isn't much of a selling point to me.

Take parser combinators, for example.  I've written a lot of little parsers in a lot of languages over the years, and they've always been a pain.  Then along comes Scala--and poof!  90% of parsing jobs are now simple with a DSL from a library.  Brilliant!  If you make a language that doesn't comfortably support parser combinators, you've made it "simpler" by making parser construction much harder.  Yay?

That said, there is a place for languages that make easy problems easy and hard problems terrifying: it keeps people who have less training from making as bad a mess of things.  I don't think Scala needs to be that language.
 

"When you're coming to a project of legacy code (that hundreds different people written several years), you [can't] ignore all of scala's overcomplicated features. You'll have to understand all of them."  

This is only true if either
  (a) Your project required all those features or it would be an even more complicated code base, or
  (b) Your coders didn't exercise discipline in their coding.
Sadly, (b) is all too common.

I think there is a place--a very large place, occupied by a large number of excellent programmers writing really interesting things--for people who can exercise some discipline in their coding.  I don't think it reflects badly on Scala that people can use it to write unmaintainable code.  It also doesn't reflect badly on other languages that they try to force you to write maintainable code.  They are different, largely opposing use cases.  Scala shouldn't adopt gratuitously confusing or dangerous features, but I think it's okay to sit in the "with power comes responsibility" corner. 
 

What do we do about this?   For Scala to go mainstream it has to address the "too complex" issue.  One idea is to use profiles or levels to tell the compiler to reject certain language features.  Conservative development shops could turn off "dangerous" stuff in regular app code.

The best libraries require a lot of "dangerous" stuff, and anyway, the "dangerous" stuff is there to make difficult problems more approachable.  So this seems like a bad idea.  If you run a conservative development shop, hire talented people or don't use Scala.

  --Rex

How is "I have to understand something" in any way a good point? I can't think of a point for which I have the highest contempt.

On 22/07/11 13:39, Eric Pederson wrote:

ziqm6JQa0FdKA [at] mail [dot] gmail [dot] com" type="cite">One of the big claims that Kotlin and Ceylon are making is that Scala is too complex and that these other languages are simpler.   They don't really back up these claims yet, but the general idea seems to be that they get their simplicity through a intentionally limited feature set.   ( It remains to be seen if they will ultimately resist the temptation to get feature parity with Scala.)  
My initial reaction to the simplicity argument was that it was FUD - your Scala code can be as simple or complex as you want -- that is part of Scala's nature being a "Scalable Language".   However, a good point was made on the Kotlin wiki (http://confluence.jetbrains.net/display/Kotlin/Welcome?focusedCommentId=40703726#comment-40703726):
"When you're coming to a project of legacy code (that hundreds different people written several years), you [can't] ignore all of scala's overcomplicated features. You'll have to understand all of them."  
This is a pretty interesting argument that enterprise management types would find compelling.  Being the sole Scala developer in my typically enterprise dev group I often reflect back on my code wondering if I made it too clever/concise/etc for whoever is going to have to maintain it.
What do we do about this?   For Scala to go mainstream it has to address the "too complex" issue.  One idea is to use profiles or levels to tell the compiler to reject certain language features.  Conservative development shops could turn off "dangerous" stuff in regular app code.
Thoughts?

-- Eric

-- 
Tony Morris
http://tmorris.net/

On Thu, Jul 21, 2011 at 8:39 PM, Eric Pederson wrote:
> One of the big claims that Kotlin and Ceylon are making is that Scala is too
> complex and that these other languages are simpler.   They don't really back
> up these claims yet, but the general idea seems to be that they get their
> simplicity through a intentionally limited feature set.   (It remains to be
> seen if they will ultimately resist the temptation to get feature parity
> with Scala.)
> My initial reaction to the simplicity argument was that it was FUD - your
> Scala code can be as simple or complex as you want -- that is part of
> Scala's nature being a "Scalable Language".   However, a good point was made
> on the Kotlin wiki
> (http://confluence.jetbrains.net/display/Kotlin/Welcome?focusedCommentId=...):
> "When you're coming to a project of legacy code (that hundreds different
> people written several years), you [can't] ignore all of scala's
> overcomplicated features. You'll have to understand all of them."
> This is a pretty interesting argument

Well, it's interesting in that it begs the question by asserting that
Scala has "all" these "overcomplicated" features -- which, aside from
not being supported by a reasoned argument, is somewhat dishonest
considering how many of Scala's features Kotlin has adopted, sometimes
making them more complicated in the process. As for the point it tries
to make, language features are a red herring, because they are a small
fragment of the entire project ecology that must be understood, most
of which is far more obscure and undocumented than the language
features ... *especially* if powerful language features aren't
available.

> that enterprise management types would
> find compelling.  Being the sole Scala developer in my typically enterprise
> dev group I often reflect back on my code wondering if I made it too
> clever/concise/etc for whoever is going to have to maintain it.

And what would prevent you form doing that in Kotlin code? This
illustrates the red herring.

> What do we do about this?   For Scala to go mainstream it has to address the
> "too complex" issue.

It's largely a political issue, and must be addressed by pushing back
against misinformation and bad arguments, by educating people, by
getting more major adopter and testimonials, and by being somewhat
more "diplomatic" in certain areas.

>  One idea is to use profiles or levels to tell the
> compiler to reject certain language features.  Conservative development
> shops could turn off "dangerous" stuff in regular app code.
> Thoughts?

This idea has been discussed here at some length. I believe it's
fraught with problems, but you might want to hunt down the discussion
to get the full range of opinion.

Kotlin looks relatively nice and decent, and if there were no Scala, I'd be already writing slide shows on why we should choose Kotlin over Java.

But it's too late.

Scala sets much higher standards. Higher order generics. Implicits. (Almost) union types. :)

I believe Kotlin will stay a niche langauge, like Groovy and the likes.

(disclaimer: I know nothing about The Market)

Thanks,
-Vlad


On Thu, Jul 21, 2011 at 8:39 PM, Eric Pederson <ericacm [at] gmail [dot] com> wrote:

One of the big claims that Kotlin and Ceylon are making is that Scala is too complex and that these other languages are simpler.   They don't really back up these claims yet, but the general idea seems to be that they get their simplicity through a intentionally limited feature set.   (It remains to be seen if they will ultimately resist the temptation to get feature parity with Scala.)  
My initial reaction to the simplicity argument was that it was FUD - your Scala code can be as simple or complex as you want -- that is part of Scala's nature being a "Scalable Language".   However, a good point was made on the Kotlin wiki (http://confluence.jetbrains.net/display/Kotlin/Welcome?focusedCommentId=40703726#comment-40703726):
"When you're coming to a project of legacy code (that hundreds different people written several years), you [can't] ignore all of scala's overcomplicated features. You'll have to understand all of them."  
This is a pretty interesting argument that enterprise management types would find compelling.  Being the sole Scala developer in my typically enterprise dev group I often reflect back on my code wondering if I made it too clever/concise/etc for whoever is going to have to maintain it.
What do we do about this?   For Scala to go mainstream it has to address the "too complex" issue.  One idea is to use profiles or levels to tell the compiler to reject certain language features.  Conservative development shops could turn off "dangerous" stuff in regular app code.
Thoughts?

-- Eric

Hi Eric

[Quote from Kotlin]
> "When you're coming to a project of legacy code (that hundreds different
> people written several years), you [can't] ignore all of scala's
> overcomplicated features. You'll have to understand all of them."
...
> What do we do about this? For Scala to go mainstream it has to address
> the "too complex" issue. One idea is to use profiles or levels to tell
> the compiler to reject certain language features. Conservative
> development shops could turn off "dangerous" stuff in regular app code.

I thought about compiler levels of allowed complexity as well (whatever
definition of complexity we want to apply).
But I dismissed it after quite some time. Because I came to the conclusion
that each feature of scala is part of a problem solving toolset. By removing
any feature of this toolset you might force devs into solving problems with
less appropriate tools creating even less obvious or less efficient solutions.

I would recommend
- a scalaish adaption of code metrics to be able to measure some code
properties (for the rough sketch and as warning signal)
- team code reviews to identify proplematic parts
- good documentation and education
- code styleguides, code conventions

Any feature can be misused (in any language). It's about establishing a code
culture and a diagnostic toolset to help create and maintain a sound codebase.

And we all now - a dev who doesn't care will create code problems no matter
what language he/she is using.

Just my 5 cents
Bernd

We had a discussion about this at work.

They make the argument that implicits are too complex, but I did not
see anything about their collections. If they manage to get the scala
collection behavior (all transformations keep the proper type when
possible) without implicits, then they will have a point. But if they
can't do it then obviously the language is lacking in features. Having
used the scala collections I am not willing to go back to a collection
library where you can not do transformations while preserving the
type.

Kotlin claims to have "reified generics". I am curious how they did
that. But there is not even a REPL yet that would allow you to play
with it. So I guess we will have to wait.

I hope that kotlin does not lead to jetbrains slowing the development
of the scala plugin for IDEA.

On Jul 22, 5:39 am, Eric Pederson wrote:
> One of the big claims that Kotlin and Ceylon are making is that Scala is too
> complex and that these other languages are simpler.   They don't really back
> up these claims yet, but the general idea seems to be that they get their
> simplicity through a intentionally limited feature set.   (It remains to be
> seen if they will ultimately resist the temptation to get feature parity
> with Scala.)
>
> My initial reaction to the simplicity argument was that it was FUD - your
> Scala code can be as simple or complex as you want -- that is part of
> Scala's nature being a "Scalable Language".   However, a good point was made
> on the Kotlin wiki (http://confluence.jetbrains.net/display/Kotlin/Welcome?focusedComment...
> ):
>
> "When you're coming to a project of legacy code (that hundreds different
> people written several years), you [can't] ignore all of scala's
> overcomplicated features. You'll have to understand all of them."
>
> This is a pretty interesting argument that enterprise management types would
> find compelling.  Being the sole Scala developer in my typically enterprise
> dev group I often reflect back on my code wondering if I made it too
> clever/concise/etc for whoever is going to have to maintain it.
>
> What do we do about this?   For Scala to go mainstream it has to address the
> "too complex" issue.  One idea is to use profiles or levels to tell the
> compiler to reject certain language features.  Conservative development
> shops could turn off "dangerous" stuff in regular app code.
>
> Thoughts?
>

On 22/07/11 16:20, rklaehn wrote:
> They make the argument that implicits are too complex
This statement discredits itself.

They add a field that holds a TypeInfo.

On Fri, Jul 22, 2011 at 2:20 AM, rklaehn <rklaehn [at] googlemail [dot] com> wrote:

We had a discussion about this at work.

They make the argument that implicits are too complex, but I did not
see anything about their collections. If they manage to get the scala
collection behavior (all transformations keep the proper type when
possible) without implicits, then they will have a point. But if they
can't do it then obviously the language is lacking in features. Having
used the scala collections I am not willing to go back to a collection
library where you can not do transformations while preserving the
type.

Kotlin claims to have "reified generics". I am curious how they did
that. But there is not even a REPL yet that would allow you to play
with it. So I guess we will have to wait.

I hope that kotlin does not lead to jetbrains slowing the development
of the scala plugin for IDEA.

On Jul 22, 5:39 am, Eric Pederson <eric [dot] [dot] [dot] [at] gmail [dot] com> wrote:
> One of the big claims that Kotlin and Ceylon are making is that Scala is too
> complex and that these other languages are simpler.   They don't really back
> up these claims yet, but the general idea seems to be that they get their
> simplicity through a intentionally limited feature set.   (It remains to be
> seen if they will ultimately resist the temptation to get feature parity
> with Scala.)
>
> My initial reaction to the simplicity argument was that it was FUD - your
> Scala code can be as simple or complex as you want -- that is part of
> Scala's nature being a "Scalable Language".   However, a good point was made
> on the Kotlin wiki (http://confluence.jetbrains.net/display/Kotlin/Welcome?focusedComment...
> ):
>
> "When you're coming to a project of legacy code (that hundreds different
> people written several years), you [can't] ignore all of scala's
> overcomplicated features. You'll have to understand all of them."
>
> This is a pretty interesting argument that enterprise management types would
> find compelling.  Being the sole Scala developer in my typically enterprise
> dev group I often reflect back on my code wondering if I made it too
> clever/concise/etc for whoever is going to have to maintain it.
>
> What do we do about this?   For Scala to go mainstream it has to address the
> "too complex" issue.  One idea is to use profiles or levels to tell the
> compiler to reject certain language features.  Conservative development
> shops could turn off "dangerous" stuff in regular app code.
>
> Thoughts?
>
> -- Eric

Simple enough. You could do the same in scala, and in a way you do
just that when having an implicit manifest.

But how will they interact with existing classes (e.g. from Java) that
don't have that field? You won't be able to distinguish a
java.util.List from a java.util.List since the
information is simply not there, right?

There really should be a JVM wide standard about how to encode such
information. Otherwise we will end up with each language having its
own, incompatible way...

On Fri, Jul 22, 2011 at 8:39 AM, Naftoli Gugenheim wrote:
> They add a field that holds a TypeInfo.
>
> On Fri, Jul 22, 2011 at 2:20 AM, rklaehn wrote:
>>
>> We had a discussion about this at work.
>>
>> They make the argument that implicits are too complex, but I did not
>> see anything about their collections. If they manage to get the scala
>> collection behavior (all transformations keep the proper type when
>> possible) without implicits, then they will have a point. But if they
>> can't do it then obviously the language is lacking in features. Having
>> used the scala collections I am not willing to go back to a collection
>> library where you can not do transformations while preserving the
>> type.
>>
>> Kotlin claims to have "reified generics". I am curious how they did
>> that. But there is not even a REPL yet that would allow you to play
>> with it. So I guess we will have to wait.
>>
>> I hope that kotlin does not lead to jetbrains slowing the development
>> of the scala plugin for IDEA.
>>
>> On Jul 22, 5:39 am, Eric Pederson wrote:
>> > One of the big claims that Kotlin and Ceylon are making is that Scala is
>> > too
>> > complex and that these other languages are simpler.   They don't really
>> > back
>> > up these claims yet, but the general idea seems to be that they get
>> > their
>> > simplicity through a intentionally limited feature set.   (It remains to
>> > be
>> > seen if they will ultimately resist the temptation to get feature parity
>> > with Scala.)
>> >
>> > My initial reaction to the simplicity argument was that it was FUD -
>> > your
>> > Scala code can be as simple or complex as you want -- that is part of
>> > Scala's nature being a "Scalable Language".   However, a good point was
>> > made
>> > on the Kotlin wiki
>> > (http://confluence.jetbrains.net/display/Kotlin/Welcome?focusedComment...
>> > ):
>> >
>> > "When you're coming to a project of legacy code (that hundreds different
>> > people written several years), you [can't] ignore all of scala's
>> > overcomplicated features. You'll have to understand all of them."
>> >
>> > This is a pretty interesting argument that enterprise management types
>> > would
>> > find compelling.  Being the sole Scala developer in my typically
>> > enterprise
>> > dev group I often reflect back on my code wondering if I made it too
>> > clever/concise/etc for whoever is going to have to maintain it.
>> >
>> > What do we do about this?   For Scala to go mainstream it has to address
>> > the
>> > "too complex" issue.  One idea is to use profiles or levels to tell the
>> > compiler to reject certain language features.  Conservative development
>> > shops could turn off "dangerous" stuff in regular app code.
>> >
>> > Thoughts?
>> >
>> > -- Eric
>

On Thu, Jul 21, 2011 at 11:20 PM, rklaehn wrote:
> We had a discussion about this at work.
>
> They make the argument that implicits are too complex, but I did not
> see anything about their collections.

From http://confluence.jetbrains.net/display/Kotlin/FAQ?focusedCommentId=4070...

Andrey Breslav: "There will be a collection library in Kotlin standard
library. The exact design is not fixed yet."

> If they manage to get the scala
> collection behavior (all transformations keep the proper type when
> possible) without implicits, then they will have a point. But if they
> can't do it then obviously the language is lacking in features. Having
> used the scala collections I am not willing to go back to a collection
> library where you can not do transformations while preserving the
> type.
>
> Kotlin claims to have "reified generics". I am curious how they did
> that. But there is not even a REPL yet that would allow you to play
> with it. So I guess we will have to wait.
>
> I hope that kotlin does not lead to jetbrains slowing the development
> of the scala plugin for IDEA.
>
> On Jul 22, 5:39 am, Eric Pederson wrote:
>> One of the big claims that Kotlin and Ceylon are making is that Scala is too
>> complex and that these other languages are simpler.   They don't really back
>> up these claims yet, but the general idea seems to be that they get their
>> simplicity through a intentionally limited feature set.   (It remains to be
>> seen if they will ultimately resist the temptation to get feature parity
>> with Scala.)
>>
>> My initial reaction to the simplicity argument was that it was FUD - your
>> Scala code can be as simple or complex as you want -- that is part of
>> Scala's nature being a "Scalable Language".   However, a good point was made
>> on the Kotlin wiki (http://confluence.jetbrains.net/display/Kotlin/Welcome?focusedComment...
>> ):
>>
>> "When you're coming to a project of legacy code (that hundreds different
>> people written several years), you [can't] ignore all of scala's
>> overcomplicated features. You'll have to understand all of them."
>>
>> This is a pretty interesting argument that enterprise management types would
>> find compelling.  Being the sole Scala developer in my typically enterprise
>> dev group I often reflect back on my code wondering if I made it too
>> clever/concise/etc for whoever is going to have to maintain it.
>>
>> What do we do about this?   For Scala to go mainstream it has to address the
>> "too complex" issue.  One idea is to use profiles or levels to tell the
>> compiler to reject certain language features.  Conservative development
>> shops could turn off "dangerous" stuff in regular app code.
>>
>> Thoughts?
>>

It's good idea that the compiler could manage a profile. There are Standard Application Profile, Advance Application Profile,Standard Framework Profile,Advance Framework Profile.And the compiler could warn when the code or function exceed.
The implicit is really magic and should be avoid or cautious.

> It's good idea that the compiler could manage a profile.
> There are Standard Application Profile, Advance Application
> Profile,Standard Framework Profile,Advance Framework Profile.
> And the compiler could warn when the code or function exceed.
>
> The implicit is really magic and should be avoid or cautious.

I really believe that this is a company "internal development standard"
problem, and there was the same with Java.
Implicit are no more magic than Java broken memory model, untyped
collection are variant array... or even Java Generics. I could say they
are complexe, because I just never understood them. Is that a reason to
ask Oracle to build compiler profile to forbid them ? No, better I try
to understand them and decide with my team which aspects of them we will
use in our soft, and why.

I don't know Kotlin (or Ceylon), but I'm pretty sure they will have
gotcha, and things tagged as "magic", and they will endure really alike
comments about complexity. Just because they are new, they bring new
ideas, people have to understand and get used to them.

The scala code with implicit is similar like classical Chinese with metaphor.It could express things with little or without word.
But it ask the code writer have much knowledge , experiences.And the code reader should family with the full code context.

On Fri, Jul 22, 2011 at 11:23 AM, Xuefeng Wu wrote:
> The scala code with implicit is similar like classical Chinese
> with metaphor.
> It could express things with little or without word.
> But it ask the code writer have much knowledge , experiences.
> And the code reader should family with the full code context.

Nice explanation! :-)

This is more a thread for scala-debate, no? Where there is already a long thread on Kotlin
and complexity...

On 22/07/2011 05:39, Eric Pederson wrote:
> "When you're coming to a project of legacy code (that hundreds different people written
> several years), you [can't] ignore all of scala's overcomplicated features. You'll have to
> understand all of them."

Not necessarily. The Scala compiler, and probably the collection library, are probably
using "overcomplicated features", yet they make (or try hard) a good job at hiding them.
That's a responsibility of a good library: make hard things possible, perhaps doing ugly
(but efficient) or complex things behind the functions we see.

Most of the maintainers of the large codebase will have to deal with this library and the
code using it, which hopefully can remain simple.
Only advanced users will have to dive into the library itself to maintain it.

See Martin's levels of Scala essay.

The complexity argument will solve itself once there is market demand for Scala developers. I've seen large legacy Java projects with extremely complex code bases that managed to hire new people and stay afloat. It is as if people have no issue with complexity once they can be paid for it.

Now being able to navigate and refactor large code bases efficiently is crucial in enterprise environments and this is today an area where Scala lacks behind. Of course, adressing compile time speed and IDE support issues caused by (higher-kinded) type inference and implicit resolution takes time because these are innovative features Scala brings on the table.

JetBrain could have collaborated with Scala folks to improve the presentation compiler. It could have invested in the design of new visualisation tools to provide the best commercial IDE support for Scala development. But no. Instead it drops the ball and "creates" a language that supports only the features that would have made Scala just a better Java.

I haven't seen a good explanation of what went wrong here. People drop bluntly a "Scala is too complex", but then it is fair to question their ability to innovate or support innovation.

2011/7/22 Eric Pederson <ericacm [at] gmail [dot] com>

One of the big claims that Kotlin and Ceylon are making is that Scala is too complex and that these other languages are simpler.   They don't really back up these claims yet, but the general idea seems to be that they get their simplicity through a intentionally limited feature set.   (It remains to be seen if they will ultimately resist the temptation to get feature parity with Scala.)  
My initial reaction to the simplicity argument was that it was FUD - your Scala code can be as simple or complex as you want -- that is part of Scala's nature being a "Scalable Language".   However, a good point was made on the Kotlin wiki (http://confluence.jetbrains.net/display/Kotlin/Welcome?focusedCommentId=40703726#comment-40703726):
"When you're coming to a project of legacy code (that hundreds different people written several years), you [can't] ignore all of scala's overcomplicated features. You'll have to understand all of them."  
This is a pretty interesting argument that enterprise management types would find compelling.  Being the sole Scala developer in my typically enterprise dev group I often reflect back on my code wondering if I made it too clever/concise/etc for whoever is going to have to maintain it.
What do we do about this?   For Scala to go mainstream it has to address the "too complex" issue.  One idea is to use profiles or levels to tell the compiler to reject certain language features.  Conservative development shops could turn off "dangerous" stuff in regular app code.
Thoughts?

-- Eric

--
Sébastien

From what I have seen from Kotlin, I'm certain that a language like
that has much higher chance for mass adaptation than Scala has (but of
course, much more is needed for that than the language itself, so it
doesn't mean at all that Kotlin will go anywhere). Wouldn't you agree?
It addresses tasks that ordinal Java developers recognize on a direct
and catching way. Just look at Kotlin "properties", or its null-safety
(compared to Option-s). If you are someone who is smart with languages
then maybe you say that Scala is more flexible, more correct, etc.
Certainly, but I doubt that ordinary developers see that, want that,
or maybe even that they need that. Surely it's part psychological on
their side, because you also have to grasp a lot of API-s, frameworks,
tools, etc., and compared to that the difficulty of the language is
maybe not a big deal. OTOH maybe most programmers indeed aren't good
when it comes to languages (consider: PHP is a raging success; users
should be disgusted at seeing the language design and run away, but
they don't even notice anything), so they can just never truly grasp a
deeper language.

Yeah.

It seems that every time a new "simpler" language is presented, it
ends up
becoming a complex language over the time, sometimes even more complex
than the languages it was supposed to replace.

Sure Scala, C++, PL/I, Algol among others, are complex languages. But
we
live in a complex world.

Only complex languages can provide the right abstraction mechanisms to
handle
most architecture issues.

I think the desire for simple languages comes from this idea that
everyone should
be able to program. Or even better, simple languages make it easier to
replace
developers, forgetting that the language is only one piece of the
software
development puzzle.

The thing is, I don't expect in many jobs the people to know their job
without proper
education, so why should computing be any different?

--
Paulo

On Jul 22, 8:24 am, Tony Morris wrote:
> On 22/07/11 16:20, rklaehn wrote:> They make the argument that implicits are too complex
>
> This statement discredits itself.
>
> --
> Tony Morrishttp://tmorris.net/

Computing is different because you never see _Brain Surgery for Dummies_

-----Original Message-----
From: scala-user [at] googlegroups [dot] com [mailto:scala-user [at] googlegroups [dot] com] On Behalf Of Paulo Pinto
Sent: Friday, July 22, 2011 10:06 AM
To: scala-user
Subject: [scala-user] Re: Complexity of Scala versus Kotlin/Ceylon

Yeah.

It seems that every time a new "simpler" language is presented, it ends up becoming a complex language over the time, sometimes even more complex than the languages it was supposed to replace.

Sure Scala, C++, PL/I, Algol among others, are complex languages. But we live in a complex world.

Only complex languages can provide the right abstraction mechanisms to handle most architecture issues.

I think the desire for simple languages comes from this idea that everyone should be able to program. Or even better, simple languages make it easier to replace developers, forgetting that the language is only one piece of the software development puzzle.

The thing is, I don't expect in many jobs the people to know their job without proper education, so why should computing be any different?

--
Paulo

On Jul 22, 8:24 am, Tony Morris wrote:
> On 22/07/11 16:20, rklaehn wrote:> They make the argument that
> implicits are too complex
>
> This statement discredits itself.
>
> --
> Tony Morrishttp://tmorris.net/

On Fri, Jul 22, 2011 at 4:10 PM, Nation, Carey <Carey [dot] Nation [at] turner [dot] com> wrote:

Computing is different because you never see _Brain Surgery for Dummies_

http://i628.photobucket.com/albums/uu7/longshotkickde/BrainSurgeryForDummies.jpg
 

-----Original Message-----
From: scala-user [at] googlegroups [dot] com [mailto:scala-user [at] googlegroups [dot] com] On Behalf Of Paulo Pinto
Sent: Friday, July 22, 2011 10:06 AM
To: scala-user
Subject: [scala-user] Re: Complexity of Scala versus Kotlin/Ceylon

Yeah.

It seems that every time a new "simpler" language is presented, it ends up becoming a complex language over the time, sometimes even more complex than the languages it was supposed to replace.

Sure Scala, C++, PL/I, Algol among others, are complex languages. But we live in a complex world.

Only complex languages can provide the right abstraction mechanisms to handle most architecture issues.

I think the desire for simple languages comes from this idea that everyone should be able to program. Or even better, simple languages make it easier to replace developers, forgetting that the language is only one piece of the software development puzzle.


The thing is, I don't expect in many jobs the people to know their job without proper education, so why should computing be any different?

--
Paulo

On Jul 22, 8:24 am, Tony Morris <tonymor [dot] [dot] [dot] [at] gmail [dot] com> wrote:
> On 22/07/11 16:20, rklaehn wrote:> They make the argument that
> implicits are too complex
>
> This statement discredits itself.
>
> --
> Tony Morrishttp://tmorris.net/

--
Viktor Klang

Akka Tech LeadTypesafe - Enterprise-Grade Scala from the Experts

Twitter: @viktorklang

I had seen that Kotlin stuff too and then decided not to
post that and fire up discussion here.
Now it is done ;-)

> My initial reaction to the simplicity argument was that it was FUD -
> your Scala code can be as simple or complex as you want --

I think it is not so much about the code itsself but about the
possible features one has to learn.
Well and about the theories behind that features.
But I feel that we cannot avoid that stuff, if we want to
be future-compatible.

> that is part of Scala's nature being a "Scalable Language".
> However, a good point was made on the Kotlin wiki
> (http://confluence.jetbrains.net/display/Kotlin/Welcome?focusedCommentI
> d=40703726#comment-40703726):
>
> "When you're coming to a project of legacy code (that hundreds
> different people written several years), you [can't] ignore all of
> scala's overcomplicated features. You'll have to understand all of
> them."
>
> This is a pretty interesting argument that enterprise management types
> would find compelling.

Only if they talk only to themselves and don't consult the dev
department.

I consider that argument a FUD a lot.
And I say that sitting between the chairs, being a non-academic
framework-developer.
I.e.: I have a hard time to grok some of the advanced features
of Scala on one hand, but are confronted with the rants from people
that keep programming Java the 1.4 style, when they look at my code.

The problem arises when management decides to put some developers who
have only coded new MyClass() and if/else so far into the fw department
to "speed things up".

The topics *are* complex, and Java does not help. So one has to learn
the complex (say: bloated) code of the solutions, deeply
understand Generics (user-site), be fit in design patterns
(structural solutions for lacking language features) a.s.o.

The problem is only shifted not solved.

Kotlin may have some interesting features one can think about, and may
perhaps even influence Scala here and there.

But the Complexity argument -in the way they (re-)produce it- I do not buy!

Once they will have a fancy collection library, will have copied the
actors framework, will have reproduced some other features of Scala
or Groovy, they will get the same rant from old-style Java developers
who are facing too many new concepts at once.

> What do we do about this? For Scala to go mainstream it has to
> address the "too complex" issue. One idea is to use profiles or levels
> to tell the compiler to reject certain language features. Conservative
> development shops could turn off "dangerous" stuff in regular app code.

Not the job of the compiler. There are two solutions already available:
a) Coding guides (organisational restriction)
b) Teaching (=> no restriction necessary, gain: better developers )

I promise, if a conservative shop will restrict the features technically
(by profiles), they will chop themselves a leg of or throw them obstacles
in the way to the future.

Another way to address the problem is: Talk about your (positive) experience
with Scala. Messages like that, in private or public, will much better do
against the FUD than any technical activism.

KR
Det

On Fri, Jul 22, 2011 at 8:39 AM, Detering Dirk
wrote:
> Another way to address the problem is: Talk about your (positive) experience
> with Scala. Messages like that, in private or public, will much better do
> against the FUD than any technical activism.

+1.

And another way: Keep publishing Scala code that people want to use.
Ruby didn't become popular because of its intrinsic beauty, but people
use it because it comes with Rails. (Oldtimers may remember that
people bought Apple IIs so they could run Visicalc, the first
spreadsheet.) Get those libraries and frameworks out there, and people
will use Scala because that's what they need to use them.

Cheers,

Cay

"This statement is false" is an example of self-discrediting statement.

Thanks,
-Vlad


On Thu, Jul 21, 2011 at 11:24 PM, Tony Morris <tonymorris [at] gmail [dot] com> wrote:

On 22/07/11 16:20, rklaehn wrote:
> They make the argument that implicits are too complex
This statement discredits itself.

--
Tony Morris
http://tmorris.net/

Agreed.

The same people that complain about Scala's complexity, are the same
that
have issues dealing with advanced meta-programming concepts in dynamic
languages.

Those developer shops have to learn that people should learn how to
develop software
properly and apply proper abstraction concepts.

Having to work to an offshoring company I got to learn that many of
these complains come
from people that like offshoring friendly languages. Where you can
replace resources (what
a name for persons) at the whim of project status without having to
look for "experts".

--
Paulo

On 23 Jul., 00:38, Cay Horstmann wrote:
> On Fri, Jul 22, 2011 at 8:39 AM, Detering Dirk
>
> wrote:
> > Another way to address the problem is: Talk about your (positive) experience
> > with Scala. Messages like that, in private or public, will much better do
> > against the FUD than any technical activism.
>
> +1.
>
> And another way: Keep publishing Scala code that people want to use.
> Ruby didn't become popular because of its intrinsic beauty, but people
> use it because it comes with Rails. (Oldtimers may remember that
> people bought Apple IIs so they could run Visicalc, the first
> spreadsheet.) Get those libraries and frameworks out there, and people
> will use Scala because that's what they need to use them.
>
> Cheers,
>
> Cay

I've met Scala newbies coming from Java, PHP, Groovy, and Ruby. They seem to appreciate Scala simplicity and its aptitude for application to a broader solution set. As announced in an earlier post, I'm putting together a ~6 person Scala team for a multi-year initiative. Skill to design libraries and frameworks takes longer, but a developer new to Scala can start writing acceptable code in a few days. So I'm fine with them learning Scala on-the-fly if necessary.

Most of the complexity I have found (in any language) is when I wasn't up to speed on the concept--not the language. Understand the concepts that Scala supports and the language flows well. So what's the top 10 list for those that struggle with Scala the language, but not the concepts?

Erik

On Jul 23, 2011, at 11:53 AM, Paulo Pinto wrote:

> Agreed.
>
> The same people that complain about Scala's complexity, are the same
> that
> have issues dealing with advanced meta-programming concepts in dynamic
> languages.
>
> Those developer shops have to learn that people should learn how to
> develop software
> properly and apply proper abstraction concepts.
>
> Having to work to an offshoring company I got to learn that many of
> these complains come
> from people that like offshoring friendly languages. Where you can
> replace resources (what
> a name for persons) at the whim of project status without having to
> look for "experts".
>
> --
> Paulo
>
> On 23 Jul., 00:38, Cay Horstmann wrote:
>> On Fri, Jul 22, 2011 at 8:39 AM, Detering Dirk
>>
>> wrote:
>>> Another way to address the problem is: Talk about your (positive) experience
>>> with Scala. Messages like that, in private or public, will much better do
>>> against the FUD than any technical activism.
>>
>> +1.
>>
>> And another way: Keep publishing Scala code that people want to use.
>> Ruby didn't become popular because of its intrinsic beauty, but people
>> use it because it comes with Rails. (Oldtimers may remember that
>> people bought Apple IIs so they could run Visicalc, the first
>> spreadsheet.) Get those libraries and frameworks out there, and people
>> will use Scala because that's what they need to use them.
>>
>> Cheers,
>>
>> Cay

I don't find the argument very compelling. In general, new programmers dealing with legacy code have to deal with a significant learning curve. That's true in any environment, with any programming language. That learning curve is also very different for each type of company as it involves various toolkits and in particular in house toolkits that a programmer cannot learn anywhere but on the job. I don't see how scala makes this worse.

However, I do see a way in which scala can make this significantly better - the ability to create scale the language to create domain specific language capabilities. When done well it can result in code that is vastly more readable and can reduce the learning curve. Think of Behavior Driven Development scripts using specs or ScalaTest as an example of this. I imagine that many business domains could benefit from customized language features.

A counter argument could be made that even though scala can be used in a way that improves readability and minimizes the learning curve, the possiblity is still there to venture out into the wild west and create code that will then be much harder to maintain. I find this true of any programming environment though. They all build up cruft and they all have the potential for unreadable code. I think a certain amount of developer discipline along with a well defined business processes (including code reviews and change control for example) are the only solution for this.

So in short, I think the flexibility of scala is a big selling point. It can result in greater complexity, but it doesn't have to.

I disagree almost completely with the whole idea of DSLs. It makes sense to create a DSL _only_ if the language you create is so much better at solving problems in that domain that it overcomes the cost of engineers needing to learn yet another piece of highly specialized knowledge that is, in the case of DSLs, probably of very limited use. I for one don't find BDD tests any more useful that asserts; in fact, I find them kind of COBOLish in their desire to read like English language.
There are places where DSLs are appropriate. Parser combinators, the example from Programming in Scala, are a good example. But Ruby is one language you can really twist into odd shapes, and I for one decided I had no patience with the games people were playing with Ruby. I'd much rather have had code that had 30% more lines, but was standard usage.
Scala is unfortunately given to this type of experimentation, and I've already seen too much of it--the guilty libraries will remain unnamed. However, at the very least--for goodness' sakes, if an operator doesn't have an obvious or easily-rationalized meaning, don't use it! Define a named method instead. We live in the era of IDEs with autocomplete, and should all be aware that code maintenance is much more expensive than code production.
Praeus, this wasn't necessarily aimed at you, I just get annoyed with fads in CS (I've been around long enough to have seen a lot of them), and I think DSLs are mostly (not completely) another fad.
Cheers,Ken

On Saturday, July 23, 2011 8:27:13 PM UTC-5, eptx wrote:

I've met Scala newbies coming from Java, PHP, Groovy, and Ruby. They seem to appreciate Scala simplicity and its aptitude for application to a broader solution set. As announced in an earlier post, I'm putting together a ~6 person Scala team for a multi-year initiative. Skill to design libraries and frameworks takes longer, but a developer new to Scala can start writing acceptable code in a few days. So I'm fine with them learning Scala on-the-fly if necessary.

Most of the complexity I have found (in any language) is when I wasn't up to speed on the concept--not the language. Understand the concepts that Scala supports and the language flows well. So what's the top 10 list for those that struggle with Scala the language, but not the concepts?

Erik

On Jul 23, 2011, at 11:53 AM, Paulo Pinto wrote:

> Agreed.
>
> The same people that complain about Scala's complexity, are the same
> that
> have issues dealing with advanced meta-programming concepts in dynamic
> languages.
>

I think it's pretty easy to learn to program Scala to the level of Java, and just by doing so, one does get a significant productivity boost. (Assuming the IDEs can come up to speed...) But at some point things like implicit arguments and the type system start coming into play, and those _are_ quite difficult to learn.
I'd disagree about the comment that people who have problems with Scala's advanced features also have problems with advanced features in dynamic languages. Python is dead simply compared to Scala. If you want to get complex, you have to get into Python metaprogramming, which isn't intended for general use--while Scala's advanced features are. And even there, Python's metaprogramming is still simpler than the complex Scala stuff.
Ken

Scala is deep deep language, it is easy to get drowned once you reach a particular. The community is helpful. But I believe more is needed.

concepts like manifest, package object, delimited continuation, compiler plugin, linear types(capabilities), monads are important and but there is a need for tutorials (pragmatic one).

Some these features/concepts have deep computer science baggage that com with them(eg monads).

These are things that may make scala seem "complicated", but they are not. However, once you learn them, you can program in any language that have them, scala I believe promotes also the learning of concepts, another language that does that on the jvm is clojure.


Kotlin took a more pragmatic root meaning fewer features, more verbose,more java like IDE support and less computer science to absorbed. This may make it a good competitor. Also, it support for reified generics,exension methods, implicit nullable type ala c#   has also decrease some of its complexity. But how would it fair on the long run when new features will be added, will it be as awful as java generics.

Kotlin is not proven yet, scala is.

scala new features did not break the language, only binary compatibility.

Also it is a community that really put a language to the test, scala is well poised on many levels to be a language of choice for the jvm/clr. It is just as mentioned earlier by Ken mcDonald some library makes scala unreadable, even disgusting, I personally avoid those.

One flaw that appears a lot in those libary :-
Operator as a method is great, it is like a good spice, but too much of it, makes you sick.
Overusing implicits.

I believe we will see other static languages and functional, and they will target scala as their primary target to say how great their language is and point out flaws in scala.

All in all, I believe it is a community that  drives the language, example perl is awful, but for decades may be still now it was a great language for many.

That is my 2 cents on the matter.

On Fri, Jul 29, 2011 at 2:29 AM, Ken McDonald <ykkenmcd [at] gmail [dot] com> wrote:

I disagree almost completely with the whole idea of DSLs. It makes sense to create a DSL _only_ if the language you create is so much better at solving problems in that domain that it overcomes the cost of engineers needing to learn yet another piece of highly specialized knowledge that is, in the case of DSLs, probably of very limited use. I for one don't find BDD tests any more useful that asserts; in fact, I find them kind of COBOLish in their desire to read like English language.
There are places where DSLs are appropriate. Parser combinators, the example from Programming in Scala, are a good example. But Ruby is one language you can really twist into odd shapes, and I for one decided I had no patience with the games people were playing with Ruby. I'd much rather have had code that had 30% more lines, but was standard usage.
Scala is unfortunately given to this type of experimentation, and I've already seen too much of it--the guilty libraries will remain unnamed. However, at the very least--for goodness' sakes, if an operator doesn't have an obvious or easily-rationalized meaning, don't use it! Define a named method instead. We live in the era of IDEs with autocomplete, and should all be aware that code maintenance is much more expensive than code production.
Praeus, this wasn't necessarily aimed at you, I just get annoyed with fads in CS (I've been around long enough to have seen a lot of them), and I think DSLs are mostly (not completely) another fad.
Cheers,Ken

On Thu, Jul 28, 2011 at 3:35 PM, Ken McDonald wrote:
> Python is dead simply compared to Scala. If you want to get
> complex, you have to get into Python metaprogramming, which isn't intended
> for general use--while Scala's advanced features are. And even there,
> Python's metaprogramming is still simpler than the complex Scala stuff.
> Ken

Python metaprogramming may well be simple--I haven't looked at it. But
Ruby metaprogramming is not simple at all, and people still think Ruby
is simple.

When I bring this up with Ruby programmers, they tell me cheerfully
that they don't care. They never do any metaprogramming--that's left
to a few wizards. And in Java--how many people write generic methods
with wildcards?

Why would it be any different in Scala? There is no good reason for
Joe Programmer to write their own implicits, or their own
parameterized methods. That's why Martin talks about Scala levels. You
can be happy and productive at Martin's level A2. You use objects and
some functional idioms, exactly like a Python programmer would.

Cheers,

Cay

Cay Horstmann wrote:
> On Thu, Jul 28, 2011 at 3:35 PM, Ken McDonald wrote:
>> Python is dead simply compared to Scala. If you want to get
>> complex, you have to get into Python metaprogramming, which isn't intended
>> for general use--while Scala's advanced features are. And even there,
>> Python's metaprogramming is still simpler than the complex Scala stuff.
>> Ken
> Python metaprogramming may well be simple--I haven't looked at it. But
> Ruby metaprogramming is not simple at all, and people still think Ruby
> is simple.
>
> When I bring this up with Ruby programmers, they tell me cheerfully
> that they don't care. They never do any metaprogramming--that's left
> to a few wizards. And in Java--how many people write generic methods
> with wildcards?
>
> Why would it be any different in Scala? There is no good reason for
> Joe Programmer to write their own implicits, or their own
> parameterized methods. That's why Martin talks about Scala levels. You
> can be happy and productive at Martin's level A2. You use objects and
> some functional idioms, exactly like a Python programmer would.
The main difference I think is when a programmer meets the complex
features of the language. With Ruby, a new programmer first encounters
the cool and easy features. Only later, if he wants to, he learns
metaprogramming. In Scala, these are in-your-face from the start (e.g.,
the scala tour). I think that the Scala documentation (not just
scaladoc, but the scala tour, examples etc.) should focus more on how to
program java-like, but with less lines of code, and leave the more
complex features "hidden", so only those already proficient with Scala
will find them.

Ittay
>
> Cheers,
>
> Cay

On 07/29/2011 12:29 AM, Ken McDonald wrote:
> I disagree almost completely with the whole idea of DSLs. It makes
> sense to create a DSL _only_ if the language you create is so much
> better at solving problems in that domain that it overcomes the cost
> of engineers needing to learn yet another piece of highly specialized
> knowledge that is, in the case of DSLs, probably of very limited use.
> I for one don't find BDD tests any more useful that asserts; in fact,
> I find them kind of COBOLish in their desire to read like English
> language.
>
> There are places where DSLs are appropriate. Parser combinators, the
> example from Programming in Scala, are a good example. But Ruby is one
> language you can really twist into odd shapes, and I for one decided I
> had no patience with the games people were playing with Ruby. I'd much
> rather have had code that had 30% more lines, but was standard usage.
>
> Scala is unfortunately given to this type of experimentation, and I've
> already seen too much of it--the guilty libraries will remain unnamed.
> However, at the very least--for goodness' sakes, if an operator
> doesn't have an obvious or easily-rationalized meaning, don't use it!
> Define a named method instead. We live in the era of IDEs with
> autocomplete, and should all be aware that code maintenance is much
> more expensive than code production.
>
> Praeus, this wasn't necessarily aimed at you, I just get annoyed with
> fads in CS (I've been around long enough to have seen a lot of them),
> and I think DSLs are mostly (not completely) another fad.

+1, especially "code maintenance is much more expensive than code
production". Seems people tend to forget or overlook this one. That's my
nr. 1 argument for using a type-safe language like Scala (and Lift
instead of reflection-based frameworks).

On Thursday 28 July 2011, Ken McDonald wrote:
> ...
>
> Praeus, this wasn't necessarily aimed at you, I just get annoyed with
> fads in CS (I've been around long enough to have seen a lot of them),
> and I think DSLs are mostly (not completely) another fad.

To be a fad, they'd have to be far younger than they are. That which is
today referred to as a DSL went by other names in the past and go back
at least 35 years.

> Cheers,
> Ken

Randall Schulz

On Fri, Jul 29, 2011 at 9:38 PM, Randall R Schulz wrote:
> On Thursday 28 July 2011, Ken McDonald wrote:
>> ...
>>
>> Praeus, this wasn't necessarily aimed at you, I just get annoyed with
>> fads in CS (I've been around long enough to have seen a lot of them),
>> and I think DSLs are mostly (not completely) another fad.
>
> To be a fad, they'd have to be far younger than they are. That which is
> today referred to as a DSL went by other names in the past and go back
> at least 35 years.

Yup. Why do you think there is that saying about every program of a
sufficient size containing an ad-hoc, poorly specified, buggy
implementation of half of Common Lisp? Giving an old concept a
3-letter acronym doesn't make it a new concept.

Kris

 Giving an old concept a
3-letter acronym doesn't make it a new concept.

Kris

No, but it often means it's become a fad :-)
Ken 

35... as I understand Forth was invented to make it easy to implement dsls, and it was something like 7 years earlier (and 42 is also a good round number).

Thanks,
-Vlad


On Fri, Jul 29, 2011 at 8:38 PM, Randall R Schulz <rschulz [at] sonic [dot] net> wrote:

On Thursday 28 July 2011, Ken McDonald wrote:
> ...
>
> Praeus, this wasn't necessarily aimed at you, I just get annoyed with
> fads in CS (I've been around long enough to have seen a lot of them),
> and I think DSLs are mostly (not completely) another fad.

To be a fad, they'd have to be far younger than they are. That which is
today referred to as a DSL went by other names in the past and go back
at least 35 years.


> Cheers,
> Ken


Randall Schulz

On Sat, Jul 30, 2011 at 16:50, Vlad Patryshev wrote:
> 35... as I understand Forth was invented to make it easy to implement dsls,
> and it was something like 7 years earlier (and 42 is also a good round
> number).

Both Forth and Lisp -- the second oldest high level language, older
even than COBOL -- are programmed in by writing successive layers of
DSLs.