Complexity of Scala versus Kotlin/Ceylon
Eric Pederson
-- Eric
Brian Maso
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
Best regards,
Brian Maso
(949) 395-8551
Follow me: @bmaso
br...@blumenfeld-maso.com
Naftoli Gugenheim
Tony Morris
On 22/07/11 13:39, 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=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
Rex Kerr
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
Jim Balter
> 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
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.
-- Jim
Vlad Patryshev
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
Bernd Johannes
[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
rklaehn
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...@gmail.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
> ):
Tony Morris
> They make the argument that implicits are too complex
Naftoli Gugenheim
Rüdiger Klaehn
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<Int> from a java.util.List<String> 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...
Jim Balter
> 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=40703732#comment-40703732
Andrey Breslav: "There will be a collection library in Kotlin standard
library. The exact design is not fixed yet."
Xuefeng Wu
Francois
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.
--
Francois ARMAND
http://fanf42.blogspot.com
http://www.normation.com
Xuefeng Wu
Martin Grigorov
Nice explanation! :-)
Sébastien Bocq
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.
--
Sébastien
Philippe Lhoste
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.
--
Philippe Lhoste
-- (near) Paris -- France
-- http://Phi.Lho.free.fr
-- -- -- -- -- -- -- -- -- -- -- -- -- --
Daniel Dekany
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.
--
Best regards,
Daniel Dekany
Paulo Pinto
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
Nation, Carey
√iktor Ҡlang
Computing is different because you never see _Brain Surgery for Dummies_
--
Viktor Klang
Akka Tech Lead
Detering Dirk
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
Cay Horstmann
<Dirk.D...@bitmarck.de> 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
Vlad Patryshev
Thanks,
-Vlad
Paulo Pinto
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 <cay.horstm...@gmail.com> wrote:
> On Fri, Jul 22, 2011 at 8:39 AM, Detering Dirk
>
coach3pete
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
Chad Salamon
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.
Ken McDonald
Ken McDonald
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.
>
Renghen Renghen
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.
Cay Horstmann
> 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
Ittay Dror
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
Detering Dirk
> I'd disagree about the comment that people who have problems with
> Scala's advanced features also have problems with advanced features in
This is IMHO an unfair statement, as in that comparision so far you compare
Scala's advanced(!) features with (standard) Python. But ...
> 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.
AFAIC there is
1.) a mismatch about when the 'advanced' features begin and the
'standard' level ends.
2.) a documented intention about the feature set, which does not
really back up your statement: http://www.scala-lang.org/node/8610
The differentiation between application programmer and
library designer alone is just contradicting your statement that
Scala's advanced features are intended for general use.
> And even there, Python's metaprogramming is still simpler than the
> complex Scala stuff.
of what exactly the problematic things are, this is a worthless debate.
And:
! ( dynamic languages == Python)
Python's metaprogramming may even be as simple in it's technique as
Scala's most often critized advanced features.
But it is as well confusing in an application when one is not trained
to think in meta-levels and it's correct application and is easily
scared by what's going on with the classes and objects at runtime:
Suddenly appearing methods (true reflection), changing scope ('delegate'
and other Builder stuff), or magic behaviour (missing method).
And e.g. delimited continuations exist in Ruby too, and are not
used or even understood by the ordinary programmer, and therefore
not needed by them. Same is true with Scala's delimited continuations.
It is not the language, it's the concept!
The people I would keep Scala's advanced features away from are the
same I would not put into framework development or codegenerator
maintenance with Java or even Python. They would shoot in the foot,
not only of themselves but also of their users.
"Scala is complex" _is_ FUD.
"Scala has very advanced features" is true.
"Scala provides concepts I had never before contact with" may be surely
true for many of us, but what the set of these concepts is depends on
the individual developer.
My 2ct
Det
Andreas Joseph Krogh
+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).
--
Andreas Joseph Krogh <and...@officenet.no>
Senior Software Developer / CTO
Public key: http://home.officenet.no/~andreak/public_key.asc
------------------------+---------------------------------------------+
OfficeNet AS | The most difficult thing in the world is to |
Rosenholmveien 25 | know how to do a thing and to watch |
1414 Troll�sen | somebody else doing it wrong, without |
NORWAY | comment. |
Org.nr: NO 981 479 076 | |
| |
Tlf: +47 24 15 38 90 | |
Fax: +47 24 15 38 91 | |
Mobile: +47 909 56 963 | |
------------------------+---------------------------------------------+
Randall R Schulz
> ...
>
> 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
