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

multi-line Strings

Started by	bob smith <bob@coolfone.comze.com>
First post	2012-12-10 08:22 -0800
Last post	2012-12-29 18:18 +0100
Articles	20 on this page of 146 — 22 participants

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

  multi-line Strings bob smith <bob@coolfone.comze.com> - 2012-12-10 08:22 -0800
    Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-10 11:43 -0500
      Re: multi-line Strings Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-12-10 09:36 -0800
      Re: multi-line Strings markspace <-@.> - 2012-12-10 09:42 -0800
        Re: multi-line Strings Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-12-10 09:51 -0800
          Re: multi-line Strings markspace <-@.> - 2012-12-10 10:27 -0800
            Re: multi-line Strings Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-12-10 13:43 -0500
              Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-10 15:08 -0500
                Re: multi-line Strings markspace <-@.> - 2012-12-10 13:05 -0800
                Re: multi-line Strings Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-12-10 16:22 -0500
                  Re: multi-line Strings markspace <-@.> - 2012-12-10 13:36 -0800
                  Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-10 16:52 -0500
                    Re: multi-line Strings Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-12-10 18:04 -0500
                      Re: multi-line Strings Martin Gregorie <martin@address-in-sig.invalid> - 2012-12-11 00:17 +0000
                        Re: multi-line Strings markspace <-@.> - 2012-12-10 17:35 -0800
                          Re: multi-line Strings Martin Gregorie <martin@address-in-sig.invalid> - 2012-12-11 01:56 +0000
                            Re: multi-line Strings markspace <-@.> - 2012-12-10 18:00 -0800
                              Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-10 21:16 -0500
                                Re: multi-line Strings Martin Gregorie <martin@address-in-sig.invalid> - 2012-12-11 22:21 +0000
                              Re: multi-line Strings BGB <cr88192@hotmail.com> - 2012-12-10 22:12 -0600
                            Re: multi-line Strings Arved Sandstrom <asandstrom2@eastlink.ca> - 2012-12-11 05:01 -0400
                              Re: multi-line Strings markspace <-@.> - 2012-12-11 09:46 -0800
                                Re: multi-line Strings Martin Gregorie <martin@address-in-sig.invalid> - 2012-12-11 22:26 +0000
                              Re: multi-line Strings BGB <cr88192@hotmail.com> - 2012-12-11 16:25 -0600
                        Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-10 21:10 -0500
                          Re: multi-line Strings Martin Gregorie <martin@address-in-sig.invalid> - 2012-12-11 22:31 +0000
                            Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-14 22:30 -0500
                              Re: multi-line Strings BGB <cr88192@hotmail.com> - 2012-12-15 03:35 -0600
                              Re: multi-line Strings "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2012-12-15 11:54 +0000
                                Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-15 08:53 -0500
                                Re: multi-line Strings Jim Janney <jjanney@shell.xmission.com> - 2012-12-16 12:19 -0700
                                  Re: multi-line Strings "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2012-12-18 13:24 +0000
                                Re: multi-line Strings Gene Wirchenko <genew@telus.net> - 2012-12-16 17:21 -0800
                                  Re: multi-line Strings "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2012-12-18 14:03 +0000
                                    Re: multi-line Strings Gene Wirchenko <genew@telus.net> - 2012-12-18 09:05 -0800
                                Re: multi-line Strings Arved Sandstrom <asandstrom2@eastlink.ca> - 2012-12-17 20:13 -0400
                                  Re: multi-line Strings "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2012-12-18 13:38 +0000
                                    Re: multi-line Strings Arved Sandstrom <asandstrom2@eastlink.ca> - 2012-12-19 19:48 -0400
                                Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-18 21:07 -0500
                                  Re: multi-line Strings BGB <cr88192@hotmail.com> - 2012-12-19 08:26 -0600
                                    Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-19 16:36 -0500
                                      Re: multi-line Strings BGB <cr88192@hotmail.com> - 2012-12-21 12:51 -0600
                                        Re: multi-line Strings BGB <cr88192@hotmail.com> - 2012-12-21 14:05 -0600
                              Re: multi-line Strings "Peter J. Holzer" <hjp-usenet2@hjp.at> - 2012-12-15 18:22 +0100
                                Re: multi-line Strings Robert Klemme <shortcutter@googlemail.com> - 2012-12-16 00:34 +0100
                                  Re: multi-line Strings BGB <cr88192@hotmail.com> - 2012-12-16 02:56 -0600
                                    Re: multi-line Strings Robert Klemme <shortcutter@googlemail.com> - 2012-12-16 14:07 +0100
                                      Re: multi-line Strings BGB <cr88192@hotmail.com> - 2012-12-16 13:44 -0600
                                  Re: multi-line Strings "Peter J. Holzer" <hjp-usenet2@hjp.at> - 2012-12-16 17:43 +0100
                                    Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-19 19:37 -0500
                        Re: multi-line Strings BGB <cr88192@hotmail.com> - 2012-12-10 22:03 -0600
                        Re: multi-line Strings Joshua Cranmer <Pidgeot18@verizon.invalid> - 2012-12-11 10:43 -0600
                          Re: multi-line Strings Martin Gregorie <martin@address-in-sig.invalid> - 2012-12-11 22:44 +0000
                      Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-10 21:09 -0500
        Re: multi-line Strings Sebastian <sebastian@undisclosed.invalid> - 2012-12-12 10:40 +0100
          Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-12 20:28 -0500
      Re: multi-line Strings BGB <cr88192@hotmail.com> - 2012-12-10 13:42 -0600
    Re: multi-line Strings "William Bonawentura" <nie@ma.mnie.pl> - 2012-12-11 07:58 +0100
      Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-11 10:08 -0500
        Re: multi-line Strings Leif Roar Moldskred <leifm@dimnakorr.com> - 2012-12-11 09:41 -0600
        Re: multi-line Strings BGB <cr88192@hotmail.com> - 2012-12-11 15:02 -0600
          Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-14 22:27 -0500
          Re: multi-line Strings Joshua Cranmer <Pidgeot18@verizon.invalid> - 2012-12-14 23:23 -0600
            Re: multi-line Strings BGB <cr88192@hotmail.com> - 2012-12-15 02:56 -0600
      Re: multi-line Strings Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-12-11 16:31 -0500
        Re: multi-line Strings BGB <cr88192@hotmail.com> - 2012-12-11 17:07 -0600
          Re: multi-line Strings Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2012-12-11 15:31 -0800
            Re: multi-line Strings BGB <cr88192@hotmail.com> - 2012-12-11 19:41 -0600
        Re: multi-line Strings "William Bonawentura" <nie@ma.mnie.pl> - 2012-12-13 07:43 +0100
          Re: multi-line Strings Lew <lewbloch@gmail.com> - 2012-12-12 23:09 -0800
          Re: multi-line Strings Arved Sandstrom <asandstrom2@eastlink.ca> - 2012-12-13 06:34 -0400
            Re: multi-line Strings "William Bonawentura" <nie@ma.mnie.pl> - 2012-12-14 07:35 +0100
              Re: multi-line Strings Leif Roar Moldskred <leifm@dimnakorr.com> - 2012-12-14 02:44 -0600
                Re: multi-line Strings "William Bonawentura" <nie@ma.mnie.pl> - 2012-12-14 11:48 +0100
                  Re: multi-line Strings Leif Roar Moldskred <leifm@dimnakorr.com> - 2012-12-14 05:10 -0600
                  Re: multi-line Strings Lew <lewbloch@gmail.com> - 2012-12-14 15:18 -0800
                  Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-14 22:16 -0500
              Re: multi-line Strings Arved Sandstrom <asandstrom2@eastlink.ca> - 2012-12-14 05:55 -0400
                Re: multi-line Strings "William Bonawentura" <nie@ma.mnie.pl> - 2012-12-14 11:50 +0100
                  Re: multi-line Strings Leif Roar Moldskred <leifm@dimnakorr.com> - 2012-12-14 05:12 -0600
                  Re: multi-line Strings Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-12-14 11:24 -0800
                    Re: multi-line Strings markspace <-@.> - 2012-12-14 11:47 -0800
                      Re: multi-line Strings Gene Wirchenko <genew@telus.net> - 2012-12-14 12:26 -0800
                        Re: multi-line Strings markspace <-@.> - 2012-12-14 12:53 -0800
                          Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-14 22:36 -0500
                            Re: multi-line Strings "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2012-12-15 12:06 +0000
                              Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-19 19:23 -0500
                            Re: multi-line Strings Leif Roar Moldskred <leifm@dimnakorr.com> - 2012-12-15 08:16 -0600
                              Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-19 19:24 -0500
                            Re: multi-line Strings Lew <lewbloch@gmail.com> - 2012-12-15 13:36 -0800
                          Re: multi-line Strings Gene Wirchenko <genew@telus.net> - 2012-12-16 17:36 -0800
                      Re: multi-line Strings Gene Wirchenko <genew@telus.net> - 2012-12-14 12:30 -0800
                        Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-14 22:43 -0500
                      Re: multi-line Strings Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-12-14 17:36 -0500
                        Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-14 22:46 -0500
                          Re: multi-line Strings BGB <cr88192@hotmail.com> - 2012-12-16 04:29 -0600
                      Re: multi-line Strings Arved Sandstrom <asandstrom2@eastlink.ca> - 2012-12-17 20:45 -0400
                        Re: multi-line Strings Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2012-12-17 17:11 -0800
                          Re: multi-line Strings Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-12-17 20:25 -0500
                            Re: multi-line Strings Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2012-12-17 18:13 -0800
                              Re: multi-line Strings Arved Sandstrom <asandstrom2@eastlink.ca> - 2012-12-18 06:34 -0400
                                Re: multi-line Strings Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2012-12-18 10:54 -0800
                                  Re: multi-line Strings Arved Sandstrom <asandstrom2@eastlink.ca> - 2012-12-18 18:57 -0400
                                    Re: multi-line Strings Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-12-18 20:02 -0500
                                      Re: multi-line Strings Lew <lewbloch@gmail.com> - 2012-12-18 17:13 -0800
                                    Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-19 19:35 -0500
                                  Re: multi-line Strings Gene Wirchenko <genew@telus.net> - 2012-12-18 15:12 -0800
                                    Re: multi-line Strings Gene Wirchenko <genew@telus.net> - 2012-12-19 10:00 -0800
                                  Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-19 19:31 -0500
                                Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-19 19:29 -0500
                                  Re: multi-line Strings Arved Sandstrom <asandstrom2@eastlink.ca> - 2012-12-19 20:44 -0400
                                    Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-19 21:50 -0500
                                      Re: multi-line Strings Lew <lewbloch@gmail.com> - 2012-12-19 23:15 -0800
                                      Re: multi-line Strings Arved Sandstrom <asandstrom2@eastlink.ca> - 2012-12-20 06:00 -0400
                                  Re: multi-line Strings Gene Wirchenko <genew@telus.net> - 2012-12-20 08:56 -0800
                                Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-19 19:33 -0500
                            Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-17 21:43 -0500
                              Re: multi-line Strings Leif Roar Moldskred <leifm@dimnakorr.com> - 2012-12-17 22:09 -0600
                                Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-18 20:59 -0500
                              Re: multi-line Strings "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2012-12-18 13:22 +0000
                                Re: multi-line Strings Leif Roar Moldskred <leifm@dimnakorr.com> - 2012-12-18 07:52 -0600
                                  Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-18 20:58 -0500
                                Re: multi-line Strings Gene Wirchenko <genew@telus.net> - 2012-12-18 09:10 -0800
                                Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-18 20:56 -0500
                              Re: multi-line Strings Arved Sandstrom <asandstrom2@eastlink.ca> - 2012-12-18 19:05 -0400
                                Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-18 20:42 -0500
                            Re: multi-line Strings Jim Janney <jjanney@shell.xmission.com> - 2012-12-17 22:18 -0700
                          Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-17 21:46 -0500
                            Re: multi-line Strings Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2012-12-17 21:01 -0800
                              Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-18 20:46 -0500
                        Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-17 21:51 -0500
                          Re: multi-line Strings Patricia Shanahan <pats@acm.org> - 2012-12-17 19:41 -0800
                          Re: multi-line Strings Arved Sandstrom <asandstrom2@eastlink.ca> - 2012-12-18 19:19 -0400
                            Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-18 20:50 -0500
                              Re: multi-line Strings Arved Sandstrom <asandstrom2@eastlink.ca> - 2012-12-19 05:23 -0400
                                Re: multi-line Strings Lew <lewbloch@gmail.com> - 2012-12-19 13:25 -0800
              Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-14 22:14 -0500
              Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-14 22:14 -0500
            Re: multi-line Strings Jukka Lahtinen <jtfjdehf@hotmail.com.invalid> - 2012-12-14 23:43 +0200
              Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-14 22:20 -0500
                Re: multi-line Strings Arved Sandstrom <asandstrom2@eastlink.ca> - 2012-12-17 20:47 -0400
    Re: multi-line Strings Jim Janney <jjanney@shell.xmission.com> - 2012-12-12 08:33 -0700
      Re: multi-line Strings Lew <lewbloch@gmail.com> - 2012-12-12 11:32 -0800
        Re: multi-line Strings markspace <-@.> - 2012-12-12 11:45 -0800
    Re: multi-line Strings Lew <lewbloch@gmail.com> - 2012-12-15 13:33 -0800
      Re: multi-line Strings Sven Köhler <remove-sven.koehler@gmail.com> - 2012-12-29 18:18 +0100

Page 2 of 8 — ← Prev page 1 [2] 3 4 5 6 7 8 Next page →

#20248

From	Arved Sandstrom <asandstrom2@eastlink.ca>
Date	2012-12-11 05:01 -0400
Message-ID	<tDCxs.3405$EO2.1439@newsfe04.iad>
In reply to	#20238

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

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

#20255

From	markspace <-@.>
Date	2012-12-11 09:46 -0800
Message-ID	<ka7rid$55u$1@dont-email.me>
In reply to	#20248

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.

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

#20260

From	Martin Gregorie <martin@address-in-sig.invalid>
Date	2012-12-11 22:26 +0000
Message-ID	<ka8bu2$68v$2@localhost.localdomain>
In reply to	#20255

On Tue, 11 Dec 2012 09:46:50 -0800, markspace wrote:

> 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.
>
My problems in that area are usually to a failure on my part to stop and 
think about a set of objects and how they will be used before getting 
stuck in. As you say, refactoring is a pain but IME its all too often due 
to a lack of forethought.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

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

#20261

From	BGB <cr88192@hotmail.com>
Date	2012-12-11 16:25 -0600
Message-ID	<ka8c2f$jdc$1@news.albasani.net>
In reply to	#20248

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.

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

#20241

From	Arne Vajhøj <arne@vajhoej.dk>
Date	2012-12-10 21:10 -0500
Message-ID	<50c69625$0$293$14726298@news.sunsite.dk>
In reply to	#20234

On 12/10/2012 7: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.

That require regex to become a part of the language
syntax.

Arne

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

#20262

From	Martin Gregorie <martin@address-in-sig.invalid>
Date	2012-12-11 22:31 +0000
Message-ID	<ka8c8b$68v$3@localhost.localdomain>
In reply to	#20241

On Mon, 10 Dec 2012 21:10:46 -0500, Arne Vajhøj wrote:

> 
> That require regex to become a part of the language syntax.
>
Yes, probably, but so would using Python-like """string""" features as 
was discussed recently. IMO regexes are so powerful and useful that it 
would be worthwhile making them a special case, but then again I'm not a 
language designer, so what do I know....
 
Its just a bit frustrating that there are languages around that can deal 
with regexes without turning them into an unreadable mess and that Java 
isn't one of them.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

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

#20343

From	Arne Vajhøj <arne@vajhoej.dk>
Date	2012-12-14 22:30 -0500
Message-ID	<50cbeec3$0$291$14726298@news.sunsite.dk>
In reply to	#20262

On 12/11/2012 5:31 PM, Martin Gregorie wrote:
> On Mon, 10 Dec 2012 21:10:46 -0500, Arne Vajhøj wrote:
>> That require regex to become a part of the language syntax.
>>
> Yes, probably, but so would using Python-like """string""" features as
> was discussed recently. IMO regexes are so powerful and useful that it
> would be worthwhile making them a special case, but then again I'm not a
> language designer, so what do I know....

I am not so happy about special additions to language to handle
special cases.

But then I am not a language person either ...

:-)

> Its just a bit frustrating that there are languages around that can deal
> with regexes without turning them into an unreadable mess and that Java
> isn't one of them.

The regex syntax itself is not exactly a good example of readability.

Arne

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

#20351

From	BGB <cr88192@hotmail.com>
Date	2012-12-15 03:35 -0600
Message-ID	<kahgdm$aao$1@news.albasani.net>
In reply to	#20343

On 12/14/2012 9:30 PM, Arne Vajhøj wrote:
> On 12/11/2012 5:31 PM, Martin Gregorie wrote:
>> On Mon, 10 Dec 2012 21:10:46 -0500, Arne Vajhøj wrote:
>>> That require regex to become a part of the language syntax.
>>>
>> Yes, probably, but so would using Python-like """string""" features as
>> was discussed recently. IMO regexes are so powerful and useful that it
>> would be worthwhile making them a special case, but then again I'm not a
>> language designer, so what do I know....
>
> I am not so happy about special additions to language to handle
> special cases.
>
> But then I am not a language person either ...
>
> :-)
>

a lot depends on language use-case and design philosophy...
one mans' useless is another mans vital...

for example, in my case I personally have relatively little need for 
date-handling or code to help with monetary calculations...

but, I have more extensive use-cases for things like vector, quaternion, 
and matrix math (as well as good old math-functions, like 
sin/cos/atan2/sqrt/...).

so, for example, one language designer more aiming for business uses 
might be like "why don't I make dates and money features be built into 
the language?...", and I might be more like "why not make vector-math 
and math-functions be built in?".

another person might really want built-in regexes, due to doing a lot of 
text-processing.

...

then, another area might be "language minimalism" vs "throwing in 
whatever might be potentially useful". one person might avoid adding any 
feature unless it is painfully needed, and another person might just 
throw in features "because they can" (especially features which don't 
cost much to implement).

...

all these things leading to variations in the "style" of the language.

>> Its just a bit frustrating that there are languages around that can deal
>> with regexes without turning them into an unreadable mess and that Java
>> isn't one of them.
>
> The regex syntax itself is not exactly a good example of readability.
>

yeah.

I guess it is more about being "common" than "readable".

for example, I initially didn't really want to add it to my language, 
because it was pretty ugly, but ECMA-262 did include it as part of the 
language description.

FWIW, I also added the "Type<T>" generic syntax as well (as part of the 
parser), even if thus far, generics aren't actually implemented (it is 
one thing to add parser support, and another to actually make it do 
something...).

then there are a few features which are supported, but are on the "I 
don't know what their future status will be" list.

one example, is supporting more conventional declaration syntax, in 
contrast to the usual JS / AS declaration syntax.

like, currently, a person can type either:
"var a:int[];" or "int[] a;".

the uncertainty is mostly along the lines of "how much sense does it 
make to have a language based of JS, but not use JS declaration syntax?...".

well, nevermind:
"int[256] arr;" which is equivalent to:
"var arr:int[256];"
or:
"int[] arr=new int[256];"
or:
"var arr:int[]=new int[256];"
...

I also considered before possibly allowing for:
"var:int[256] arr;"
but, there is no precedent for such a syntax...

such is the great fun (and uncertainty) of language-design.

> Arne
>
>

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

#20353

From	"Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org>
Date	2012-12-15 11:54 +0000
Message-ID	<MbednV3SS9RB-VHNnZ2dnUVZ8lqdnZ2d@bt.com>
In reply to	#20343

Arne Vajhøj wrote:

> The regex syntax itself is not exactly a good example of readability.

This, I think, is the point.  We don't need a special String syntax to fix the
problem with regexps -- we'd be much better off with a fixed regexp syntax.
Something OO.  And (since this is Java) I don't think that we need be afraid of
something verbose.

Off-the-top-of-my-head (all classes and method are imaginary):

    Regexp alpha = Regexp.fromList(java.lang.text.portable.Alphas);
    alpha = alpha.or('_');
    Regexp num = Regexp.fromList(java.lang.text.portable.Digits);
    Regexp alphanum = alpha.or(num);
    Regexp identifier = alpha.followedBy(alphanum.repeated());

Naturally, I'd prefer something a /bit/ less verbose, but Java won't support
that.  But even with the verbosity, I think my version is /far/ better.  It
puts the composition of regexps into the programmer's hands which means that it
can be approached like any other complex programming task.  Quoting/escaping
problems go away.  Grouping (bracketing) problems go away (and become
decoupled from the backreference concept.  Comments become trivially easy to
add.  Various kinds of abstraction and reuse are possible.

    -- chris

P.S. Mind you: my /real/ opinion is that regular expressions have no place in
production code except in the construction of scanners (for which a more
directly-applicable implementation than standalone regexps is helpful).
Regexps are for users to enter, or go into configuration data.  At least the
suggestion above has the advantage -- from my point of view -- that regexps no
longer look like "quick and easy" fixes to problems, and maybe the programmer
would think more about whether they /actually/ solve [all of] the problem at
hand.

P.P.S  UK post codes...

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

#20359

From	Arne Vajhøj <arne@vajhoej.dk>
Date	2012-12-15 08:53 -0500
Message-ID	<50cc80ca$0$284$14726298@news.sunsite.dk>
In reply to	#20353

On 12/15/2012 6:54 AM, Chris Uppal wrote:
> Arne Vajhøj wrote:
>
>> The regex syntax itself is not exactly a good example of readability.
>
> This, I think, is the point.  We don't need a special String syntax to fix the
> problem with regexps -- we'd be much better off with a fixed regexp syntax.
> Something OO.  And (since this is Java) I don't think that we need be afraid of
> something verbose.
>
> Off-the-top-of-my-head (all classes and method are imaginary):
>
>      Regexp alpha = Regexp.fromList(java.lang.text.portable.Alphas);
>      alpha = alpha.or('_');
>      Regexp num = Regexp.fromList(java.lang.text.portable.Digits);
>      Regexp alphanum = alpha.or(num);
>      Regexp identifier = alpha.followedBy(alphanum.repeated());
>
> Naturally, I'd prefer something a /bit/ less verbose, but Java won't support
> that.  But even with the verbosity, I think my version is /far/ better.  It
> puts the composition of regexps into the programmer's hands which means that it
> can be approached like any other complex programming task.  Quoting/escaping
> problems go away.  Grouping (bracketing) problems go away (and become
> decoupled from the backreference concept.  Comments become trivially easy to
> add.  Various kinds of abstraction and reuse are possible.

I would assume that it has been tried many times to come up with
a nicer syntax for regex. Tried without success.

It is not a problem for the simplex regex, but the complex ones
are tricky.

> P.S. Mind you: my /real/ opinion is that regular expressions have no place in
> production code except in the construction of scanners (for which a more
> directly-applicable implementation than standalone regexps is helpful).
> Regexps are for users to enter, or go into configuration data.  At least the
> suggestion above has the advantage -- from my point of view -- that regexps no
> longer look like "quick and easy" fixes to problems, and maybe the programmer
> would think more about whether they /actually/ solve [all of] the problem at
> hand.

Regex is widely used for general data validations. From form input
validation in web apps to XML schema definitions.

Arne

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

#20384

From	Jim Janney <jjanney@shell.xmission.com>
Date	2012-12-16 12:19 -0700
Message-ID	<ydn6241erdy.fsf@shell.xmission.com>
In reply to	#20353

"Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> writes:

> Arne Vajhøj wrote:
>
>> The regex syntax itself is not exactly a good example of readability.
>
> This, I think, is the point.  We don't need a special String syntax to fix the
> problem with regexps -- we'd be much better off with a fixed regexp syntax.
> Something OO.  And (since this is Java) I don't think that we need be afraid of
> something verbose.
>
> Off-the-top-of-my-head (all classes and method are imaginary):
>
>     Regexp alpha = Regexp.fromList(java.lang.text.portable.Alphas);
>     alpha = alpha.or('_');
>     Regexp num = Regexp.fromList(java.lang.text.portable.Digits);
>     Regexp alphanum = alpha.or(num);
>     Regexp identifier = alpha.followedBy(alphanum.repeated());
>
> Naturally, I'd prefer something a /bit/ less verbose, but Java won't support
> that.  But even with the verbosity, I think my version is /far/ better.  It
> puts the composition of regexps into the programmer's hands which means that it
> can be approached like any other complex programming task.  Quoting/escaping
> problems go away.  Grouping (bracketing) problems go away (and become
> decoupled from the backreference concept.  Comments become trivially easy to
> add.  Various kinds of abstraction and reuse are possible.
>
>     -- chris
>
> P.S. Mind you: my /real/ opinion is that regular expressions have no place in
> production code except in the construction of scanners (for which a more
> directly-applicable implementation than standalone regexps is helpful).
> Regexps are for users to enter, or go into configuration data.  At least the
> suggestion above has the advantage -- from my point of view -- that regexps no
> longer look like "quick and easy" fixes to problems, and maybe the programmer
> would think more about whether they /actually/ solve [all of] the problem at
> hand.
>
> P.P.S  UK post codes...

For me the native regexp syntax usually becomes unmanageable at about
the same time that I'm ready to decide that regexps aren't the best
approach anyway.  But there are some Java libraries for building complex
regexps. A quick Google search turns up this one

    http://reggert.github.com/reb4j/

I thought I remembered another one, but I can't find it now.

-- 
Jim Janney

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

#20440

From	"Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org>
Date	2012-12-18 13:24 +0000
Message-ID	<67adnWd5AN0Z7U3NnZ2dnUVZ8hednZ2d@bt.com>
In reply to	#20384

Jim Janney wrote:

>  But there are some Java libraries for building complex
> regexps. A quick Google search turns up this one
>
>    http://reggert.github.com/reb4j/

Thank you for the link.  I hadn't come acress reb4j before.  Nice.

    -- chris

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

#20387

From	Gene Wirchenko <genew@telus.net>
Date	2012-12-16 17:21 -0800
Message-ID	<ngssc8t2ff5fff72dnial8rg979rq5mgg5@4ax.com>
In reply to	#20353

On Sat, 15 Dec 2012 11:54:15 -0000, "Chris Uppal"
<chris.uppal@metagnostic.REMOVE-THIS.org> wrote:

[snip]

>P.S. Mind you: my /real/ opinion is that regular expressions have no place in
>production code except in the construction of scanners (for which a more
>directly-applicable implementation than standalone regexps is helpful).

     I find them useful for validation of data format.  Apart from
that, I have little to no use for them.

     I do not like them where I have to explain why something is
wrong.  For that, I will use a state machine with multiple error
states.

>Regexps are for users to enter, or go into configuration data.  At least the
>suggestion above has the advantage -- from my point of view -- that regexps no
>longer look like "quick and easy" fixes to problems, and maybe the programmer
>would think more about whether they /actually/ solve [all of] the problem at
>hand.

     I find that as soon as a regex becomes a bit hairy that that is
about the point where I want to break it up.  I prefer short regexes
with a bit of control code.

>P.P.S  UK post codes...

     As an example of what?

Sincerely,

Gene Wirchenko

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

#20445

From	"Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org>
Date	2012-12-18 14:03 +0000
Message-ID	<K9udnT17yJXN5U3NnZ2dnUVZ8hOdnZ2d@bt.com>
In reply to	#20387

Gene Wirchenko wrote:

> > P.P.S  UK post codes...
>
>     As an example of what?

;-)

As an example of either or both of the points I was trying to make.

UK post codes are pretty complex -- much more so than they look (e.g. see:
    http://en.wikipedia.org/wiki/Postcodes_in_the_United_Kingdom
) but many programmers don't realise that at first and so expect to be able to 
use regular expressions for (say) input validation.  A quick web search turns 
up tons of examples of people looking for regexps for matching UK post codes.

But if you want correct validation, then -- although it can be done with a 
regexp -- it aint pretty.  More importantly its not maintainable.  I can't find 
a reference to an (semi-)official correct regexp anymore, but the following 
(which is present, but commented out in the British NLPG XML Schema 
http://www.iahub.net/docs/1280134898838.xsd):

    /(GIR 0AA)|((([A-Z-[QVX]][0-9][0-9]?)|(([A-Z-[QVX]][A-Z-[IJZ]][0-9][0-9]?)| 
(([A-Z-[QVX]][0-9][A-HJKSTUW])|([A-Z-[QVX]][A-Z-[IJZ]][0-9][ABEHMNPRVWXY])))) 
[0-9][A-Z-[CIKMOV]]{2})/

seems to be close enough to illustrate[*].  In my (admittedly limited) 
experience, if you are going to do things /right/ with regexps (rather than 
indulge in a quick 'n wrong approximation), such monsters are the rule rather 
than the exception.

So, there are two ways around this.  One is not to try to shoe-horn complex 
(typically for human, legal, or historical reasons) processing into the 
one-size-fits-all tool of regexps.  Just don't use 'em ;-)

The other to take a normal programmer's approach to the complexity here.  Break 
it down.  Approach it in stages.  Use abstraction.  Use variables.  Use loops 
(where appropriate).  Use /comments/.  I was going to try converting the 
monster into code using reb4j (see Jim Janney's comments) and the info from the 
above Wikipedia page, but it turns out that I'm too lazy :-(

    -- chris

[*] But it doesn't handle BFPO address postcodes.

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

#20451

From	Gene Wirchenko <genew@telus.net>
Date	2012-12-18 09:05 -0800
Message-ID	<vq71d8dlk9eakg2s4tscgndcp4bve1f6sd@4ax.com>
In reply to	#20445

On Tue, 18 Dec 2012 14:03:37 -0000, "Chris Uppal"
<chris.uppal@metagnostic.REMOVE-THIS.org> wrote:

>Gene Wirchenko wrote:
>
>> > P.P.S  UK post codes...
>>
>>     As an example of what?
>
>;-)

     Exactly.

>As an example of either or both of the points I was trying to make.
>
>UK post codes are pretty complex -- much more so than they look (e.g. see:
>    http://en.wikipedia.org/wiki/Postcodes_in_the_United_Kingdom
>) but many programmers don't realise that at first and so expect to be able to 
>use regular expressions for (say) input validation.  A quick web search turns 
>up tons of examples of people looking for regexps for matching UK post codes.

     Canadian Postal Codes have a bit of complexity, too, but I think
that the UK system wins on that.  After checking the Wikipedia
article, it seems that the UK system is *too* complex.

     The U.S. system has some odd exceptions, too.

[snip]

Sincerely,

Gene Wirchenko

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

#20402

From	Arved Sandstrom <asandstrom2@eastlink.ca>
Date	2012-12-17 20:13 -0400
Message-ID	<czOzs.27926$tG.10328@newsfe15.iad>
In reply to	#20353

On 12/15/2012 07:54 AM, Chris Uppal wrote:
> Arne Vajhøj wrote:
>
>> The regex syntax itself is not exactly a good example of readability.
>
> This, I think, is the point.  We don't need a special String syntax to fix the
> problem with regexps -- we'd be much better off with a fixed regexp syntax.
> Something OO.  And (since this is Java) I don't think that we need be afraid of
> something verbose.
>
> Off-the-top-of-my-head (all classes and method are imaginary):
>
>      Regexp alpha = Regexp.fromList(java.lang.text.portable.Alphas);
>      alpha = alpha.or('_');
>      Regexp num = Regexp.fromList(java.lang.text.portable.Digits);
>      Regexp alphanum = alpha.or(num);
>      Regexp identifier = alpha.followedBy(alphanum.repeated());
>
> Naturally, I'd prefer something a /bit/ less verbose, but Java won't support
> that.  But even with the verbosity, I think my version is /far/ better.  It
> puts the composition of regexps into the programmer's hands which means that it
> can be approached like any other complex programming task.  Quoting/escaping
> problems go away.  Grouping (bracketing) problems go away (and become
> decoupled from the backreference concept.  Comments become trivially easy to
> add.  Various kinds of abstraction and reuse are possible.
>
>      -- chris
>
> P.S. Mind you: my /real/ opinion is that regular expressions have no place in
> production code except in the construction of scanners (for which a more
> directly-applicable implementation than standalone regexps is helpful).
> Regexps are for users to enter, or go into configuration data.  At least the
> suggestion above has the advantage -- from my point of view -- that regexps no
> longer look like "quick and easy" fixes to problems, and maybe the programmer
> would think more about whether they /actually/ solve [all of] the problem at
> hand.
>
> P.P.S  UK post codes...

No offense, Chris, but personally I find your syntax about as hard to 
follow as the JPA Criteria API. Which latter I refuse to use, even 
though I seriously dislike silent JPA provider failures when a JPQL 
string is wrong.

I don't develop my regular expressions in Java. I work them up on the 
command line using grep or sed, or in a good editor like Sublime Text. 
As others have also said, at the point where an RE is getting ridiculous 
even without Java escaping, I'll simplify with other forms of processing 
- these most likely in Java.

I think verbose is *bad*. Anything that adds to it is bad. My opinion, 
others may certainly (vociferously) disagree. OO can already suffer from 
fragmentation, where logic that solves an immediate problem is found in 
many different spots; that problem is exacerbated when any given chunk 
of code is appreciably larger than it needs to be because of extra 
verbosity. Java is already bad enough in this regard - let's not make it 
worse.

Regular expressions are *not* Java, and IMHO they are about as readable 
for what they are intended for as anything else that people could come 
up with. I don't myself think of them as a quick or easy fix to anything 
- I consider the development of a useful RE to be a mini-program project 
that may merit several hours. *If* the original problem rates it.

AHS

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

#20441

From	"Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org>
Date	2012-12-18 13:38 +0000
Message-ID	<a4SdnRPaf_N-703NnZ2dnUVZ8k-dnZ2d@bt.com>
In reply to	#20402

Arved Sandstrom wrote:

> No offense, Chris,

None taken

> but personally I find your syntax about as hard to
> follow as the JPA Criteria API. Which latter I refuse to use, even
> though I seriously dislike silent JPA provider failures when a JPQL
> string is wrong.

I think the point that I was trying to get across is not about a "better 
syntax" for regular expressions, but about moving that kind of logic out of 
syntax altogether and into programmer-domian objects and code.

So -- for me -- I don't /care/ whether it is less readable than the traditional 
ex/awk/sed-style regexp syntax.  Naturally, I'd prefer the code to be 
reasonably readable, and I'll certaily concede that the example code I came up 
with is none too expressive.  But I'm willing to put up with that given the 
limitations of Java.

(Though maybe the sort of approach to designing DSLs in terms of "plain Java" 
shown in jMock, in particular the paper:
     Evolving an Embedded Domain-Specific Language in Java
    Steve Freeman, Nat Pryce
    http://jmock.org/articles.html
could be adapted to improve the feel of the objects-only approach that I'm 
advocating.  Hmm...)

> I think verbose is *bad*. Anything that adds to it is bad. My opinion,
> others may certainly (vociferously) disagree. OO can already suffer from
> fragmentation, where logic that solves an immediate problem is found in
> many different spots; that problem is exacerbated when any given chunk
> of code is appreciably larger than it needs to be because of extra
> verbosity. Java is already bad enough in this regard - let's not make it
> worse.

Largely agreed.   (Actually agreed entirely with the exception of the 
"fragmentation" thing.)

> Regular expressions are *not* Java, and IMHO they are about as readable

My contrasting view is that regular language grammars and parsers can be 
expressed directly in object language, which gives all sorts of advantages.  So 
they /ought/ to be Java (but in the current state of affairs) are not.

Oh well...

    -- chirs

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

#20602

From	Arved Sandstrom <asandstrom2@eastlink.ca>
Date	2012-12-19 19:48 -0400
Message-ID	<SmsAs.29396$tG.18983@newsfe15.iad>
In reply to	#20441

On 12/18/2012 09:38 AM, Chris Uppal wrote:
> Arved Sandstrom wrote:
>
>> No offense, Chris,
>
> None taken
>
>> but personally I find your syntax about as hard to
>> follow as the JPA Criteria API. Which latter I refuse to use, even
>> though I seriously dislike silent JPA provider failures when a JPQL
>> string is wrong.
>
> I think the point that I was trying to get across is not about a "better
> syntax" for regular expressions, but about moving that kind of logic out of
> syntax altogether and into programmer-domian objects and code.
>
> So -- for me -- I don't /care/ whether it is less readable than the traditional
> ex/awk/sed-style regexp syntax.  Naturally, I'd prefer the code to be
> reasonably readable, and I'll certaily concede that the example code I came up
> with is none too expressive.  But I'm willing to put up with that given the
> limitations of Java.
>
> (Though maybe the sort of approach to designing DSLs in terms of "plain Java"
> shown in jMock, in particular the paper:
>       Evolving an Embedded Domain-Specific Language in Java
>      Steve Freeman, Nat Pryce
>      http://jmock.org/articles.html
> could be adapted to improve the feel of the objects-only approach that I'm
> advocating.  Hmm...)

As far as syntax goes, things that work for me are Linq (most any 
flavour) or Scala Squeryl. Nothing's perfect, but Linq for XML or 
Squeryl achieve a nice mix of readability, conciseness and safety. 
That's just me - I know folks that can't wrap their heads around 
syntaxes like that.

I'll be honest - I have little interest in trying to improve Java along 
these lines anymore. I like Java for GP programming, but for certain 
things I'll solve the problem in another JVM language and call that code 
from Java.

>> I think verbose is *bad*. Anything that adds to it is bad. My opinion,
>> others may certainly (vociferously) disagree. OO can already suffer from
>> fragmentation, where logic that solves an immediate problem is found in
>> many different spots; that problem is exacerbated when any given chunk
>> of code is appreciably larger than it needs to be because of extra
>> verbosity. Java is already bad enough in this regard - let's not make it
>> worse.
>
> Largely agreed.   (Actually agreed entirely with the exception of the
> "fragmentation" thing.)

Well, that's an entire other debate, fragmentation caused by OOP. :-)

>> Regular expressions are *not* Java, and IMHO they are about as readable
>
> My contrasting view is that regular language grammars and parsers can be
> expressed directly in object language, which gives all sorts of advantages.  So
> they /ought/ to be Java (but in the current state of affairs) are not.
>
> Oh well...
>
>      -- chirs
>
>
AHS

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

#20506

From	Arne Vajhøj <arne@vajhoej.dk>
Date	2012-12-18 21:07 -0500
Message-ID	<50d1216e$0$287$14726298@news.sunsite.dk>
In reply to	#20353

On 12/15/2012 6:54 AM, Chris Uppal wrote:
> Off-the-top-of-my-head (all classes and method are imaginary):
>
>      Regexp alpha = Regexp.fromList(java.lang.text.portable.Alphas);
>      alpha = alpha.or('_');
>      Regexp num = Regexp.fromList(java.lang.text.portable.Digits);
>      Regexp alphanum = alpha.or(num);
>      Regexp identifier = alpha.followedBy(alphanum.repeated());

I think that is what is widely known in the .NET world
as a fluent API.

Arne

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

#20526

From	BGB <cr88192@hotmail.com>
Date	2012-12-19 08:26 -0600
Message-ID	<kasivf$d8h$1@news.albasani.net>
In reply to	#20506

On 12/18/2012 8:07 PM, Arne Vajhøj wrote:
> On 12/15/2012 6:54 AM, Chris Uppal wrote:
>> Off-the-top-of-my-head (all classes and method are imaginary):
>>
>>      Regexp alpha = Regexp.fromList(java.lang.text.portable.Alphas);
>>      alpha = alpha.or('_');
>>      Regexp num = Regexp.fromList(java.lang.text.portable.Digits);
>>      Regexp alphanum = alpha.or(num);
>>      Regexp identifier = alpha.followedBy(alphanum.repeated());
>
> I think that is what is widely known in the .NET world
> as a fluent API.
>

better term maybe than "big pile o' nasty...".

yes, regex syntax could be nicer, but probably not by making it into a 
big pile of API calls.


maybe something more EBNF-like can be used, like say:
SyntaxPattern pat = new SyntaxPattern(
	"alpha = ('A'-'Z') | ('a'-'z');"
	"alpha2 = alpha | '_';",
	"hexalpha = ('A'-'F') | ('a'-'f');"
	"num = ('0'-'9');",
	"hexnum = num | hexalpha;",
	"alphanum = alpha2 | num;",
	"basenumber = num+;",
	"realnumber = basenumber '.' basenumber ['e' basenumber ];",
	"hexnumber = '0x' hexnum+;",
	"integer = basenumber | hexnumber;",
	"identifier = alpha2 alphanum*;",
	...);

StringReader strr = new StringReader("foo 999 bar69");
String tok;
...
if(pat.match(strr, "identifier"))
{
	tok=pat.readNext(strr, "identifier");
	...
}

or:
tok=pat.tryMatchRead(strr, "identifier");
if(tok!=null)
{
	...
}

or:
SyntaxParser parse = new SyntaxParser(strr, pat);
tok=parse.tryMatchRead("identifier");
if(tok!=null)
{
	...
}
tok=parse.tryMatchRead("integer");
if(tok!=null)
{
	...
}


granted, yes, all this is probably something a bit different than using 
regexes, but oh well.


or something...

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

Page 2 of 8 — ← Prev page 1 [2] 3 4 5 6 7 8 Next page →

csiph-web

multi-line Strings

Contents

#20248

#20255

#20260

#20261

#20241

#20262

#20343

#20351

#20353

#20359

#20384

#20440

#20387

#20445

#20451

#20402

#20441

#20602

#20506

#20526