Re: [scala-language] The cake’s problem, dotty des ign and the approach to modularity.

On Fri, Aug 21, 2015, 5:03 PM Shelby <[email protected]> wrote:

I have two reasons to sort of break my implied promise in my prior message
that I would come back when organized.

1. I have been in an ongoing discussion with a senior software developer as
follows below, who is an expert Java programmer, who favors Lisp as his
favorite language, and who a polygot in computer languages. So the
following summary may need to be revised on further clarifications from
that person. But I think it will remain true that it serves as a poignant
insight into why Scala can never become a mainstream

language

Wait, it hasn't already?

UNLESS IT MAKES THE ARGUMENT ABOUT STATIC TYPING LESS SUBJECTIVE. I think
if we show that subclassing can be replaced with a compiler assisted
inversion-of-control for a complete solution to Wadler's Expression
Problem, such that we hardly never need to refactor and recompile again,
modules get smaller and more orthogonal, and much of the tsuris of
programming falls away, then we can finally slam dunk the Steve Yeggies of
this world. Of course dynamically (uni-)typed languages will always have a
role to play. The point is to attempt to elucidate clear victories for
expressive typing that are not as nebulous as arguments up to now. Many
programmers do not internalize the fact that the semantics of code always
have types, but if your compiler can't express these types then you cast
them away and instead model your invariants with comments, in your head,
and regression testing. But regression testing tests effects, not
invariants. In the Scala Days 2015 presentation, Martin Odersky attempted
to make this point in slide 10 (link below), but I think the point needs to
be made more emphatically that expressive type systems are about capturing
the types that are already in your program. Wadler made the point when
distinguishing between S-modularity and I-modularity in the following
linked blog comment (note it immediately followed my comment):

http://www.slideshare.net/Odersky/scala-days-san-francisco-45917092

http://gbracha.blogspot.com/2011/06/types-are-anti-modular.html?showComment=1312367864429#c8055471612448657189

2. Help! I know we aren't supposed to advertize jobs on the mailing lists
but I can't operate through normal job finding avenues because the
controlling group and investors in the project I refer to are anonymous
thus only pay in Bitcoin (job sites do not accept Bitcoin and anonymous
employers even to get started). I am very handicapped in trying to make
Scala the reality for this coin. I wish I could find a Scala developer
interested in helping me make sure a radically innovative altcoin has a
Scala ecosystem and not Java or C. It could be a major win for Scala
because it could spawn many network effects Scala projects. I am available
via private message on the Bitcointalk forum. Also the profit potential is
unfathomably large (as is the risk of failure). I suggest going to the
linked posts below and reviewing the description of advantages over Bitcoin.

https://bitcointalk.org/index.php?topic=1049048.msg12127776#msg12127776

https://bitcointalk.org/index.php?topic=1049048.msg12175683#msg12175683

https://bitcointalk.org/index.php?topic=1049048.msg12180439#msg12180439

https://bitcointalk.org/index.php?topic=1082909.msg12173116#msg12173116

https://bitcointalk.org/index.php?topic=1049048.msg12200924#msg12200924
 (the post quote below)

[quote=myself a.k.a. TPTB_need_war]

In other news, a very prominent member of these forums who claims he is a
world-class programmer has expressed strong interest in partnering with me
to help me get this implemented faster (which I very much appreciate). We
are in discussions, but this may or may not work out because we have a
(slight or significant?) difference of opinion on the preferred computer
language and potentially his cash compensation opportunity cost may be too
high (or maybe not, as I haven't seen his figures yet). And there is
unclear communication (so far) about the importance of modularity. As best
as I can determine thus far, he prioritizes very much speed of
implementation at the cost of expressive type systems that [i]some
claim[/i] (which he may have a right to doubt and others do doubt) can
capture modularity in a way that eliminates much of the [url=
http://accu.org/content/conf2009/ACCU2009_Bernhard_Merkle_StopTheSoftwareArchitectureErosion.pdf#page=17]metastasizing
spaghetti code[/url] because he said for as long it is all open source, his
point is you can always refactor and recompile. Whereas, I believe
modularity is a paramount priority and that one can be just as productive
by following "best coding practices" (and that is a subjective phrase to
some extent so my "best" could be argued as not "best" by others). As far
as I can grasp so far, this person claims all that theoretical computer
science doesn't matter that much (or slows us down when it is not yet a
mainstream language or most other programmers won't take to it) and he
claims he is very productive regardless. I have no doubt he is productive
in the short-run, but I am concerned about [url=
http://accu.org/content/conf2009/ACCU2009_Bernhard_Merkle_StopTheSoftwareArchitectureErosion.pdf#page=17]metastasizing
tightly coupled spaghetti over the long-term[/url] as a project becomes
more ingrained and complex. His perspective is not without merit but it is
the sort of comment you hear from folks who are trying to justify why
dynamically typed languages should be used every where, e.g. [url=
http://steve-yegge.blogspot.com/2008/06/rhinos-and-tigers.html]Steve
Yeggie[/url] and even the [url=
http://jobtipsforgeeks.com/2012/05/17/lessons-from-a-jug-talk-with-eric-esr-raymond/]progenitor
of the term "open source" the 150+ IQ genius Eric S. Raymond[/url]. And
although it is a reasonable point to balance, it is not an absolute truth
and there are good reasons sometimes to think the other way. Most
programmers can do more damage to your project than you initially realize
(although I suspect that doesn't apply to the programmer I am referring to
above). However criticizing myself, one has to be pragmatic and accept that
the productivity of even sufficiently large numbers of monkeys (not the
programmer referred to above) banging randomly on source code can find (and
[url=
http://www.technologyreview.com/news/506466/given-tablets-but-no-teachers-ethiopian-children-teach-themselves/]even
fix[/url]!) more bugs than one guy lonesome.

[url=
http://accu.org/content/conf2009/ACCU2009_Bernhard_Merkle_StopTheSoftwareArchitectureErosion.pdf#page=17][img
width=480]http://i61.tinypic.com/6gbngh.png[/img][/url] <-  metastasizing
tightly coupled spaghetti over the long-term

[/quote]

Slightly edited salient portion of my prior message follows...

On Friday, August 21, 2015 at 3:42:31 AM UTC+8, Shelby wrote:

... because I am concerned that DOT and Dotty need some radical tweak yet
before we go that direction. All the progress is great, but I think by not
discarding subclassing and replacing it with my proposal for compiler
assisted inversion-of-control (assuming it can't be otherwise unified from
some other perspective such as category theory), then we will have lost a
critical opportunity to be the next mainstream language that overtakes Java
finally.


I recently watched the video of Martin's presentation from Scaladays 2015
and I really love the TASTY direction to modularize orthogonal compilation
layers. Kudos!


And I love the conceptual idea of simplification via unification (paradigm
shift) in DOT. I just think we will miss a huge opportunity if we don't
deprecate subclassing for Scala 3. If we look at the popular languages, it
is Java #1 but on a steady decline (perhaps Android and Java 8 staved off a
free fall for a short while) and all these FP languages as nipping at its
heels, e.g. Scala, Clojure, Python, etc..


Scala needs to be cleaned up and even less verbose. Eliminating subclassing
can enable the DOT calculus to become much simpler and also enable more
opportunities to infer types to reduce verbosity.

IMO what has prevented an FP language from overtaking Java is the lack of
mainstream need for any particular feature of FP, as well as it being
presented a bit too obtusely. Scala made some leaps forward on being less
obtuse because it looks more like a familiar OOP language, eager evaluation
by default, non-total by default, etc.. But the most salient point IMHO, is
there is no requirement to use typing in programming. People can make
arguments either for and against static typing.


But I think I have shown (and I understand I need to organize my
presentation and thoughts soon) that no one can get fine grained
extensibility (that is without refactoring and recompilation) without my
idea for inversion-of-control which requires the sophisticated and unified
typing of DOT (sans the subclassing).


-- 
You received this message because you are subscribed to the Google Groups
"scala-language" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to [email protected].
For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups "scala-language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/d/optout.