Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #37452 > unrolled thread

underscore as keyword in Java 9

Back to article view | Back to comp.lang.java.programmer

Contents

  underscore as keyword in Java 9 Andreas Leitgeb <avl@logic.at> - 2017-09-23 11:58 +0000
    Re: underscore as keyword in Java 9 j4n bur53 <janburse@fastmail.fm> - 2017-09-23 18:46 +0200
      Re: underscore as keyword in Java 9 Arne Vajhøj <arne@vajhoej.dk> - 2017-09-23 21:01 -0400
        Re: underscore as keyword in Java 9 Andreas Leitgeb <avl@logic.at> - 2017-09-24 11:25 +0000
          Re: underscore as keyword in Java 9 j4n bur53 <janburse@fastmail.fm> - 2017-09-24 17:30 +0200
          Re: underscore as keyword in Java 9 Arne Vajhøj <arne@vajhoej.dk> - 2017-09-24 18:24 -0400
            Re: underscore as keyword in Java 9 Andreas Leitgeb <avl@logic.at> - 2017-09-24 23:27 +0000
              Re: underscore as keyword in Java 9 Arne Vajhøj <arne@vajhoej.dk> - 2017-09-24 21:10 -0400
                Re: underscore as keyword in Java 9 Andreas Leitgeb <avl@logic.at> - 2017-09-25 13:30 +0000
      Re: underscore as keyword in Java 9 Eric Douglas <e.d.programmer@gmail.com> - 2017-09-25 08:07 -0700
        Re: underscore as keyword in Java 9 lewbloch@gmail.com - 2017-09-25 13:21 -0700
        Re: underscore as keyword in Java 9 Silvio <silvio@internet.com> - 2017-09-25 23:30 +0200
          Re: underscore as keyword in Java 9 Arne Vajhøj <arne@vajhoej.dk> - 2017-09-25 20:24 -0400
            Re: underscore as keyword in Java 9 j4n bur53 <janburse@fastmail.fm> - 2017-09-26 13:37 +0200
            Re: underscore as keyword in Java 9 Silvio <silvio@internet.com> - 2017-09-27 19:05 +0200
              Re: underscore as keyword in Java 9 Eric Douglas <e.d.programmer@gmail.com> - 2017-09-27 10:25 -0700
                Re: underscore as keyword in Java 9 Silvio <silvio@internet.com> - 2017-09-27 23:02 +0200
              Re: underscore as keyword in Java 9 Arne Vajhøj <arne@vajhoej.dk> - 2017-09-27 20:02 -0400
                Re: underscore as keyword in Java 9 Eric Douglas <e.d.programmer@gmail.com> - 2017-09-28 05:11 -0700
                  Re: underscore as keyword in Java 9 Arne Vajhøj <arne@vajhoej.dk> - 2017-09-28 20:42 -0400
            Re: underscore as keyword in Java 9 Sebastian <nowhere@nirvana.org> - 2017-09-27 20:26 +0200
              Re: underscore as keyword in Java 9 Silvio <silvio@internet.com> - 2017-09-27 23:10 +0200
          Re: underscore as keyword in Java 9 Andreas Leitgeb <avl@logic.at> - 2017-09-26 08:29 +0000
            Re: underscore as keyword in Java 9 Silvio <silvio@internet.com> - 2017-09-27 19:08 +0200
            Re: underscore as keyword in Java 9 Sebastian <nowhere@nirvana.org> - 2017-09-27 21:46 +0200
    Re: underscore as keyword in Java 9 Eric Douglas <e.d.programmer@gmail.com> - 2017-09-27 06:53 -0700
      Re: underscore as keyword in Java 9 Andreas Leitgeb <avl@logic.at> - 2017-09-27 15:59 +0000
        Re: underscore as keyword in Java 9 Arne Vajhøj <arne@vajhoej.dk> - 2017-09-27 19:18 -0400
          Re: underscore as keyword in Java 9 Daniele Futtorovic <da.futt.news@laposte.net> - 2017-09-28 11:41 +0200

Page 1 of 2  [1] 2  Next page →

#37452 — underscore as keyword in Java 9

When googling for underscore keyword I found a mail by Brian Goetz, where
he hinted for a future use of the "_" keyword:

  http://mail.openjdk.java.net/pipermail/lambda-dev/2013-July/010670.html

" However, things it might be used for include things like "I don't want
" to give this variable a name" (such as catch parameters that are never
" used.)

Now, some people might already have used that identifier in exactly such
circumstances, namely for variable names that need to be there
syntactically, but are not intended to be used.

It strikes me odd, that Java would first forbid them generally, only to 
later essentially encourage that particular use again.

Maybe, if that was the intention already 4 years ago, they should only 
have made uses of "_" as values (lvalue or rvalue) illegal.

Comments?  Maybe there have risen newer intentions for different uses
in the meantime?

[toc] | [next] | [standalone]

#37454

As long as Java doesn't have multi-returns, there
will be not many use cases. For multi returns, if
they were in the Java language, it could be offered
as in the Go Programming Language:

/* fetching the y coordinate of a 3D point */
_, y, _ := coord(p)
https://stackoverflow.com/questions/27764421/what-is-in-a-golang-declaration

Which reminds me of the Prolog language so called
annonymous variables:

   ?- .., coord(P,_,Y,_).

Andreas Leitgeb schrieb:
> When googling for underscore keyword I found a
> mail by Brian Goetz, where he hinted for a future
> use of the "_" keyword:
>
>   http://mail.openjdk.java.net/pipermail/lambda-dev/2013-July/010670.html

[toc] | [prev] | [next] | [standalone]

#37455

On 9/23/2017 12:46 PM, j4n bur53 wrote:
> As long as Java doesn't have multi-returns, there
> will be not many use cases. For multi returns, if
> they were in the Java language, it could be offered
> as in the Go Programming Language:
> 
> /* fetching the y coordinate of a 3D point */
> _, y, _ := coord(p)

I suspect that Java will get that in version 10 or 11.

Reason: C# got it in version 7 (and Java and C# tend
to steal ideas from each other).

Syntax like:

(int v1,int v2) = M();

Arne

[toc] | [prev] | [next] | [standalone]

#37457

Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 9/23/2017 12:46 PM, j4n bur53 wrote:
>> As long as Java doesn't have multi-returns, there
>> will be not many use cases. For multi returns, if
>> they were in the Java language, it could be offered
>> as in the Go Programming Language:
>> /* fetching the y coordinate of a 3D point */
>> _, y, _ := coord(p)
> I suspect that Java will get that in version 10 or 11.
> Reason: C# got it in version 7 (and Java and C# tend
> to steal ideas from each other).
> Syntax like:
> (int v1,int v2) = M();

These speculations are entirely orthogonal to the point that "_"
is taken away from the realm of identifiers, but might in future
be used syntactically like throw-away identifiers - A use they
sometimes already have - and this particular use is now being
forbidden just before likely being re-enabled.

[toc] | [prev] | [next] | [standalone]

#37458

Yeah, somehow it would work if a "_" is
an ordinary variable, for example in:

_, y, _ := coord(p)

Then "_" could be an integer (or what
ever number is used in coord).

Then we would have:

   "_" gets assigned by a value (the x from coord)
   y gets assigne by a value (the y from coord)
   "_" gets assigned, overridden, by a value (the z from coord)

But now there is a problem, what if
we have such a code:

_, _, e = person(z)

And if person returns for example (name:String,
age:integer, employer:String). Then Andreas
Leitgrebs re-enablement is just phantasie,

since in a type safe language, this simple
translation with the same variable "_"
doesn't work:

   "_" gets assigned by a value (the name from person)
   "_" gets assigned, overridden, by a value (the age from coord)
   e gets assigned by a value (the employer from person)

The two "_" are in type conflict. But Garbage
collection and everything in Java needs types.
So there is no re-enablement whatever,

this would be a new feature. A requirement
would be that "_" is really really short lived,
and quickly losses its type and can acquire

another type...

> Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 9/23/2017 12:46 PM, j4n bur53 wrote:
>>> As long as Java doesn't have multi-returns, there
>>> will be not many use cases. For multi returns, if
>>> they were in the Java language, it could be offered
>>> as in the Go Programming Language:
>>> /* fetching the y coordinate of a 3D point */
>>> _, y, _ := coord(p)
>> I suspect that Java will get that in version 10 or 11.
>> Reason: C# got it in version 7 (and Java and C# tend
>> to steal ideas from each other).
>> Syntax like:
>> (int v1,int v2) = M();
>
> These speculations are entirely orthogonal to the point that "_"
> is taken away from the realm of identifiers, but might in future
> be used syntactically like throw-away identifiers - A use they
> sometimes already have - and this particular use is now being
> forbidden just before likely being re-enabled.
>

[toc] | [prev] | [next] | [standalone]

#37460

On 9/24/2017 7:25 AM, Andreas Leitgeb wrote:
> Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 9/23/2017 12:46 PM, j4n bur53 wrote:
>>> As long as Java doesn't have multi-returns, there
>>> will be not many use cases. For multi returns, if
>>> they were in the Java language, it could be offered
>>> as in the Go Programming Language:
>>> /* fetching the y coordinate of a 3D point */
>>> _, y, _ := coord(p)
>> I suspect that Java will get that in version 10 or 11.
>> Reason: C# got it in version 7 (and Java and C# tend
>> to steal ideas from each other).
>> Syntax like:
>> (int v1,int v2) = M();
> 
> These speculations are entirely orthogonal to the point that "_"
> is taken away from the realm of identifiers, but might in future
> be used syntactically like throw-away identifiers

True.

>                                             - A use they
> sometimes already have - and this particular use is now being
> forbidden just before likely being re-enabled.

Regarding the original question then I am not sure that
I understand it.

According to the link Java 8 gives a warning about the
usage of _ as an identified because it may get a special
meaning in a future Java version.

That makes perfect sense to me at the old context
may become illegal syntax in the future, so a good
thing to get rid of that usage now before problems
arise.

Arne

[toc] | [prev] | [next] | [standalone]

#37461

Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 9/24/2017 7:25 AM, Andreas Leitgeb wrote:
>> [...] - A use they
>> sometimes already have - and this particular use is now being
>> forbidden just before likely being re-enabled.
> According to the link Java 8 gives a warning about the
> usage of _ as an identified[r?] because it may get a special
> meaning in a future Java version.

In Java up to (and including, despite the warning) 8, one can
have a method with (at most) one of the formal parameter names
called "_", as well as "catch (MyException _) ...", and it is
also (still) possible to actually see the value in "_" in the
respective block.

With Java 9, one can not use "_" as a param name or catch
identifier at all - regardless if used lateron or not.

In some future Java version "X" it *may* be, that one can once
again specify the keyword "_" in certain places, where currently 
an identifier is required. It's probably going to mean that
whatever value would end up in that position is just dropped/
ignored/unretrievable.

Case 1: 
  final void foo(int _) { System.out.printf("%d%n", _); }

Case 2: 
  final void foo(int _) { System.out.printf("%d%n", 54); }

Both are legal in Java up to 8, illegal in 9, but only case 1
would remain illegal in that Java "X". Case 2 in Java "X" would
behave exactly the same as it behaved back in Java 7.

Anyone using "_" already now as if it were a black-hole identifier
(as in case 2) will have to change their code to use e.g. "_ignore"
instead, and only for Java "X" they will once again be able to
change it back to "_".

A less bumpy road would have been to only error on the *use* of
"_" as in case 1, while leaving case 2 legal until Java "X".

> That makes perfect sense to me at[s?] the old context
> may become illegal syntax in the future, so a good
> thing to get rid of that usage now before problems
> arise.

It would be, if only those usages were refused that would fail
with the new semantics.

But then again, the prognose about future meaning of "_" might be
entirely off, and "_" might get to mean something completely different 
lateron - only then it would become clear, why "_" was illegalized 
even for cases like case 2 above.

[toc] | [prev] | [next] | [standalone]

#37462

On 9/24/2017 7:27 PM, Andreas Leitgeb wrote:
> Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 9/24/2017 7:25 AM, Andreas Leitgeb wrote:
>>> [...] - A use they
>>> sometimes already have - and this particular use is now being
>>> forbidden just before likely being re-enabled.
>> According to the link Java 8 gives a warning about the
>> usage of _ as an identified[r?] because it may get a special
>> meaning in a future Java version.
> 
> In Java up to (and including, despite the warning) 8, one can
> have a method with (at most) one of the formal parameter names
> called "_", as well as "catch (MyException _) ...", and it is
> also (still) possible to actually see the value in "_" in the
> respective block.
> 
> With Java 9, one can not use "_" as a param name or catch
> identifier at all - regardless if used lateron or not.
> 
> In some future Java version "X" it *may* be, that one can once
> again specify the keyword "_" in certain places, where currently
> an identifier is required. It's probably going to mean that
> whatever value would end up in that position is just dropped/
> ignored/unretrievable.
> 
> Case 1:
>    final void foo(int _) { System.out.printf("%d%n", _); }
> 
> Case 2:
>    final void foo(int _) { System.out.printf("%d%n", 54); }
> 
> Both are legal in Java up to 8, illegal in 9, but only case 1
> would remain illegal in that Java "X". Case 2 in Java "X" would
> behave exactly the same as it behaved back in Java 7.
> 
> Anyone using "_" already now as if it were a black-hole identifier
> (as in case 2) will have to change their code to use e.g. "_ignore"
> instead, and only for Java "X" they will once again be able to
> change it back to "_".
> 
> A less bumpy road would have been to only error on the *use* of
> "_" as in case 1, while leaving case 2 legal until Java "X".
> 
>> That makes perfect sense to me at[s?] the old context
>> may become illegal syntax in the future, so a good
>> thing to get rid of that usage now before problems
>> arise.
> 
> It would be, if only those usages were refused that would fail
> with the new semantics.
> 
> But then again, the prognose about future meaning of "_" might be
> entirely off, and "_" might get to mean something completely different
> lateron - only then it would become clear, why "_" was illegalized
> even for cases like case 2 above.

Even if the prognosis is almost on and the future meaning
would be almost the same as expected now, then there could
still be some subtle differences.

I think it would be risky to try and base warnings
on something expected.

Arne

[toc] | [prev] | [next] | [standalone]

#37464

Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 9/24/2017 7:27 PM, Andreas Leitgeb wrote:
>> But then again, the prognose about future meaning of "_" might be
>> entirely off, and "_" might get to mean something completely different
>> lateron - only then it would become clear, why "_" was illegalized
>> even for cases like case 2 above.
> Even if the prognosis is almost on and the future meaning
> would be almost the same as expected now, then there could
> still be some subtle differences.
> I think it would be risky to try and base warnings
> on something expected.

These "expectations" are all mine, and I add one more expectation
to my list, namely that *they* (the Java designers) themselves have
more solid ground for their work than just my vague expectations.

So, I'd see two possibilities: a) they have intentions for "_"
that are really incompatible with any current use of "_" as 
identifier (or pseudio-identifier not further used), or b) they
did a questionable job. Based on what awesome work they've done
so far, I'd rather bet on a).

[toc] | [prev] | [next] | [standalone]

#37465

On Saturday, September 23, 2017 at 12:47:10 PM UTC-4, j4n bur53 wrote:
> As long as Java doesn't have multi-returns, there
> will be not many use cases. For multi returns, if
> they were in the Java language, it could be offered
> as in the Go Programming Language:
> 
> /* fetching the y coordinate of a 3D point */
> _, y, _ := coord(p)
> https://stackoverflow.com/questions/27764421/what-is-in-a-golang-declaration
> 
> Which reminds me of the Prolog language so called
> annonymous variables:
> 
>    ?- .., coord(P,_,Y,_).
> 
> Andreas Leitgeb schrieb:
> > When googling for underscore keyword I found a
> > mail by Brian Goetz, where he hinted for a future
> > use of the "_" keyword:
> >
> >   http://mail.openjdk.java.net/pipermail/lambda-dev/2013-July/010670.html

I don't see the point to _ as a placeholder for a value passed in or out of a method in an OO language.

Passing in if we don't want to pass a parameter we either have an overload for the method to default that parameter or pass in a dummy value such as null for an object or -1 for primitive number.

Passing out if you don't need that parameter don't reference it.  To pass out more than one we can use a native array[], a List object, a built in multi-value object ie java.awt.Point, or a custom object.

I'm sure I've never used _ by itself, so if it doesn't affect _variable or _method we should be fine.  I normally write catch (Exception e) even if I never reference the e variable within the block.

[toc] | [prev] | [next] | [standalone]

#37466

Eric Douglas wrote:
> 
> I don't see the point to _ as a placeholder for a value passed in or out of a method in an OO language.
> 
> Passing in if we don't want to pass a parameter we either have an overload for the method to default that parameter or pass in a dummy value such as null for an object or -1 for primitive number.
> 
> Passing out if you don't need that parameter don't reference it.  To pass out more than one we can use a native array[], a List object, a built in multi-value object ie java.awt.Point, or a custom object.
> 
> I'm sure I've never used _ by itself, so if it doesn't affect _variable or _method we should be fine.  I normally write catch (Exception e) even if I never reference the e variable within the block.

The JLS tells us that identifier characters include "for historical reasons, the ASCII underscore". That "for historical reasons" is a hint that one should not use it for current code, other than in constant variable names and not as the first character.

The style conventions, if followed, would prevent any difficulty from a repurposing of the identifier `_`. But no one cares about coding conventions, so now they're whining.

Kinda like those folks who used non-public APIs like `Unsafe` then complained when the usage turned out to be, well, unsafe.

I find it difficult to be sympathetic to those who abuse the system then complain when the abuse becomes untenable.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#37471

On 25-09-17 17:07, Eric Douglas wrote:
> On Saturday, September 23, 2017 at 12:47:10 PM UTC-4, j4n bur53 wrote:
> 
> I don't see the point to _ as a placeholder for a value passed in or out of a method in an OO language.
> 
> Passing in if we don't want to pass a parameter we either have an overload for the method to default that parameter or pass in a dummy value such as null for an object or -1 for primitive number.
> 
> Passing out if you don't need that parameter don't reference it.  To pass out more than one we can use a native array[], a List object, a built in multi-value object ie java.awt.Point, or a custom object.
> 
> I'm sure I've never used _ by itself, so if it doesn't affect _variable or _method we should be fine.  I normally write catch (Exception e) even if I never reference the e variable within the block.
> 

I personally think _ as a throw-out identifier is not very useful. If 
you do not want a name then change the grammar to allow leaving it out 
at the first place, like C++ did.

I do like what Scala also does with the _ identifier (it also uses it as 
throw-out identifier). In Scala

_ + 1

is shorthand for

x_1001 => x_1001 + 1

and

_.toLowerCase

is shorthand for

x_1002 => x_1002.toLowerCase

and Scala goes even further. It defines

_ * _

to be a shorthand for

(x_1003,x_1004) => x_1003 * x_1004

This allows for expressions like

x.filter(_.length > 1).map(_.toInt).reduce(_ + _)

which is far more concise and readable than

x.filter(a => a.length > 1).map(b => b.toInt).reduce((c,d) => c + d)

[toc] | [prev] | [next] | [standalone]

#37476

On 9/25/2017 5:30 PM, Silvio wrote:
> I do like what Scala also does with the _ identifier (it also uses it as 
> throw-out identifier). In Scala
> 
> _ + 1
> 
> is shorthand for
> 
> x_1001 => x_1001 + 1
> 
> and
> 
> _.toLowerCase
> 
> is shorthand for
> 
> x_1002 => x_1002.toLowerCase
> 
> and Scala goes even further. It defines
> 
> _ * _
> 
> to be a shorthand for
> 
> (x_1003,x_1004) => x_1003 * x_1004
> 
> This allows for expressions like
> 
> x.filter(_.length > 1).map(_.toInt).reduce(_ + _)
> 
> which is far more concise and readable than
> 
> x.filter(a => a.length > 1).map(b => b.toInt).reduce((c,d) => c + d)

It is definitely shorter.

I am not as convinced about more readable.

Arne

[toc] | [prev] | [next] | [standalone]

#37479

Ok, thats interesting, shorthand for
lambda expressions. Oki Doki.

There is no end to learning...

Arne Vajhøj schrieb:
> On 9/25/2017 5:30 PM, Silvio wrote:
>> I do like what Scala also does with the _ identifier (it also uses it
>> as throw-out identifier). In Scala
>>
>> _ + 1
>>
>> is shorthand for
>>
>> x_1001 => x_1001 + 1
>>
>> and
>>
>> _.toLowerCase
>>
>> is shorthand for
>>
>> x_1002 => x_1002.toLowerCase
>>
>> and Scala goes even further. It defines
>>
>> _ * _
>>
>> to be a shorthand for
>>
>> (x_1003,x_1004) => x_1003 * x_1004
>>
>> This allows for expressions like
>>
>> x.filter(_.length > 1).map(_.toInt).reduce(_ + _)
>>
>> which is far more concise and readable than
>>
>> x.filter(a => a.length > 1).map(b => b.toInt).reduce((c,d) => c + d)
>
> It is definitely shorter.
>
> I am not as convinced about more readable.
>
> Arne

[toc] | [prev] | [next] | [standalone]

#37493

On 26-09-17 02:24, Arne Vajhøj wrote:
> On 9/25/2017 5:30 PM, Silvio wrote:
> 
> It is definitely shorter.
> 
> I am not as convinced about more readable.
> 
> Arne

The improved readability (as I conceive it) lies in the fact that there 
is no need to match up two variable names.

x => x.length

requires my mind to note that the same identifier x is used twice: once 
as formal parameter and once in the value expression. Having

_.length

makes that work redundant. But you have to be used to this to 
immediately recognize the closure (lambda in Java speak). Since in 
typical Scala source code the use of this shorthand is more frequent 
than explicit closures one gets used to it really fast.

Besides, all other things considered equal I find shorter code more 
readable than long code. But that also depends on the way one tends to 
absorb code.

Silvio

[toc] | [prev] | [next] | [standalone]

#37495

On Wednesday, September 27, 2017 at 1:05:52 PM UTC-4, Silvio wrote:
> On 26-09-17 02:24, Arne Vajhøj wrote:
> > On 9/25/2017 5:30 PM, Silvio wrote:
> > 
> > It is definitely shorter.
> > 
> > I am not as convinced about more readable.
> > 
> > Arne
> 
> The improved readability (as I conceive it) lies in the fact that there 
> is no need to match up two variable names.
> 
> x => x.length
> 
> requires my mind to note that the same identifier x is used twice: once 
> as formal parameter and once in the value expression. Having
> 
> _.length
> 
> makes that work redundant. But you have to be used to this to 
> immediately recognize the closure (lambda in Java speak). Since in 
> typical Scala source code the use of this shorthand is more frequent 
> than explicit closures one gets used to it really fast.
> 
> Besides, all other things considered equal I find shorter code more 
> readable than long code. But that also depends on the way one tends to 
> absorb code.
> 
> Silvio

Medium code is more readable.  No one likes when it gets too wordy or too abbreviated.

T1 = T1 + A1
Oh, they're totaling the sales tax here..

[toc] | [prev] | [next] | [standalone]

#37498

On 27-09-17 19:25, Eric Douglas wrote:
> On Wednesday, September 27, 2017 at 1:05:52 PM UTC-4, Silvio wrote:
> 
> Medium code is more readable.  No one likes when it gets too wordy or too abbreviated.
> 
> T1 = T1 + A1
> Oh, they're totaling the sales tax here..
> 

True, shorter is only better within reasonable boundaries. No need to go 
down the APL road again.

[toc] | [prev] | [next] | [standalone]

#37502

On 9/27/2017 1:05 PM, Silvio wrote:
> On 26-09-17 02:24, Arne Vajhøj wrote:
>> On 9/25/2017 5:30 PM, Silvio wrote:
>>
>> It is definitely shorter.
>>
>> I am not as convinced about more readable.
> 
> The improved readability (as I conceive it) lies in the fact that there 
> is no need to match up two variable names.
> 
> x => x.length
> 
> requires my mind to note that the same identifier x is used twice: once 
> as formal parameter and once in the value expression. Having
> 
> _.length
> 
> makes that work redundant. But you have to be used to this to 
> immediately recognize the closure (lambda in Java speak). Since in 
> typical Scala source code the use of this shorthand is more frequent 
> than explicit closures one gets used to it really fast.

I consider "readable by those used to it" to be "somewhat readable".

But the problem may be very limited - I don't think those not
having learned Scala will have much luck reading or writing
Scala anyway.

Arne

[toc] | [prev] | [next] | [standalone]

#37505

On Wednesday, September 27, 2017 at 8:02:56 PM UTC-4, Arne Vajhøj wrote:
> 
> I consider "readable by those used to it" to be "somewhat readable".
> 
> But the problem may be very limited - I don't think those not
> having learned Scala will have much luck reading or writing
> Scala anyway.
> 
> Arne

Bringing other languages into the mix is usually bad.  We don't want to make all my Java resemble my COBOL and all your Java resemble C#.
Each language should have clear standards such that mastering the Java at my business makes it easier to read Java at any other business.

[toc] | [prev] | [next] | [standalone]

#37511

On 9/28/2017 8:11 AM, Eric Douglas wrote:
> On Wednesday, September 27, 2017 at 8:02:56 PM UTC-4, Arne Vajhøj wrote:
>>
>> I consider "readable by those used to it" to be "somewhat readable".
>>
>> But the problem may be very limited - I don't think those not
>> having learned Scala will have much luck reading or writing
>> Scala anyway.
> 
> Bringing other languages into the mix is usually bad. We don't want
> to make all my Java resemble my COBOL and all your Java resemble C#.
> Each language should have clear standards such that mastering the
> Java  at my business makes it easier to read Java at any other business.

I agree. But languages do evolve over time - often inspired by other
languages.

My point here was strictly Scala only though. It is not a language
leaning towards trying to use without properly learning it first.

Arne

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web