Call by Result

[Silvio]

Yeah, I hoped you'd give a short example of use in Haskell/Scala, to show
what a language could make even simpler about that.

Well, here is an example in Scala:

Let's assume we have a getString defined as:

def getString(s : String) : Option[String] =
{
if (s.reverse == s) Some(s.toLowerCase)
else None
}

then it will return either Some(r) where r is a String or it will return
None indicating failure.

We could call it like this:

val t : Option[String] = getString(s)

or a bit shorter:

val t = getString(s)

and let the compiler figure out the type of t (I could have dropped the
Option[String] return type from the getString definition the same way).

Now we could use pattern matching against t:

t match
{
case Some(r) => println("Success, return value is: " + r)
case None => println("Failure")
}

However, since an Option[T] is a monad like most containers in Scala are
we have shorthand notations for chaining operations on it like map,
foreach, forall, exists etc.

Example1: t.map(_.length) will return an Option[Int] which is None if t
is None or Some(r.length) if t is Some(r)

Example2: t.foreach(println(_)) will print r if t is Some(r) and do
nothing if t is None.

Pattern matching is an incredible powerfull and flexible language
feature in Scala and clearly lays out how Option[T] can be treated. In
practice we rarely use it on an Option because the shorthand notations
cover almost every practical use.

Gr. Silvio

I should have said "short cuts" instead of "shorthand notations". They
are not notational magic but simple library functions.

 

[Gene Wirchenko]

[snip]

I have used a number of languages. One of the things that I
dislike about Java is the small letter first style. It is
particularly bothersome, because my variable naming convention often
has HN-like prefixes.

So, actually the method here would be named sGetString(), that's fine
with Java's *case*-conventions (but perhaps not with others...)

Actually, I do not use prefixes on method names. I have
considered it, but never done it. My prefixes do not indicate
variable type but variable use/function.

Sincerely,

Gene Wirchenko

 

[Gene Wirchenko]

I think its because GW is using a variant of the so-called Hungarian
Notation which AFAIK is a Microsoft invention, initially applied to C and
C++.

The idea is to make the name of a function or method document the type of
object it returns by prefixing the name with an alphabet soup of
initials, so a function returning a string might be called
sMyFunction(). The catch with it is that, if you need to change the type
of the returned value, you need to change all references to it as well,
e.g if the function should rather return a pointer to the string you have
to rename it to psMyFunction() and then hunt through the source file(s)
changing all references to it as well.

And it is a big catch.

My prefixes do not indicate types but functions. For example,
"c" is count. "cClients" is number of clients. The type might be
short, int, or long. If I change the type, I do not change the name.

Sincerely,

Gene Wirchenko



Sincerely,

Gene Wirchenko

 

[Gene Wirchenko]

On 6/10/2011 11:57 AM, Gene Wirchenko wrote:
...
...

I much prefer to have my code in each language look like conventional
code in its language.

Much code looks the same in multiple languages. Which language
is
a=b*c+d
in?

Code is not going to be more than very superficially readable by someone
who does not know its language, so the reading audience is generally
programmers who are familiar with the language. Those programmers will

There is a lot of commonality in notation. Compare the switch
statements in C, Java, and JavaScript.

usually also be used to the corresponding conventions, and will more
easily read code that follows those conventions.

There are plenty of arguments over which format is best. It is
quite possible that there is no one best way. Given that, I prefer to
use something that I like.

I'm not sure what the number of years programming has to do with anything.

It suggests that I have worked with a number of languages.

Sincerely,

Gene Wirchenko

 

[Gene Wirchenko]

Gene Wirchenko wrote :

So have I (30 years actually, ah I can see retirement from here...).
And I have had training and/or self-taught in over 15 languages. Shrug,
so what.

Yup. Why have a bunch of different formats for what is about the
same thing?

However I religiously use the conventions of the language I am writing
in. Amongst other things it allows future maintenance programmers to
read the code without needing to do mental gymnastics to convert code
style before they can understand what the code is doing.

This is important if you ever work in a professional environment. Your

Did you read the bit where I said that I have been doing so for
about twenty-five years? You quoted it.

code WILL be looked at by someone else sometime in the future.

Could be. I will follow such conventions as have been set.

The lone programmer (consultant or hired) writing obfuscated code to
their own personal style/standards would not be tolerated in any of the
companies I have worked for.

My code is not obfuscated. Sometimes, I am the one setting the
standard by right of being the only progammer. If not, I ask for the
standards and then follow them.

Sincerely,

Gene Wirchenko

 

[Gene Wirchenko]

Gene Wirchenko wrote :

The benefit is that it is instantly recognizable by any competent Java
programmer as to what it does and how any problem is handled.

Mine is also recognisable, etc.

If you want minimal source code size, then Java is not for you.

I do not. What I want is reasonable code size. Such segments as
the above are not too bad if there are only a few, but make it half a
dozen, say, and suddenly a short method is taking up most of a page.

Sincerely,

Gene Wirchenko

 

[Arved Sandstrom]

Much code looks the same in multiple languages. Which language
is
a=b*c+d
in?

Ideally none. Which brings us back to Patricia's point: what you would
_actually_ use in place of 'a' tends to look different based on what
language you're using.

There is a lot of commonality in notation. Compare the switch
statements in C, Java, and JavaScript.

[ SNIP ]

There is indeed. Some constructs, like the usual assortment of control
statements, are similar (or identical) across dozens of languages.
Probably most competent programmers with a good deal of varied
experience can parse code in quite a few languages to establish _general
purpose_ of a program, including code written in languages they have
never used.

On the other hand, I wouldn't expect a programmer to be capable of
conducting a code review unless they were familiar with the language
(i.e. they could write good-quality original code in the target language).

You could call the distinction above the difference between superficial
and non-superficial understanding. I wouldn't attempt to classify this
myself; I'd simply assert that the closer two languages are to each
other in genealogy, the easier it is for a programmer who knows one of
them well to understand programs written in the other. I'll bet most
programmers have eventually been in situations where they are writing a
program in language X and borrow implementation ideas from code examples
written in language Y. You don't have to know language Y all that well
in order to do this.

To return to the original point, languages do have conventions. It helps
to follow them. That a given language, say language X, happens to be
close enough to language Y that the two share a lot of conventions (or
what seems to be often the case, they deliberately don't) is not that
important. What's important is to be aware of what substantive and
common conventions exist for a given language. Or for that matter, for a
given organization or team. Or single coder: single coders are allowed
to have conventions too.

To seize on one specific related to the last, a convention like the one
that you follow, Hungarian notation in its original, Simonyi sense,
makes a lot of sense. I've used forms of it myself. For me this is not a
convention specific to a language, it's specific to a problem that's
being solved. I could use it in Java or C++ or F#, and it wouldn't be
wrong to use it, because it's a problem-specific tailored notation, not
a language convention notation.

AHS

 

[Paul Cager]

What I want is reasonable code size.  Such segments as
the above are not too bad if there are only a few, but make it half a
dozen, say, and suddenly a short method is taking up most of a page.

I'm not sure I understand the problem here.

I think what you want to be able to write (but Java won't let you) is
this:

String ReturnString="";
boolean DidItWork=GetString(ReturnString);
if (!DidItWork) {
handleErrorOrThrowException();
} else {
doSomethingWithString();
}

Patricia and others have suggested that the idiomatic way in Java to
do it is to use an exception like this:

try {
doSomethingWith(getString());
} catch (SomeErrorOccuredException e) {
handleErrorOrThrowException();
}

That looks perfectly reasonable to me.

 

[Gene Wirchenko]

On 11-06-13 01:53 AM, Gene Wirchenko wrote:
[snip]

Much code looks the same in multiple languages. Which language
is
a=b*c+d
in?

Ideally none. Which brings us back to Patricia's point: what you would
_actually_ use in place of 'a' tends to look different based on what
language you're using.

No, not I. What *someone else* might actually use could differ
depending on language. *I* try to keep them the same or similar
between languages. I understand that there are differences between
languages that have to be allowed for, but variable names is not
usually one of them.

[snipped lots of good points]

Sincerely,

Gene Wirchenko

 

[Wojtek]

Gene Wirchenko wrote :

Yup. Why have a bunch of different formats for what is about the
same thing?

Hmm, this statement has a slight disconnect with this statement:

Could be. I will follow such conventions as have been set.

My code is not obfuscated. Sometimes, I am the one setting the
standard by right of being the only progammer. If not, I ask for the
standards and then follow them.

If you are the originator of a language then you can set whatever
standards (um, conventions) you want. And others will follow them to
keep consistent with you.

But if you are coding in a generally used language then it behooves you
to follow the generally accepted conventions. To do otherwise will
confuse some future maintenance programmer and will also present your
work as amateurish.

Visual Basic by convention capitalizes function names. Java by
convention does not. And K&R C and PHP do not use camel case.

VB: public function DoMyWork() as String
Java: public string doMyWork()
C: char* do_my_work()
PHP: function do_my_work()

I find all of these readable, however I would NEVER mix the different
ways of naming a method.

There is one thing that has pretty well been consistent over the years.
ALL the code I have ever written HAS been looked at by someone else, no
matter how off-the-cuff and temporary I thought it was when I wrote it.

And since I have had many juniors working for me, it is my
responsibility to teach them the accepted way of presenting code in
whatever language I happen to be using at the time. No matter how much
they think it is not necessary.

A convention is just that. A generally accepted way of doing things.

 

[Wojtek]

Gene Wirchenko wrote :

Mine is also recognisable, etc.

There is a difference between (glance, ok) and (glance, read, consider,
ok).

 

[Andreas Leitgeb]

One should never confuse the actual Hungarian language with anything
found in the Hungarian naming convention. The human language has
absolutely nothing to do with the convention.

As "markspace" says, "sz" simply means a null(zero)-terminated string.
The "st" tag means a Pascal-style string.

Thanks to you and markspace for correcting my misbelief.

In Java, there's of course no need to distinguish those ancient(*haha*)
string-variants, so St and Sz as prefixes wouldn't make sense here.

As for which has more fans, I have no idea. But since the "Systems"
variant is so awful and useless, I would guess it has very few fans.
And that's probably the one you're describing as "the MS-variant".

I was once "contaminated" when programming some C++ under WfW 3.11.
Although I try to avoid Windows wherever possible (out of my experience/
taste, not out of "religion"), I do sometimes name a local variable like
bIsSnaFu, rather than just isSnaFu. Also, my classes' fields not rarely
have an "m_" prefix, and sometimes even a one-lc-letter type-code if it
helps to convey the form of representation (e.g. decimal string versus
int) used at that spot.

I tend to see it as having further evolved from original HN in the same
way as e.g. Italic has evolved from Latin..

The
people who continue to voluntarily use Hungarian (and there are few
remaining) surely are using the original, which is actually useful and
meaningful.

And I'd bet, it's just a question of personal taste than anything else.

So on that basis, I have to doubt your doubt.

I do *not* doubt your doubt on my doubt, but don't share it, either

 

[Andreas Leitgeb]

Well, here is an example in Scala:
[...]
def getString(s : String) : Option[String] =
{
if (s.reverse == s) Some(s.toLowerCase)
else None
}
[...]
val t = getString(s)
[...]
t match
{
case Some(r) => println("Success, return value is: " + r)
case None => println("Failure")
}

Ah, thanks. Yep, I've seen this concept once when playing with
OCaml (which mentions Haskell as one of its roots). Never got
warm with it, though.

In the end, it isn't all that more concise than C++/Java...
It's a bit like C's unions with some byte ahead to tell which
of the variants is the current one, and bunch of logical operations
that is often trivially converted into a couple of (possibly nested)
"if-else"s. I'm not saying it's bad, just it didn't impress me all
that much, so far.

 

[Silvio]

Well, here is an example in Scala:
[...]
def getString(s : String) : Option[String] =
{
if (s.reverse == s) Some(s.toLowerCase)
else None
}
[...]
val t = getString(s)
[...]
t match
{
case Some(r) => println("Success, return value is: " + r)
case None => println("Failure")
}

Ah, thanks. Yep, I've seen this concept once when playing with
OCaml (which mentions Haskell as one of its roots). Never got
warm with it, though.

In the end, it isn't all that more concise than C++/Java...
It's a bit like C's unions with some byte ahead to tell which
of the variants is the current one, and bunch of logical operations
that is often trivially converted into a couple of (possibly nested)
"if-else"s. I'm not saying it's bad, just it didn't impress me all
that much, so far.

Actually instead of being union-like Some and None are best thought of
as subclasses of Option (with None being an 'object' which is best
described as a singleton class).

And you are right in saying that a pattern match on an Option is quite
verbose, probably more verbose than a plain if-else.

I merely used it to lay out the logical structure of the Option. As I
said Option variables are usually handled via methods like map/foreach/etc.
This is not only shorter and easier to read (for people used to the
idiom) but it also mixes nicely with the way containers likes List, Map
etc. work.

Only when used in combination with other monads does Option shine.

Pattern matching is very powerful because it unifies matching on types
and values AND extracting sub-values from matched values. But it would
deserve better examples than the one I provided.

One would have to consider a larger piece of code to appreciate it as a
whole instead of looking at isolated language features.

Cheers,

Silvio

 

[markspace]

[...]
In Java, there's of course no need to distinguish those ancient(*haha*)
string-variants, so St and Sz as prefixes wouldn't make sense here.

True. Instead, in Java (and .NET, Cocoa, etc.) instead we have mutable
and immutable strings.

I don't think so. String is final and immutable. You can't make a
mutable object that is-a string.

You can make a CharSequence mutable, and Strings are CharSequence's, but
you can't make a mutable String.

 

[Stefan Ram]

True. Instead, in Java (and .NET, Cocoa, etc.) instead we
have mutable and immutable strings.

In Java there are strings and string buffers/builders.

A string buffer/build is not a string, just a char sequence.

Thus, in Java we have mutable and immutable char sequences.

 

[Arved Sandstrom]

Well, here is an example in Scala:
[...]
def getString(s : String) : Option[String] =
{
if (s.reverse == s) Some(s.toLowerCase)
else None
}
[...]
val t = getString(s)
[...]
t match
{
case Some(r) => println("Success, return value is: " + r)
case None => println("Failure")
}

Ah, thanks. Yep, I've seen this concept once when playing with
OCaml (which mentions Haskell as one of its roots). Never got
warm with it, though.

In the end, it isn't all that more concise than C++/Java...
It's a bit like C's unions with some byte ahead to tell which
of the variants is the current one, and bunch of logical operations
that is often trivially converted into a couple of (possibly nested)
"if-else"s. I'm not saying it's bad, just it didn't impress me all
that much, so far.

[ SNIP ]

Only when used in combination with other monads does Option shine.

Pattern matching is very powerful because it unifies matching on types
and values AND extracting sub-values from matched values. But it would
deserve better examples than the one I provided.

One would have to consider a larger piece of code to appreciate it as a
whole instead of looking at isolated language features.

+1.

Either larger chunks of code, and/or chaining of operations. With Option
or Maybe, you don't have to check every intermediate result. With
idiomatic Haskell or Scala you'd probably not see a whole bunch of
pattern matching for Maybe or Option at all.

It's way more concise than Java, and another advantage still remains
that we're not looking for a special value (null).

Cheers,

Silvio

AHS

 

[Andreas Leitgeb]

It's way more concise than Java, and another advantage still remains
that we're not looking for a special value (null).

I'm not yet sure, whether null in Java counts as a "String value", or not.

I think it is not (whereas the empty string of course is). As such, a
variable (or field) "s" (or even an expression) of type String really
happens to be implicitly the pendant of Haskell's "Option"al String:

Either it is "Null"... (ahem, "null"), or it holds an actual String value.

Ditto for all the non-primitive types.

 

[Arved Sandstrom]

I'm not yet sure, whether null in Java counts as a "String value", or not.

I think it is not (whereas the empty string of course is). As such, a
variable (or field) "s" (or even an expression) of type String really
happens to be implicitly the pendant of Haskell's "Option"al String:

Either it is "Null"... (ahem, "null"), or it holds an actual String value.

Ditto for all the non-primitive types.

I know what you're saying, but the JLS says that a variable of a class
type can hold a null reference or a reference to an object whose type is
that class type or any subclass of that class type. There are similar
comments for variables of interface and array types.

The JLS also says that the null reference can be cast to any reference
type. The JLS says that we can pretend that 'null' is a special literal
that can be of any reference type.

Furthermore, the default value for all reference types is null.

All that JLS language - but particularly that last statement from the
JLS - tells me that we consider 'null' to be a permitted value of
reference types. A String variable can refer to 'null' just as it can
refer to "" or "Arved", so from that perspective 'null' is a String
value; albeit a special one.

It's not the same notion as Option or Maybe, although I believe I sense
what you were getting at. The difference being, if I were to use, as an
example, Option[java.lang.String] in Scala, legitimate values of a
variable of that type would be

Some("Arved")
Some(null)
None

That is, Scala Option is like a container. "Some" means that a value of
a certain type (like java.lang.String) is contained; "None" means that
the container is empty. In the case of Scala Option, a reference value
contained by Some may be 'null' - this is qualitatively not the same
thing as None.

AHS

 

[Stefan Ram]

refer to "" or "Arved", so from that perspective 'null' is a String
value; albeit a special one.

The JLS does not defined »String value«, so you are all free to
define it as you like to. However, we also have

!( null instanceof java.lang.String )

. Since the objects of a value class are intended to model the
values modulo »equals«, not being an instance of such a class
has some weight in favor of not being a value of that model.

Albeit in some other context, the JLS says with regard to
Annotations,

»Note that null is not a legal element value for any
element type.«

null surely is a /reference value/, but it does not identify
a string value in the sense of the class String as a class
whose instances model string values.