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

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 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.