«

On 12/10/2012 8:00 PM, markspace wrote:
> On 12/10/2012 5:56 PM, Martin Gregorie wrote:
>>
>> Yes, couldn't agree more. The only languages I've used that approach the
>> ugliness of Perl are Python (its object construction and handling are
>>
>>
>
> Good, it's not just me that dislikes Python.
>
>

I am not so fond of Python either...

but, to each his own...


WRT scripting, many people like Python, many others prefer Lua, and I
myself, prefer my own obscure ECMAScript-based language, and, elsewhere,
I have seen plenty of people hate on ECMAScript and friends (JavaScript
and ActionScript) as well...

or such...

IMHO final code does not need to have any strings literals. Strings should
be allways created via out-of-code resources.

On 12/10/2012 09:56 PM, Martin Gregorie wrote:
> On Mon, 10 Dec 2012 17:35:37 -0800, markspace wrote:
>
>> On 12/10/2012 4:17 PM, Martin Gregorie wrote:
>>> I've always liked the Awk and Perl default convention of delimiting
>>> regexes with slashes: /regex/ - if their compilers can deal with this
>>> cleanly, the Java compiler could surely do the same.
>>
>> Perl, especially, and "cleanly" don't belong in the same sentence. Or
>> paragraph. Or solar system.
>>
> Yes, couldn't agree more. The only languages I've used that approach the
> ugliness of Perl are Python (its object construction and handling are
> every bit as nasty as Perls) and RPG II (designing an HLL to look exactly
> like a fixed field assembler is just plain perverse).
>
> I'll use awk+bash in preference to Perl any day. However, Perl almost
> certainly inherited its use of /regex/ delimiters from awk, which is a
> fairly elegant and minimal scripting system and I do like those
> delimiters.
>
> Don't forget that Perl, in its earliest form, was very obviously built by
> mashing together a lot of Bourn Shell syntax with bits nicked from awk
> and sed and completed by shovelling in the most useful bits of several
> small UNIX utilities. Larry Wall has always acknowledged that as being
> its origin. Its got a bit more structured and usable since then, but IMO
> its still damned ugly.

I'm not all that religious about any language, but let's spread the lack
of love around - Java can be awesomely ugly when it hits a problem it's
not suited for. And it often doesn't compete nearly as well as, say,
Perl or Python, if it's in a problem realm where it results in 3x or
more code to solve a given problem.

I just now close-of-business yesterday finished a chunk of code that
despite some 15 years of working with Java isn't anything but ugly...and
I stipulate that it's not an uncommon ugly as far as Java and certain
types of problems go. Very complex SQL so a native JPA query that needs
to be assembled, trees using the Swing implementations, enumerations,
iterators, *lots* of list operations, *lots* of conditional intermediate
getter and setter operations to build the list of final result objects
to pass back to XStream for the REST call response...it's not pretty.

In a problem like this Java becomes kludgy because of death by a
thousand cuts. You do everything best practise (or decent practise) and
you still end up with hard-to-read clumsy code: no type inference so too
much verbiage, no C#-style properties so dozens of getter/setter usages
start looking pretty opaque...a Perl or Python equivalent _would_ look
considerably better. Ironically even the use of longer, descriptive
variable and method names can be self-defeating in this scenario - it's
just more bloat.

And it's telling that you have libraries like StringUtils or Google
Guava that supply a list "join" method if you don't care to write your
own loop to handle it. Another one of those thousand cuts that adds to
the bloat.

I'll probably end up refactoring some of the code - but in another
language like Perl or Python or Scala or Ruby or C# I'd not have to
refactor in the first place.

AHS

On 12/11/2012 1:58 AM, William Bonawentura wrote:
> IMHO final code does not need to have any strings literals. Strings
> should be allways created via out-of-code resources.

In general yes.

There are probably some exceptions. I would not want Java keywords to
come from an external resource for a Java compiler.



Arne

On 12/10/2012 6:17 PM, Martin Gregorie wrote:
> On Mon, 10 Dec 2012 18:04:33 -0500, Eric Sosman wrote:
>
>
>> It's unfortunate that both Java and regex use \ so heavily,
>> because it leads to a lot of escaping-of-escapes and harms readability.
>> But why should it be a given that Java's literals should be different to
>> avoid conflict with regex syntax? Why not change the regex syntax
>> instead, and use, say, ~ for the role now taken by \? It might improve
>> regexes to the point where they're merely unreadable, instead of
>> intolerable.
>
> I've always liked the Awk and Perl default convention of delimiting
> regexes with slashes: /regex/ - if their compilers can deal with this
> cleanly, the Java compiler could surely do the same.

Which works really well until you want to match the / character in
pathnames. Or you want to lex but not parse the language--note that
/foo/ is lexed as a regex if the preceding token is an operator and
lexed as a sequence of tokens (DIV, IDENT, DIV) if the preceding token
is an operator.

--
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth

On 12/11/2012 1:01 AM, Arved Sandstrom wrote:

> I stipulate that it's not an uncommon ugly as far as Java and certain
> types of problems go. Very complex SQL so a native JPA query that needs
> to be assembled, ...
> getter and setter operations to build the list of final result objects
> to pass back to XStream for the REST call response...it's not pretty.


I'd love to see a smaller, non-proprietary version of that code, just to
see if we can't make some suggestions how to improve things.

On 12/11/2012 9:08 AM, Arne Vajhøj wrote:
> On 12/11/2012 1:58 AM, William Bonawentura wrote:
>> IMHO final code does not need to have any strings literals. Strings
>> should be allways created via out-of-code resources.
>
> In general yes.
>
> There are probably some exceptions. I would not want Java keywords to
> come from an external resource for a Java compiler.
>
>
>

IMO, about the only things (strings-wise) which really make sense being
moved into external resources are:
default configuration options (debatable, if the config file will
override them anyways);
(potentially) messages intended for human readers or similar (say, to
allow language-specific translations or similar).


if the bulk of the string literals are things internal to the program
(rather than intended for an end user), then it makes little sense to
move them to external resources (IME, most string literals tend to be
program internal anyways, with human-readable messages few and far
between, and most of these in-turn being internal debugging messages).

with user-readable strings, the program could still be developed under a
policy like "if you need the messages in a language you can read, either
learn English (or Japanese or Chinese or similar) or get a dictionary",
so making them external may not make much sense in this case.


even with language-specific strings, unless using magic numbers, a
string may still be needed to refer to them.

On 12/11/2012 1:58 AM, William Bonawentura wrote:
> IMHO final code does not need to have any strings literals. Strings
> should be allways created via out-of-code resources.

String message1 =
readFromURL(Thing.class.getResource("message1"));
// Code reviewer vetoes the in-line literal, so ...

String message1 =
readFromURL(Thing.class.getResource(
readFromURL(Thing.class.getResource(
"name_of_message1"))));
// Code reviewer vetoes the in-line literal, so ...

String message1 =
readFromURL(Thing.class.getResource(
readFromUrl(Thing.class.getResource(
readFromUrl(Thing.class.getResource(
"name_of_name_of_message1"))))));
// Code reviewer vetoes the in-line literal, and
// gets badly mauled by fed-up programmer.

--
Eric Sosman
d

On 12/11/2012 3:01 AM, Arved Sandstrom wrote:
> On 12/10/2012 09:56 PM, Martin Gregorie wrote:
>> On Mon, 10 Dec 2012 17:35:37 -0800, markspace wrote:
>>
>>> On 12/10/2012 4:17 PM, Martin Gregorie wrote:
>>>> I've always liked the Awk and Perl default convention of delimiting
>>>> regexes with slashes: /regex/ - if their compilers can deal with this
>>>> cleanly, the Java compiler could surely do the same.
>>>
>>> Perl, especially, and "cleanly" don't belong in the same sentence. Or
>>> paragraph. Or solar system.
>>>
>> Yes, couldn't agree more. The only languages I've used that approach the
>> ugliness of Perl are Python (its object construction and handling are
>> every bit as nasty as Perls) and RPG II (designing an HLL to look exactly
>> like a fixed field assembler is just plain perverse).
>>
>> I'll use awk+bash in preference to Perl any day. However, Perl almost
>> certainly inherited its use of /regex/ delimiters from awk, which is a
>> fairly elegant and minimal scripting system and I do like those
>> delimiters.
>>
>> Don't forget that Perl, in its earliest form, was very obviously built by
>> mashing together a lot of Bourn Shell syntax with bits nicked from awk
>> and sed and completed by shovelling in the most useful bits of several
>> small UNIX utilities. Larry Wall has always acknowledged that as being
>> its origin. Its got a bit more structured and usable since then, but IMO
>> its still damned ugly.
>
> I'm not all that religious about any language, but let's spread the lack
> of love around - Java can be awesomely ugly when it hits a problem it's
> not suited for. And it often doesn't compete nearly as well as, say,
> Perl or Python, if it's in a problem realm where it results in 3x or
> more code to solve a given problem.
>

same here, mostly not very language religious (and use several
languages, although admittedly the bulk of it is written in C and some
C++, 1).

1: C (and to a lesser extent C++) is fairly good for infrastructural
code, but sadly, using it itself seemingly creates a need for large
amounts of infrastructural code (and, as well, the "libraries" space is
often very fragmentary, and 3rd party libraries are very much often "use
at your own risk"). (a multi platform project also ends up with a lot of
"portability boilerplate" as well).


in contrast, Java is much better for tasks which involve "using things
provided by the class library" (or, at least, this has been my
experience). a big comprehensive library at some cost that writing code
for things not provided by the library is a bit more painful (partly due
to the languages' relatively minimalist semantics, vs, say, C or C++).

C# is a little more of a compromise, but has a big drawback of being
tied mostly to Windows and .NET (portability in C# is not entirely
non-existent, after all there is Mono, .GNU, ..., but is not exactly a
strong area for the language either...).


me remembering a recent example, looking where a person tried writing an
H.264 codec in Java, and apparently gave up partly through (though, as
an external observer, one can't be sure if this was more due to the
general pain of writing an H.264 codec, or the specifics of writing an
implementation in Java).

(admittedly, it is bad enough writing these sorts of things in C#, and
Java would pose some additional issues, as in many ways they run at-odds
with the language-design choices).


sadly, a lot is a case where choices made which may offer benefits in
one area come at costs in another area.


not sure if anyone will try to argue all this.


> I just now close-of-business yesterday finished a chunk of code that
> despite some 15 years of working with Java isn't anything but ugly...and
> I stipulate that it's not an uncommon ugly as far as Java and certain
> types of problems go. Very complex SQL so a native JPA query that needs
> to be assembled, trees using the Swing implementations, enumerations,
> iterators, *lots* of list operations, *lots* of conditional intermediate
> getter and setter operations to build the list of final result objects
> to pass back to XStream for the REST call response...it's not pretty.
>
> In a problem like this Java becomes kludgy because of death by a
> thousand cuts. You do everything best practise (or decent practise) and
> you still end up with hard-to-read clumsy code: no type inference so too
> much verbiage, no C#-style properties so dozens of getter/setter usages
> start looking pretty opaque...a Perl or Python equivalent _would_ look
> considerably better. Ironically even the use of longer, descriptive
> variable and method names can be self-defeating in this scenario - it's
> just more bloat.
>

pretty much...


descriptive variable-names can be a double-edged sword.

in some cases, they can make the code "more obvious", especially if the
variable has "some well-defined meaning readily expressible in words".

in many cases, there are no words to express just what exactly this
variable is being used for, or it is being used as part of a big/hairy
set of mathematical expressions, making the use of a longer variable
name considerably more painful (like a single calculation spread over 4
or 5 lines).

there are still cases where multiple lines are needed for some
calculations, even with single-letter variables.


usually, using longer method names is not as big of an issue, since IME
method calls tend to be used at a lower density than that of variables,
and also because the choice of method names often has a lot more effect
on code outside the class, whereas variable names are typically much
more local to a given class or method.


my policy in general though is more often to not rigidly adhere to any
particular conventions, but rather to adjust conventions more "as they
make sense for a particular piece of code" (though sometimes this can
get at-odds with an IDE which does auto-formatting...).


> And it's telling that you have libraries like StringUtils or Google
> Guava that supply a list "join" method if you don't care to write your
> own loop to handle it. Another one of those thousand cuts that adds to
> the bloat.
>
> I'll probably end up refactoring some of the code - but in another
> language like Perl or Python or Scala or Ruby or C# I'd not have to
> refactor in the first place.
>

yep, could be.

On 12/11/2012 3:31 PM, Eric Sosman wrote:
> On 12/11/2012 1:58 AM, William Bonawentura wrote:
>> IMHO final code does not need to have any strings literals. Strings
>> should be allways created via out-of-code resources.
>
> String message1 =
> readFromURL(Thing.class.getResource("message1"));
> // Code reviewer vetoes the in-line literal, so ...
>
> String message1 =
> readFromURL(Thing.class.getResource(
> readFromURL(Thing.class.getResource(
> "name_of_message1"))));
> // Code reviewer vetoes the in-line literal, so ...
>
> String message1 =
> readFromURL(Thing.class.getResource(
> readFromUrl(Thing.class.getResource(
> readFromUrl(Thing.class.getResource(
> "name_of_name_of_message1"))))));
> // Code reviewer vetoes the in-line literal, and
> // gets badly mauled by fed-up programmer.
>

String message1 =
readFromURL(Thing.class.getResource(
new String(new char[]
{ 'm', 'e', 's', 's', 'a', 'g', 'e', '1' } )));

but, yeah, banning string literals would be stupid...