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

Appears to be about 2.5% of Java's popularity. And the retort I get is that 
most developers will leave immediately after seeing you've chosen Scala.

I retorted that choosing Scala is choosing a culture that prioritizes 
modularity and separation-of-concerns over monkey patching. And thus a 
useful filter.

But he has a point. He is expert in Java and I can't find a Scala 
programmer to help me. And he is available and motivated to code in Java, 
but not in Scala.

I read articles that say it is very difficult to find a Scala programmer, 
because they are in such high demand and already have interesting projects 
they are working on. Hey I am just a geek, not a human resources manager.

On Saturday, August 22, 2015 at 6:08:54 AM UTC+8, nafg wrote:
>
>
> On Fri, Aug 21, 2015, 5:03 PM Shelby <[email protected] <javascript:>> 
> 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] <javascript:>.
> 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.