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

I am in the midst of studying OCaml in case it should be a preferred 
language choice for the project I am currently launching. The curiosity is 
unbearable.

First gripe (and attempting to make the first case of justification for my 
allegation of "fugly syntax") is I want to know how many in the Scala 
community agree or disagree with my preference for parens around function 
operands (a.k.a. parameters or arguments)? Those coming from the C, C++, 
and Java background do not usually like the FP preference of just using 
spaces. My justification on top of that legacy, popularity point is that 
without parens, you must visit the function declaration site before you can 
read the function use site. For someone unfamiliar trying to read code, 
this places a burden of "all or nothing" knowledge of the source code, 
which is highly inefficient and not in the spirit of separation-of-concerns 
and single-point-of-truth. The only place where I think spaces should be 
allowed are for infix operators (even those which are keywords instead of 
symbols), i.e. those in which there is an operand on each side of the 
operator, and those unary (post or prefix) operators which are symbols (and 
in that case there should be no spaces between the operand and operator, 
use parens if you need to juxtapose unary operators). These are the sort of 
rules that I would like to see so there is consistency to Scala code 
because given open source "the #1 priority of any programming language bar 
none, is readability"— Eric S. Raymond the progenitor of the term "open 
source":

http://jobtipsforgeeks.com/2012/05/17/lessons-from-a-jug-talk-with-eric-esr-raymond/

So that is one way Scala can differentiate itself from other purest, 
snobbish FP languages and be more friendly to those coming from mainstream 
backgrounds.

Feedback?


On Sunday, August 23, 2015 at 1:33:47 AM UTC+8, Shelby wrote:
>
> Thanks I'll try to look at that. I don't know ML well and struggle with 
> its syntax so it will slow me down, but I should see if that does already 
> provide the functionality. Necessary of course for writing a white paper 
> and citing prior art.
>
> Even then there are other variables at play such as:
>
> * tool support
> * JVM interopt
> * JS compilation (I must have this!)
> * fugly syntax of OCaml (imo)
> * community
> * momentum
>
> I believe Scala heads can be convinced subclassing is an anti-pattern but 
> even if not, it appears Scala is headed towards being a modular platform 
> for language experimentation with the move towards a TASTY layer.
>
> I sense that Scala will be the place where there economies-of-scale form. 
> Maybe not. Need to consider a lot of details and I am 1000 miles up in the 
> air right now due to other priorities.
>
>
> On Saturday, August 22, 2015 at 6:43:53 PM UTC+8, Bardur Arantsson wrote:
>>
>> On 08/22/2015 03:05 AM, Shelby wrote: 
>> > I agreed with all the range of discussion at the following HN thread. 
>> In 
>> > particular, I want to call attention to the following post which 
>> emphasizes 
>> > that Scala is not sufficiently simplified and unified. Scala 3 with the 
>> DOT 
>> > (Dotty) proposal is attempting to make some headway, and my position is 
>> to 
>> > try to remove subclassing (retain subtyping) and replace with a 
>> superior 
>> > paradigm which is more unified, which will make the calculus more 
>> provable, 
>> > will make type inference more simplifed and complete, and will remove 
>> the 
>> > CAKE pattern and other warts which are giving Scala a bad rap while 
>> also 
>> > slam dunking it to massive adoption... 
>> > 
>>
>> I think you're tilting at windmills. As I understand it, part of the 
>> raison d'être of Scala is that it is a research vehicle[1] and that "how 
>> to do subclassing right" is/was a big part of that research. Instead of 
>> tilting, perhaps you should look into some of the more... ahem... 
>> polished functional languages? Like O'Caml or Haskell? 
>>
>> For example, it seems that much of what you want is already provided by 
>> the row polymorphism support in O'Caml...? (Btw, O'Caml also has an 
>> object system which is structural, i.e. non-nominal, but ironically -- 
>> given the name of the language -- almost nobody used it last I heard... 
>> which was quite a long while ago, admittedly.) 
>>
>> Regards, 
>>
>> [1] Well, at least it started out that way. I guess things might have 
>> changed? 
>>
>>

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