Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.java.programmer > #24417 > unrolled thread
| Started by | rajbhaumik@gmail.com |
|---|---|
| First post | 2013-06-15 13:38 -0700 |
| Last post | 2013-06-18 04:06 -0400 |
| Articles | 20 on this page of 103 — 16 participants |
Back to article view | Back to comp.lang.java.programmer
About java program. rajbhaumik@gmail.com - 2013-06-15 13:38 -0700
Re: About java program. Arne Vajhøj <arne@vajhoej.dk> - 2013-06-15 16:50 -0400
Re: About java program. Robert Klemme <shortcutter@googlemail.com> - 2013-06-16 01:12 +0200
Re: About java program. lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-06-16 14:21 +0100
Re: About java program. Robert Klemme <shortcutter@googlemail.com> - 2013-06-16 17:28 +0200
Re: About java program. lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-06-16 19:52 +0100
Re: About java program. Arne Vajhøj <arne@vajhoej.dk> - 2013-06-16 15:50 -0400
Re: About java program. lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-06-17 09:36 +0100
Re: About java program. Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-06-17 09:49 -0300
Re: About java program. lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-06-17 14:46 +0100
Re: About java program. Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-06-17 13:32 -0300
Re: About java program. Joerg Meier <joergmmeier@arcor.de> - 2013-06-17 20:32 +0200
Re: About java program. Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-06-17 14:49 -0400
Re: About java program. Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-06-17 18:38 -0300
Re: About java program. Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-06-17 18:30 -0400
Re: About java program. Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-06-18 17:33 -0300
Re: About java program. Arne Vajhøj <arne@vajhoej.dk> - 2013-07-04 22:56 -0400
Re: About java program. Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2013-06-18 00:13 +0200
Re: About java program. Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-06-18 17:50 -0300
Re: About java program. lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-06-19 08:50 +0100
Re: About java program. Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-06-19 15:16 -0300
Re: About java program. Lew <lewbloch@gmail.com> - 2013-06-19 16:20 -0700
Re: About java program. Jeff Higgins <jeff@invalid.invalid> - 2013-07-07 13:31 -0400
Re: About java program. Jeff Higgins <jeff@invalid.invalid> - 2013-07-07 18:16 -0400
Re: About java program. Jeff Higgins <jeff@invalid.invalid> - 2013-07-07 19:21 -0400
Re: About java program. Jeff Higgins <jeff@invalid.invalid> - 2013-07-07 20:07 -0400
Re: About java program. Jeff Higgins <jeff@invalid.invalid> - 2013-07-07 20:21 -0400
Re: About java program. Jeff Higgins <jeff@invalid.invalid> - 2013-07-07 20:40 -0400
Re: About java program. Jeff Higgins <jeff@invalid.invalid> - 2013-07-07 22:20 -0400
Re: About java program. Lew <lewbloch@gmail.com> - 2013-07-07 21:47 -0700
Re: About java program. Jeff Higgins <jeff@invalid.invalid> - 2013-07-08 06:58 -0400
Re: About java program. Jeff Higgins <jeff@invalid.invalid> - 2013-07-08 08:07 -0400
Re: About java program. Jeff Higgins <jeff@invalid.invalid> - 2013-07-08 08:58 -0400
Re: About java program. Jeff Higgins <jeff@invalid.invalid> - 2013-07-08 09:18 -0400
Re: About java program. Jeff Higgins <jeff@invalid.invalid> - 2013-07-08 09:47 -0400
Re: About java program. Jeff Higgins <jeff@invalid.invalid> - 2013-07-08 10:07 -0400
Re: About java program. Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2013-06-19 16:42 +0200
Re: About java program. Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-06-20 23:33 -0300
Re: About java program. Martin Gregorie <martin@address-in-sig.invalid> - 2013-06-21 04:16 +0000
Re: About java program. Joerg Meier <joergmmeier@arcor.de> - 2013-06-21 12:27 +0200
Re: About java program. Martin Gregorie <martin@address-in-sig.invalid> - 2013-06-21 21:14 +0000
Re: About java program. Joerg Meier <joergmmeier@arcor.de> - 2013-06-21 23:37 +0200
Re: About java program. Martin Gregorie <martin@address-in-sig.invalid> - 2013-06-21 23:42 +0000
Re: About java program. Gene Wirchenko <genew@telus.net> - 2013-06-24 13:00 -0700
Re: About java program. Martin Gregorie <martin@address-in-sig.invalid> - 2013-06-24 21:29 +0000
Re: About java program. Martin Gregorie <martin@address-in-sig.invalid> - 2013-06-24 21:42 +0000
Re: About java program. Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-06-21 23:59 -0300
Re: About java program. Martin Gregorie <martin@address-in-sig.invalid> - 2013-06-22 13:30 +0000
Re: About java program. Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2013-06-21 16:24 +0200
Re: About java program. Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-06-21 22:39 -0300
Re: About java program. Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2013-06-22 19:25 +0200
Re: About java program. lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-06-22 19:41 +0100
Re: About java program. Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2013-06-23 03:53 +0200
Re: About java program. lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-06-23 09:21 +0100
Re: About java program. Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2013-06-24 18:57 +0200
Re: About java program. lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-06-24 18:14 +0100
Re: About java program. lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-06-22 09:03 +0100
Re: About java program. Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2013-06-22 19:26 +0200
Re: About java program. lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-06-22 18:51 +0100
Re: About java program. Arne Vajhøj <arne@vajhoej.dk> - 2013-07-04 22:58 -0400
Re: About java program. Joerg Meier <joergmmeier@arcor.de> - 2013-06-19 00:38 +0200
Re: About java program. Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-06-18 18:56 -0400
Re: About java program. Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-06-18 21:26 -0300
Re: About java program. Robert Klemme <shortcutter@googlemail.com> - 2013-06-19 21:20 +0200
Re: About java program. Sven Köhler <remove-sven.koehler@gmail.com> - 2013-06-20 11:23 +0300
Re: About java program. Robert Klemme <shortcutter@googlemail.com> - 2013-06-20 19:18 +0200
Re: About java program. blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2013-07-15 20:20 +0000
Re: About java program. lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-06-19 09:14 +0100
Re: About java program. lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-06-19 09:11 +0100
Re: About java program. Arne Vajhøj <arne@vajhoej.dk> - 2013-07-04 23:11 -0400
Re: About java program. lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-07-05 09:13 +0100
Re: About java program. Robert Klemme <shortcutter@googlemail.com> - 2013-07-05 23:15 +0200
Re: About java program. Arne Vajhøj <arne@vajhoej.dk> - 2013-07-05 22:03 -0400
Re: About java program. Robert Klemme <shortcutter@googlemail.com> - 2013-07-06 13:01 +0200
Re: About java program. lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-07-06 13:43 +0100
Re: About java program. Martin Gregorie <martin@address-in-sig.invalid> - 2013-07-06 14:17 +0000
Re: About java program. Arne Vajhøj <arne@vajhoej.dk> - 2013-07-06 16:18 -0400
Re: About java program. lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-07-06 21:42 +0100
Re: About java program. lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-07-06 09:16 +0100
Re: About java program. Robert Klemme <shortcutter@googlemail.com> - 2013-07-06 13:14 +0200
Re: About java program. Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-07-06 08:22 -0400
Re: About java program. Robert Klemme <shortcutter@googlemail.com> - 2013-07-07 20:43 +0200
Re: About java program. Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-07-07 18:07 -0400
Re: About java program. Arne Vajhøj <arne@vajhoej.dk> - 2013-07-07 19:35 -0400
Re: About java program. Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-07-07 20:42 -0400
Re: About java program. Robert Klemme <shortcutter@googlemail.com> - 2013-07-08 20:50 +0200
Re: About java program. Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-07-08 15:01 -0400
Re: About java program. Robert Klemme <shortcutter@googlemail.com> - 2013-07-08 23:29 +0200
Re: About java program. Arne Vajhøj <arne@vajhoej.dk> - 2013-07-06 16:27 -0400
Re: About java program. Lew <lewbloch@gmail.com> - 2013-07-06 13:41 -0700
Re: About java program. Arne Vajhøj <arne@vajhoej.dk> - 2013-07-05 21:59 -0400
Re: About java program. lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-06-17 21:06 +0100
Re: About java program. Joshua Cranmer 🐧 <Pidgeot18@verizon.invalid> - 2013-06-17 17:36 -0500
Re: About java program. Robert Klemme <shortcutter@googlemail.com> - 2013-06-18 08:24 +0200
Re: About java program. lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-06-18 09:03 +0100
Re: About java program. Joshua Cranmer 🐧 <Pidgeot18@verizon.invalid> - 2013-06-18 13:07 -0500
Re: About java program. Lew <lewbloch@gmail.com> - 2013-06-18 14:48 -0700
Re: About java program. lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-06-19 08:36 +0100
Re: About java program. Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-06-18 23:33 -0300
Re: About java program. lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-06-19 08:34 +0100
Re: About java program. Arne Vajhøj <arne@vajhoej.dk> - 2013-07-04 22:53 -0400
Re: About java program. Roedy Green <see_website@mindprod.com.invalid> - 2013-06-16 07:04 -0700
Re: About java program. Jeff Higgins <jeff@invalid.invalid> - 2013-06-18 04:06 -0400
Page 3 of 6 — ← Prev page 1 2 [3] 4 5 6 Next page →
| From | Martin Gregorie <martin@address-in-sig.invalid> |
|---|---|
| Date | 2013-06-21 21:14 +0000 |
| Message-ID | <kq2fnu$osv$1@dont-email.me> |
| In reply to | #24496 |
On Fri, 21 Jun 2013 12:27:49 +0200, Joerg Meier wrote:
> On Fri, 21 Jun 2013 04:16:32 +0000 (UTC), Martin Gregorie wrote:
>
>> [...]
>
>> days = gdatebin(String.format("%02d/%02d/%02d",day, month, year));
>> return gbindate(days - 1);
>> }
>
>> ... and wasn't much longer in assembler.
>
>> gdatebin() converted a date string into binary days since 31/12/1899
>> and gbindate() did the reverse. I have no idea why the bloke thought
>> his mess of assembler would fall over after Feb 2100: the 1900 held
>> dates in a signed 24 bit number, so its Y2K moment isn't due until some
>> time in 24866 AD.
>
> It's ironic that after all that, your algorithm would have failed on Y2K
> ;)
>
How do you work that out?
I omitted the century in the interst of historical accuracy: when I wrote
the COBOL version back in the very early 70s, nobody ever used it[1]. But
the code would work correctly: if you convert 31/12/1999 to days since a
base date (31/12/1899 is as good as any), add one to it and convert the
result back to a character string you get 01/01/2000 which, if you omit
the century, becomes 01/01/00 which is the correct result.
Admittedly, without using a 4 digit year it would eventually have got the
end of February wrong but, since 2000 was a leap year, the first of these
mistakes would only have shown up in Feb 2100 since the leap years during
a century, e.g. 1904 to 1998 and 2004 to 2098 are always the same.
However, if a four digit year is used so the method knows whether the
first year of the century is a leap year or not, then my algorithm is
correct over the range I originally stated.
**Lightbulb moment: thanks for making me think that through.
Now I understand the nameless spaghetti coder's "Works until Feb 2100"
comment, though I won't begin to guess whether, like my method, his would
have been permanently fixed by simply using a four digit year.
However you apparently missed my obvious mistake, which I thought
somebody would comment on:
int month = today.substring(3,2);
should, of course, have been:
int month = today.substring(3,2) + 1;
Since the idea was to change, say, 21/06/13 to 01/07/13 which, when you
convert it to days since a base date, subtract one and convert it back
will give you 30/06/13, the desired result.
[1] Four digit dates on the late '60s and early '70s.
There was a curious blind spot about including the century in dates back
then, partly due to hardware limitations and partly aided and abetted by
the COBOL language specification.
COBOL required the receiving field in an "ACCEPT field FROM DATE."
statement could only be a 6 digit non-computational field, i.e. exactly 6
characters long and that the received date would be in the form "yymmdd".
There was no provision for accepting a century, at least as late as the
mid '80s, and apparently in IBM COBOL/400 as late as 2006, though I see
that by 2010 their mainframe COBOL used four digit dates. The same
applied to Julian dates ("ACCEPT field FROM DAY" which returned
"yyddd").
Early hardware was expensive and physically large, but very limited in
capability. In the early days saving storage and clock cycles was all-
important. In the 60s and early 70s a small mainframe might have as
little as 16 KB of ferrite core RAM, a clock speed of 12uS (30K
instructions/sec) and stored its data on 1200 or 2400 foot magnetic tapes
at 556 bits/inch, i.e. 8 Mb or 16 MB per reel at the outside. Here I'm
thinking about the ICL 1901, which is what I learnt to write assembler on.
Consequently, you didn't bother with storing the century unless you
really had to, e.g. you had people on file with birthdays in the previous
century.
--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |
[toc] | [prev] | [next] | [standalone]
| From | Joerg Meier <joergmmeier@arcor.de> |
|---|---|
| Date | 2013-06-21 23:37 +0200 |
| Message-ID | <11vzgu1flpfc0$.fjdyohv4dmbv.dlg@40tude.net> |
| In reply to | #24500 |
On Fri, 21 Jun 2013 21:14:39 +0000 (UTC), Martin Gregorie wrote:
> On Fri, 21 Jun 2013 12:27:49 +0200, Joerg Meier wrote:
>> On Fri, 21 Jun 2013 04:16:32 +0000 (UTC), Martin Gregorie wrote:
>>> [...]
>>> days = gdatebin(String.format("%02d/%02d/%02d",day, month, year));
>>> return gbindate(days - 1);
>>> }
>>> ... and wasn't much longer in assembler.
>>> gdatebin() converted a date string into binary days since 31/12/1899
>>> and gbindate() did the reverse. I have no idea why the bloke thought
>>> his mess of assembler would fall over after Feb 2100: the 1900 held
>>> dates in a signed 24 bit number, so its Y2K moment isn't due until some
>>> time in 24866 AD.
>> It's ironic that after all that, your algorithm would have failed on Y2K
>> ;)
> How do you work that out?
I must apologize for prompting this long (but interesting) post based on a
mistake on my part: my sleep-deprived brain forgot about that pesky 400
year thing affecting 2000. That seems to happen a lot to my posts here
lately. In other words: my bad, I see nothing wrong (other than the +1
thing).
Liebe Gruesse,
Joerg
--
Ich lese meine Emails nicht, replies to Email bleiben also leider
ungelesen.
[toc] | [prev] | [next] | [standalone]
| From | Martin Gregorie <martin@address-in-sig.invalid> |
|---|---|
| Date | 2013-06-21 23:42 +0000 |
| Message-ID | <kq2oct$osv$5@dont-email.me> |
| In reply to | #24501 |
On Fri, 21 Jun 2013 23:37:59 +0200, Joerg Meier wrote:
> On Fri, 21 Jun 2013 21:14:39 +0000 (UTC), Martin Gregorie wrote:
>
>> On Fri, 21 Jun 2013 12:27:49 +0200, Joerg Meier wrote:
>>> On Fri, 21 Jun 2013 04:16:32 +0000 (UTC), Martin Gregorie wrote:
>>>> [...]
>
>>>> days = gdatebin(String.format("%02d/%02d/%02d",day, month,
>>>> year));
>>>> return gbindate(days - 1);
>>>> }
>
>>>> ... and wasn't much longer in assembler.
>
>>>> gdatebin() converted a date string into binary days since 31/12/1899
>>>> and gbindate() did the reverse. I have no idea why the bloke thought
>>>> his mess of assembler would fall over after Feb 2100: the 1900 held
>>>> dates in a signed 24 bit number, so its Y2K moment isn't due until
>>>> some time in 24866 AD.
>>> It's ironic that after all that, your algorithm would have failed on
>>> Y2K ;)
>> How do you work that out?
>
> I must apologize for prompting this long (but interesting) post based on
> a mistake on my part: my sleep-deprived brain forgot about that pesky
> 400 year thing affecting 2000. That seems to happen a lot to my posts
> here lately. In other words: my bad, I see nothing wrong (other than the
> +1 thing).
>
No problem and no apology needed.
It was fun delving back into the early days.
FWIW, I've always liked block structured languages, probably because I
first learned to program on an Ellott 503 in Algol 60 about 1967.
Interesting beast: it had 8K of 39 bit words and another 16Kwords of
slower ferrite core that it used as a sort of fast disk. It just preceded
integrated circuits: its logic was built with discrete transistors and
was a true scientific computer: its floating point divide was faster than
its integer divide. With the long 39 bit word it had no double length
arithmetic (didn't need it!) and it stored two instructions per word: the
spare bit determined whether the first instruction modified the second or
not. We programmed in on paper tape using a Flexowriter (much superior
to a teletype, as it had a huge array of symbols as well as both cases
and underline (Ellott Algol underlined reserved words. Output was either
on a big, fast line printer or more paper tape.
The machine was surprisingly fast: everything we did on it was compile
and go from paper tape, but despite that and a 3 minute testing slot, you
could easily compile your program and get a useful bit of data crunching
done within the three minute period.
In fact a year or two later I was sysadmin on an ICL 1903S with 60 MB
disks as well as loads of tapes etc. It ran George 3, one of the earliest
true multi-user, multi-tasking operation systems, but no matter what I
tried with that and despite keeping my source on disk (of course) and not
printing the compiler listings etc. I never was able to match the
compilation speed of that old Elliott 503 despite it reading the program
off a 1250 cps tape reader and printing the compiler listings direct to
the (guessed) 600 lpm line printer.
--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |
[toc] | [prev] | [next] | [standalone]
| From | Gene Wirchenko <genew@telus.net> |
|---|---|
| Date | 2013-06-24 13:00 -0700 |
| Message-ID | <i89hs8p13bde92qjtudd1ajehin9eqq7fa@4ax.com> |
| In reply to | #24500 |
On Fri, 21 Jun 2013 21:14:39 +0000 (UTC), Martin Gregorie
<martin@address-in-sig.invalid> wrote:
[snip]
>Consequently, you didn't bother with storing the century unless you
>really had to, e.g. you had people on file with birthdays in the previous
>century.
In alt.folklore.computers, I have read posts by people who have
stated that there wre programs that had only one digit for year and
when the 1970's started, the report programs had to be updated.
Sincerely,
Gene Wirchenko
[toc] | [prev] | [next] | [standalone]
| From | Martin Gregorie <martin@address-in-sig.invalid> |
|---|---|
| Date | 2013-06-24 21:29 +0000 |
| Message-ID | <kqadoc$2vs$4@dont-email.me> |
| In reply to | #24524 |
On Mon, 24 Jun 2013 13:00:38 -0700, Gene Wirchenko wrote: > On Fri, 21 Jun 2013 21:14:39 +0000 (UTC), Martin Gregorie > <martin@address-in-sig.invalid> wrote: > > [snip] > >>Consequently, you didn't bother with storing the century unless you >>really had to, e.g. you had people on file with birthdays in the >>previous century. > > In alt.folklore.computers, I have read posts by people who have > stated that there wre programs that had only one digit for year and when > the 1970's started, the report programs had to be updated. > I saw a note about that quite recently, but have never seen one myself. OTOH, I did see a payroll master file in which the century part of the employee birth date was an after-market patch (and probably after-take-on too). This ran in an ICL 1900 mainframe. To briefly recap, the standard 1900 date was stored internally as a 24 bit signed integer, based on day zero being 31Dec1899. The 1900 architecture was based round 24 bit words, each of which could hold 4 six-bit ISO characters and used two-shift character encoding, so using a word to hold dates made a lot of sense, but, although this allowed a date range of around 1670 AD to 2330 AD, the ICL subroutines for converting between binary and human-readable dates did not handle centuries: dates could only be formatted as dd/mm/yy. But I digress... One more fact: ICL 1900 tape and disk records were always variable length, so the first word in the record contained the record length (in words) in its lowest 12 bits as an unsigned integer. The upper 12 bits were unused.... You can see where this is going, can't you! Yep, the century was held as two characters stored in the top 12 bits of the record length word (either '18' or '19') and extracted from the employee's birth date as part of the process of reading input data from a punched card or inserted when printing payslips, reports etc. -- martin@ | Martin Gregorie gregorie. | Essex, UK org |
[toc] | [prev] | [next] | [standalone]
| From | Martin Gregorie <martin@address-in-sig.invalid> |
|---|---|
| Date | 2013-06-24 21:42 +0000 |
| Message-ID | <kqaegr$bdc$1@dont-email.me> |
| In reply to | #24525 |
On Mon, 24 Jun 2013 21:29:48 +0000, Martin Gregorie wrote: > but, although this allowed a date range of around 1670 AD to 2330 AD, > should, of course, be 21066 BC to 24866 AD -- martin@ | Martin Gregorie gregorie. | Essex, UK org |
[toc] | [prev] | [next] | [standalone]
| From | Arved Sandstrom <asandstrom2@eastlink.ca> |
|---|---|
| Date | 2013-06-21 23:59 -0300 |
| Message-ID | <Gq8xt.62041$5i1.57182@newsfe15.iad> |
| In reply to | #24494 |
On 06/21/2013 01:16 AM, Martin Gregorie wrote:
> On Thu, 20 Jun 2013 23:33:56 -0300, Arved Sandstrom wrote:
>
>> It's a good discussion. I'm not personally convinced that verbosity adds
>> complexity, as a rule. There's really two types of complexity here:
>> maintainability complexity - as in, can Joe Blow 12 months later
>> understand the code best if it's compact versus unrolled, and formal
>> complexity, cyclomatic and otherwise.
>>
> I'm with you there.
>
>> I'll admit that verbosity does usually add maintainability complexity,
>>
> My attitude is that well-laid out code with well-thought out names and
> intelligently commented offers about the best chance of being more easily
> maintainable. I prefer blocks of well formatted and carefully written
> comments places ahead of what they describe to any other type.
>
>> if not the other kind. But not always. I've seen plenty of code that is
>> conceptually quite complex but very terse.
>>
> I've certainly see some memorable examples of badly documented and over-
> clever code in the past.
>
> One of my favourite examples of bad documentation was actually quite good
> code: it was just the commenting style that was naff. This was MC 6800
> assembler, and the house style was to add a comment alongside every
> instruction whether it needed it or not: the machine had INC and DEC
> instructions to and or subtract 1 from a register, but did it really add
> anything the write "BUMP THE B REGISTER" alongside every INC B
> instruction?
>
> As it happens, my worst ever example was also assembler: this time PLAN 3
> assembler for an ICL 1900. In this case it was a lineprinter page, i.e.
> about 60 instructions whose task was the work out the date of the last
> day of the current month so it could be printed on financial statements.
> it worked by doing arithmetic on the current date in "dd/mm/yy" format
> This page has two comments: the first said "Calculate the last day of the
> month" and the second said "Works until Feb 2100". The rest of the page
> contained a mess of register-to-register operations and relative
> branches. There wasn't a single label or variable name in the whole mess.
> I never met anybody who could follow it past its first dozen steps - and
> that includes me - and I used to be fairly good at programming in PLAN.
>
> The silly thing was that the date calculation was trivial on a 1900,
> which held dates internally as days since 31 Dec 1899 and provided a set
> of date manipulation subroutines. The obvious solution, given that
> library, and writing the routine in pseudo-Java in deference to this 'ere
> august forum, looks like this:
>
> public String lastDayOfMonth(String today)
> {
> int day = 1;
> int month = today.substring(3,2);
> int year = today.substring(6);
> if (month > 12)
> {
> year++;
> month = 1;
> }
>
> days = gdatebin(String.format("%02d/%02d/%02d",day, month, year));
> return gbindate(days - 1);
> }
>
> ... and wasn't much longer in assembler.
>
> gdatebin() converted a date string into binary days since 31/12/1899 and
> gbindate() did the reverse. I have no idea why the bloke thought his mess
> of assembler would fall over after Feb 2100: the 1900 held dates in a
> signed 24 bit number, so its Y2K moment isn't due until some time in
> 24866 AD.
>
> And, yes, I do know my algorithm worked correctly despite leap years and
> all: it ran for years as part of an accounting package and anybody could
> see exactly how it worked even though it was written in COBOL.
>
>
Ahhh, dates. :-) Just this last fall had to bypass front ends for a
mainstream financial system and get at the DB directly. No docs worth a
damn, not even a good data dictionary for the database, so I had to use
the front end programs to generate DB activity of the sort I wanted
while I ran a SQL Server profiler trace. I cleaned up the trace and
looked at the dates...what is this, I thought? Integer numbers in the
seven hundred thousands. It took a bit of sleuthing to find out that it
was rata die dates.
There is no clean way of doing rata die <-> java.util.Calendar
conversions. And that nasty little 0.5 day floating point adjustment is
a bugger. It's only now after 9 months of production that I have a warm
fuzzy about the thing being solid.
AHS
--
When a true genius appears, you can know him by this sign:
that all the dunces are in a confederacy against him.
-- Jonathan Swift
[toc] | [prev] | [next] | [standalone]
| From | Martin Gregorie <martin@address-in-sig.invalid> |
|---|---|
| Date | 2013-06-22 13:30 +0000 |
| Message-ID | <kq48td$9qk$1@dont-email.me> |
| In reply to | #24508 |
On Fri, 21 Jun 2013 23:59:41 -0300, Arved Sandstrom wrote: > Ahhh, dates. :-) Just this last fall had to bypass front ends for a > mainstream financial system and get at the DB directly. No docs worth a > damn, not even a good data dictionary for the database, so I had to use > the front end programs to generate DB activity of the sort I wanted > while I ran a SQL Server profiler trace. I cleaned up the trace and > looked at the dates...what is this, I thought? Integer numbers in the > seven hundred thousands. It took a bit of sleuthing to find out that it > was rata die dates. > Thats interesting: there are evidently scads of different (and mutually incompatible date representations of this type. Previously I knew about four (listed in the order I learnt about them): - the proprietary 'ICL 1900 date', based on 31/12/1899 and enumerated in 24 bit signed integers, so the time is a separate issue and with its rollover event ocurring in 24866 AD. - the proprietary 'ICL 2900 date, held as as signed 64 bit integer and enumerated in microseconds, so includes the time. I've never known what the base date was but its scarcely relevant since it will only roll over after 292271 years. - the 'Julian Day', based on noon GMT on January 1, 4713 BC and enumerated as days held as a real number with the fractional part representing the time of day. The base date comes from the Julian calendar. - the UNIX data, held in 32 bits and enumerated in seconds since 00:00 on 01/01/1970 with a rollover in 2038. It also turns out that the format that IBM calls the 'Julian Date' (yyddd) isn't the same as the Julian Day. And now there's 'rata die' which I'd not previously heard of. It is similar to the Julian Day except that it is based on midnight in the local time zone on the 1st of Jan, 1AD. It is held as a real number, with the fractional part representing the time of day. However, there are variants: the second uses integers to represent whole days, i.e. its the first form with the fractional part discarded, and the third is also an integer, but defined to represent midday. > There is no clean way of doing rata die <-> java.util.Calendar > conversions. And that nasty little 0.5 day floating point adjustment is > a bugger. It's only now after 9 months of production that I have a warm > fuzzy about the thing being solid. > I'm not surprised. In fact there's no clean way to convert an arbitrary historic date to any of these representations or to a Gregorian date without using a lookup table holding the discontinuities and corrections that have been applied to all human calendars at some time or other. And, it you want to convert times, where they are known, as well it just turns into a can of worms before the invention of the railway and the introduction of the railway timetable. -- martin@ | Martin Gregorie gregorie. | Essex, UK org |
[toc] | [prev] | [next] | [standalone]
| From | Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> |
|---|---|
| Date | 2013-06-21 16:24 +0200 |
| Message-ID | <kq1nda$fbk$1@dont-email.me> |
| In reply to | #24493 |
On 21/06/2013 04:33, Arved Sandstrom allegedly wrote: > On 06/19/2013 11:42 AM, Daniele Futtorovic wrote: >> I'm all for defensive programming, but I think that there's a limit >> where it can be on the verge of silliness, and that that limit has been >> grazed here. >> >> Less-than-bright programmers IMO cannot be a justification for crossing >> that line; less-than-bright programmers have more ways to mess things up >> than you could possibly ever guard against. "Do not underestimate the >> ingenuity of complete fools", as the saying goes. >> >> And for me, there is an additional aspect: if a piece of code does >> something simple, something basic, then I will want it to be short, and >> vice-versa. Verbosity of code, to me, should hold a first-glance >> indication of the complexity of the algorithm. In other words: be terse >> IFF it's basic, be verbose IFF it's not. >> >> Perhaps your mileage does vary. No beef with that. Just throwing in my >> two cents. >> > It's a good discussion. I'm not personally convinced that verbosity adds > complexity, as a rule. There's really two types of complexity here: > maintainability complexity - as in, can Joe Blow 12 months later > understand the code best if it's compact versus unrolled, and formal > complexity, cyclomatic and otherwise. > > I'll admit that verbosity does usually add maintainability complexity, > if not the other kind. But not always. I've seen plenty of code that is > conceptually quite complex but very terse. Sorry to nitpick, but I don't think you understood me right. I'm not saying that verbosity adds complexity; I'm saying: if the piece of code does something tricky, something complicated, tend to make it verbose, otherwise, tend to make it terse. Thus, seeing a big blob of (e.g. unrolled, step-by-step) code holds the message "here be dragons". (And if it cannot be made verbose, then it means it absolutely requires an in-line comment). At least the way I perceived it, this discussion was about making stuff verbose indiscriminately, viz. basic code as well. I disagree with that in the above sense. -- DF.
[toc] | [prev] | [next] | [standalone]
| From | Arved Sandstrom <asandstrom2@eastlink.ca> |
|---|---|
| Date | 2013-06-21 22:39 -0300 |
| Message-ID | <lf7xt.83078$1p2.22506@newsfe25.iad> |
| In reply to | #24498 |
On 06/21/2013 11:24 AM, Daniele Futtorovic wrote: > On 21/06/2013 04:33, Arved Sandstrom allegedly wrote: >> On 06/19/2013 11:42 AM, Daniele Futtorovic wrote: >>> I'm all for defensive programming, but I think that there's a limit >>> where it can be on the verge of silliness, and that that limit has been >>> grazed here. >>> >>> Less-than-bright programmers IMO cannot be a justification for crossing >>> that line; less-than-bright programmers have more ways to mess things up >>> than you could possibly ever guard against. "Do not underestimate the >>> ingenuity of complete fools", as the saying goes. >>> >>> And for me, there is an additional aspect: if a piece of code does >>> something simple, something basic, then I will want it to be short, and >>> vice-versa. Verbosity of code, to me, should hold a first-glance >>> indication of the complexity of the algorithm. In other words: be terse >>> IFF it's basic, be verbose IFF it's not. >>> >>> Perhaps your mileage does vary. No beef with that. Just throwing in my >>> two cents. >>> >> It's a good discussion. I'm not personally convinced that verbosity adds >> complexity, as a rule. There's really two types of complexity here: >> maintainability complexity - as in, can Joe Blow 12 months later >> understand the code best if it's compact versus unrolled, and formal >> complexity, cyclomatic and otherwise. >> >> I'll admit that verbosity does usually add maintainability complexity, >> if not the other kind. But not always. I've seen plenty of code that is >> conceptually quite complex but very terse. > > Sorry to nitpick, but I don't think you understood me right. I'm not > saying that verbosity adds complexity; I'm saying: if the piece of code > does something tricky, something complicated, tend to make it verbose, > otherwise, tend to make it terse. Thus, seeing a big blob of (e.g. > unrolled, step-by-step) code holds the message "here be dragons". (And > if it cannot be made verbose, then it means it absolutely requires an > in-line comment). We're very much in agreement, on all points you just made. > At least the way I perceived it, this discussion was about making stuff > verbose indiscriminately, viz. basic code as well. I disagree with that > in the above sense. > I won't speak for anyone else, the argument I was making was for verbosity in support of defensive programming. I see Java code all the time where exceptions are try-caught with no thought placed into handling the problem somewhere - defensive coding fail...and handling it properly would add verbosity. I see main methods all the time where someone assumes the number and type of arguments. Defensive coding fail. I see methods all the time - like I said - where the same coder wrote the calling code and called code, and makes assumptions about what the calling code will do. Defensive coding fail. Or they make the naive assumption that people read Javadocs thoroughly. It's not the calling code's responsibility to protect the called code, after all. Given that we have to consider the bounds of parameters carefully, I don't see how some verbosity in the form of defensive code is objectionable. "Here be dragons" often means simply that there is - that we have to guard against what the calling code is doing. AHS -- When a true genius appears, you can know him by this sign: that all the dunces are in a confederacy against him. -- Jonathan Swift
[toc] | [prev] | [next] | [standalone]
| From | Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> |
|---|---|
| Date | 2013-06-22 19:25 +0200 |
| Message-ID | <kq4mdh$fbm$1@dont-email.me> |
| In reply to | #24506 |
On 22/06/2013 03:39, Arved Sandstrom allegedly wrote:
> On 06/21/2013 11:24 AM, Daniele Futtorovic wrote:
>> On 21/06/2013 04:33, Arved Sandstrom allegedly wrote:
>>> On 06/19/2013 11:42 AM, Daniele Futtorovic wrote:
>>>> I'm all for defensive programming, but I think that there's a limit
>>>> where it can be on the verge of silliness, and that that limit has been
>>>> grazed here.
>>>>
>>>> Less-than-bright programmers IMO cannot be a justification for crossing
>>>> that line; less-than-bright programmers have more ways to mess
>>>> things up
>>>> than you could possibly ever guard against. "Do not underestimate the
>>>> ingenuity of complete fools", as the saying goes.
>>>>
>>>> And for me, there is an additional aspect: if a piece of code does
>>>> something simple, something basic, then I will want it to be short, and
>>>> vice-versa. Verbosity of code, to me, should hold a first-glance
>>>> indication of the complexity of the algorithm. In other words: be terse
>>>> IFF it's basic, be verbose IFF it's not.
>>>>
>>>> Perhaps your mileage does vary. No beef with that. Just throwing in my
>>>> two cents.
>>>>
>>> It's a good discussion. I'm not personally convinced that verbosity adds
>>> complexity, as a rule. There's really two types of complexity here:
>>> maintainability complexity - as in, can Joe Blow 12 months later
>>> understand the code best if it's compact versus unrolled, and formal
>>> complexity, cyclomatic and otherwise.
>>>
>>> I'll admit that verbosity does usually add maintainability complexity,
>>> if not the other kind. But not always. I've seen plenty of code that is
>>> conceptually quite complex but very terse.
>>
>> Sorry to nitpick, but I don't think you understood me right. I'm not
>> saying that verbosity adds complexity; I'm saying: if the piece of code
>> does something tricky, something complicated, tend to make it verbose,
>> otherwise, tend to make it terse. Thus, seeing a big blob of (e.g.
>> unrolled, step-by-step) code holds the message "here be dragons". (And
>> if it cannot be made verbose, then it means it absolutely requires an
>> in-line comment).
>
> We're very much in agreement, on all points you just made.
>
>> At least the way I perceived it, this discussion was about making stuff
>> verbose indiscriminately, viz. basic code as well. I disagree with that
>> in the above sense.
>>
> I won't speak for anyone else, the argument I was making was for
> verbosity in support of defensive programming. I see Java code all the
> time where exceptions are try-caught with no thought placed into
> handling the problem somewhere - defensive coding fail...and handling it
> properly would add verbosity.
>
> I see main methods all the time where someone assumes the number and
> type of arguments. Defensive coding fail. I see methods all the time -
> like I said - where the same coder wrote the calling code and called
> code, and makes assumptions about what the calling code will do.
> Defensive coding fail.
>
> Or they make the naive assumption that people read Javadocs thoroughly.
> It's not the calling code's responsibility to protect the called code,
> after all. Given that we have to consider the bounds of parameters
> carefully, I don't see how some verbosity in the form of defensive code
> is objectionable.
>
> "Here be dragons" often means simply that there is - that we have to
> guard against what the calling code is doing.
I see. Thanks for clarifying.
It looks like I had not understood the discussion about verbosity in the
same sense as you do. In my view, when talking about verbosity, we talk
about a measure on, and that's the important point, an iso-functional
basis. To illustrate, when I switch on a "verbose" flag on my command
line, I do not expect the command to perform any differently than before
-- only that it should be more talkative about it. But the functions it
performs should not be impacted by it.
To illustrate with code, and to pick some of the original examples
again, take the following two methods:
boolean method1( String input ){
return "yes".equals( input );
}
boolean method2( String input ){
final boolean ret;
if( input == null ){
ret = false;
}
else if( input.equals("yes") ){
ret = true;
}
else {
ret = false;
}
return ret;
}
This is what I mean. Both methods perform exactly the same for any
input. The only matter in which they differ is their verbosity.
And to pick up the argument again: it could be argued that the latter
form is preferable, because it is more obvious what happens in each
case. I argue against that. Not generally, but in this case. Because
what's going on there is a very basic operation (making sure the input
is exactly the String "yes"). The second form is too verbose -- that is,
so verbose that it becomes clutter. The first (non-verbose) form
expresses the intent clearly enough. If there is a "programmer" who does
not understand that (especially the null-implication), then I'm sure Lew
would have some poignant recommendations as to what avenues of
employment they rather ought to pursue, and I would happen to be in
agreement with him.
Some of what you are talking about, on the topic of defensive
programming, on the other hand, I would call functional defects. I do
not perceive those as being matters of verbosity or not, but of whether
the code is functionally complete or not. To your hypothetical
programmer who does not handle exceptions because it would supposedly
add verbosity, "verbosity" is but a pathetic front to mask either their
lack of professionalism.
The other examples you give definitely fall in the realm of defensive
programming. Yes, a method should not make hidden assumptions as to its
parameters (OTOH there would be nothing wrong per se with what I'd call
an explicit assumption along the lines of: if( argumentNotValid ) throw
new IllegalArgumentException(); ). Yes, every caller should be defensive
about what the callee might return (within the boundaries of its
contract). It should be noted that annotations have given us a potential
tool forcibly to impose more stringency in these regards, although the
way I see it it won't really be usable until teh Oracle makes the effort
to formalise them and adds them to the core lib (I mean things like
@NotNull). It still needs to mature a bit I think.
The aforementioned is mitigated in code that is internal to a component
(in the spirit of encapsulation, code ought to be divided into
components such that the density of interrelation of code within a
component is always strictly greater than that of interrelation of code
in different components). Think private or package-private methods. It
is often impractical and counter-productive to have
to forego any hidden assumptions in those parts of the code. Then again,
it is precisely the combination of these two aspects, that it is
impractical and that it would be necessary, which makes OO and esp.
encapsulation such a virtuous tool: by structuring code and data flow,
you *can* relegate, notably, input checks to the boundaries of the
component and operate on assumptions within the component. (Granted,
this does not help the case where multiple programmers who are not in
relation with each other work on the internals of the same component,
which is why such a situation should be avoided).
--
DF.
[toc] | [prev] | [next] | [standalone]
| From | lipska the kat <"nospam at neversurrender dot co dot uk"> |
|---|---|
| Date | 2013-06-22 19:41 +0100 |
| Message-ID | <l_WdnQVSU6BKcljMnZ2dnUVZ8jOdnZ2d@bt.com> |
| In reply to | #24511 |
On 22/06/13 18:25, Daniele Futtorovic wrote:
> On 22/06/2013 03:39, Arved Sandstrom allegedly wrote:
>> On 06/21/2013 11:24 AM, Daniele Futtorovic wrote:
>>> On 21/06/2013 04:33, Arved Sandstrom allegedly wrote:
>>>> On 06/19/2013 11:42 AM, Daniele Futtorovic wrote:
>>>>> I'm all for defensive programming, but I think that there's a limit
>>>>> where it can be on the verge of silliness, and that that limit has been
>>>>> grazed here.
>>>>>
>>>>> Less-than-bright programmers IMO cannot be a justification for crossing
>>>>> that line; less-than-bright programmers have more ways to mess
>>>>> things up
>>>>> than you could possibly ever guard against. "Do not underestimate the
>>>>> ingenuity of complete fools", as the saying goes.
>>>>>
>>>>> And for me, there is an additional aspect: if a piece of code does
>>>>> something simple, something basic, then I will want it to be short, and
>>>>> vice-versa. Verbosity of code, to me, should hold a first-glance
>>>>> indication of the complexity of the algorithm. In other words: be terse
>>>>> IFF it's basic, be verbose IFF it's not.
>>>>>
>>>>> Perhaps your mileage does vary. No beef with that. Just throwing in my
>>>>> two cents.
>>>>>
>>>> It's a good discussion. I'm not personally convinced that verbosity adds
>>>> complexity, as a rule. There's really two types of complexity here:
>>>> maintainability complexity - as in, can Joe Blow 12 months later
>>>> understand the code best if it's compact versus unrolled, and formal
>>>> complexity, cyclomatic and otherwise.
>>>>
>>>> I'll admit that verbosity does usually add maintainability complexity,
>>>> if not the other kind. But not always. I've seen plenty of code that is
>>>> conceptually quite complex but very terse.
>>>
>>> Sorry to nitpick, but I don't think you understood me right. I'm not
>>> saying that verbosity adds complexity; I'm saying: if the piece of code
>>> does something tricky, something complicated, tend to make it verbose,
>>> otherwise, tend to make it terse. Thus, seeing a big blob of (e.g.
>>> unrolled, step-by-step) code holds the message "here be dragons". (And
>>> if it cannot be made verbose, then it means it absolutely requires an
>>> in-line comment).
>>
>> We're very much in agreement, on all points you just made.
>>
>>> At least the way I perceived it, this discussion was about making stuff
>>> verbose indiscriminately, viz. basic code as well. I disagree with that
>>> in the above sense.
>>>
>> I won't speak for anyone else, the argument I was making was for
>> verbosity in support of defensive programming. I see Java code all the
>> time where exceptions are try-caught with no thought placed into
>> handling the problem somewhere - defensive coding fail...and handling it
>> properly would add verbosity.
>>
>> I see main methods all the time where someone assumes the number and
>> type of arguments. Defensive coding fail. I see methods all the time -
>> like I said - where the same coder wrote the calling code and called
>> code, and makes assumptions about what the calling code will do.
>> Defensive coding fail.
>>
>> Or they make the naive assumption that people read Javadocs thoroughly.
>> It's not the calling code's responsibility to protect the called code,
>> after all. Given that we have to consider the bounds of parameters
>> carefully, I don't see how some verbosity in the form of defensive code
>> is objectionable.
>>
>> "Here be dragons" often means simply that there is - that we have to
>> guard against what the calling code is doing.
>
> I see. Thanks for clarifying.
>
> It looks like I had not understood the discussion about verbosity in the
> same sense as you do. In my view, when talking about verbosity, we talk
> about a measure on, and that's the important point, an iso-functional
> basis. To illustrate, when I switch on a "verbose" flag on my command
> line, I do not expect the command to perform any differently than before
> -- only that it should be more talkative about it. But the functions it
> performs should not be impacted by it.
>
> To illustrate with code, and to pick some of the original examples
> again, take the following two methods:
>
> boolean method1( String input ){
> return "yes".equals( input );
> }
>
> boolean method2( String input ){
> final boolean ret;
> if( input == null ){
> ret = false;
> }
> else if( input.equals("yes") ){
> ret = true;
> }
> else {
> ret = false;
> }
>
> return ret;
> }
>
> This is what I mean. Both methods perform exactly the same for any
> input. The only matter in which they differ is their verbosity.
> And to pick up the argument again: it could be argued that the latter
> form is preferable, because it is more obvious what happens in each
> case. I argue against that. Not generally, but in this case. Because
> what's going on there is a very basic operation (making sure the input
> is exactly the String "yes"). The second form is too verbose -- that is,
> so verbose that it becomes clutter. The first (non-verbose) form
> expresses the intent clearly enough. If there is a "programmer" who does
> not understand that (especially the null-implication), then I'm sure Lew
> would have some poignant recommendations as to what avenues of
> employment they rather ought to pursue, and I would happen to be in
> agreement with him.
Why am I not surprised.
> Some of what you are talking about, on the topic of defensive
> programming, on the other hand, I would call functional defects. I do
> not perceive those as being matters of verbosity or not, but of whether
> the code is functionally complete or not. To your hypothetical
> programmer who does not handle exceptions because it would supposedly
> add verbosity, "verbosity" is but a pathetic front to mask either their
> lack of professionalism.
>
> The other examples you give definitely fall in the realm of defensive
> programming. Yes, a method should not make hidden assumptions as to its
> parameters (OTOH there would be nothing wrong per se with what I'd call
> an explicit assumption along the lines of: if( argumentNotValid ) throw
> new IllegalArgumentException(); ). Yes, every caller should be defensive
> about what the callee might return (within the boundaries of its
> contract). It should be noted that annotations have given us a potential
> tool forcibly to impose more stringency in these regards, although the
> way I see it it won't really be usable until teh Oracle makes the effort
> to formalise them and adds them to the core lib (I mean things like
> @NotNull). It still needs to mature a bit I think.
>
> The aforementioned is mitigated in code that is internal to a component
> (in the spirit of encapsulation, code ought to be divided into
> components such that the density of interrelation of code within a
> component is always strictly greater than that of interrelation of code
> in different components).
You mean it should be cohesive (the code in a component), still, why use
one word when fifty will do.
as you say.
"verbosity is but a pathetic front to mask either their
lack of professionalism" [sic]
> Think private or package-private methods. It
> is often impractical and counter-productive to have
> to forego any hidden assumptions in those parts of the code.
Hidden from whom???
This is what encapsulation *means* for goodness sake. Callers code to
your published contract. You contract that your component behaves in a
certain way. If the caller breaks the contract then it's the callers
responsibility, you are stating the obvious. To what end?
> Then again, it is precisely the combination of these two aspects, that it is
> impractical and that it would be necessary, which makes OO and esp.
> encapsulation such a virtuous tool: by structuring code and data flow,
> you *can* relegate, notably, input checks to the boundaries of the
> component and operate on assumptions within the component.
It's called programming by contract. Or maybe compile time type checking
... what does any of this have to do with the original issue
> (Granted,
> this does not help the case where multiple programmers who are not in
> relation with each other work on the internals of the same component,
> which is why such a situation should be avoided).
I hardly know where to start. Oh, I know, *documentation*
What about maintenance. It will nearly always be the case that
programmers who have no knowledge of or contact with the original author
will be required to maintain the code at sometime in the future.
*This* is why code should be unambiguous. Truly enlightened developers
understand this without needing to be told.
... and BTW. Enlightenment is not the same as 'cleverness'
lipska
--
Lipska the Kat©: Troll hunter, sandbox destroyer
and farscape dreamer of Aeryn Sun
[toc] | [prev] | [next] | [standalone]
| From | Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> |
|---|---|
| Date | 2013-06-23 03:53 +0200 |
| Message-ID | <kq5k56$rqe$1@dont-email.me> |
| In reply to | #24514 |
On 22/06/2013 20:41, lipska the kat allegedly wrote: > On 22/06/13 18:25, Daniele Futtorovic wrote: >> The aforementioned is mitigated in code that is internal to a >> component (in the spirit of encapsulation, code ought to be divided >> into components such that the density of interrelation of code >> within a component is always strictly greater than that of >> interrelation of code in different components). > > You mean it should be cohesive (the code in a component), still, why > use one word when fifty will do. > > as you say. > > "verbosity is but a pathetic front to mask either their lack of > professionalism" [sic] No, I did not simply say it should be cohesive. If you want to substitute "cohesiveness" for "density of interrelation" (which is fair enough), I said it should be more cohesive within the component than between components, and that this is what characterises something as being a component. Not the same thing. But still, assuming it were the same thing for a moment (which, again, it is not by a wide stretch), do you really think that completely twisting my words, under the guise of quoting me, to proceed to advocate, for a natural and hence inexact language, a practice which you rebuke me for advocating for a computer and hence exact language is going to induce me to take you seriously? -- DF.
[toc] | [prev] | [next] | [standalone]
| From | lipska the kat <"nospam at neversurrender dot co dot uk"> |
|---|---|
| Date | 2013-06-23 09:21 +0100 |
| Message-ID | <jq-dnbtLwcyYLVvMnZ2dnUVZ7qCdnZ2d@bt.com> |
| In reply to | #24515 |
On 23/06/13 02:53, Daniele Futtorovic wrote: > On 22/06/2013 20:41, lipska the kat allegedly wrote: >> On 22/06/13 18:25, Daniele Futtorovic wrote: >>> The aforementioned is mitigated in code that is internal to a >>> component (in the spirit of encapsulation, code ought to be divided >>> into components such that the density of interrelation of code >>> within a component is always strictly greater than that of >>> interrelation of code in different components). >> >> You mean it should be cohesive (the code in a component), still, why >> use one word when fifty will do. >> >> as you say. >> >> "verbosity is but a pathetic front to mask either their lack of >> professionalism" [sic] > > No, I did not simply say it should be cohesive. If you want to > substitute "cohesiveness" for "density of interrelation" (which is fair > enough), I said it should be more cohesive within the component than > between components, and that this is what characterises something as > being a component. Not the same thing. A component is characterised by the coherence of it's abstraction expressed as the collection of related operations exposed in its interface. What goes on 'inside' a component is irrelevant to it's external clients, or should be. Normal measures of software quality still apply of course but otherwise I have no idea what you mean by 'cohesive within the component' A component is a building block. Many cohesive components can be combined to make another cohesive component. Again, the cohesion of the abstraction is characterised by the interface presented to the outside world and cohesion between components (coupling) becomes a moot point (again) as the interface is what matters. > But still, assuming it were the same thing for a moment (which, again, > it is not by a wide stretch), do you really think that completely > twisting my words, under the guise of quoting me, to proceed to > advocate, for a natural and hence inexact language, a practice which you > rebuke me for advocating for a computer and hence exact language is > going to induce me to take you seriously? What is this obsession that people on this group seem to have with being taken seriously? I couldn't care less if you 'take me seriously' I have nothing to prove to you or anyone else so please don't waste any more time on 'taking me seriously'. When you come out with complete bollocks like ... "verbosity is but a pathetic front to mask either their lack of professionalism" [sic] Then expect me to react. It's nothing personal fercrissakes. lipska -- Lipska the Kat©: Troll hunter, sandbox destroyer and farscape dreamer of Aeryn Sun
[toc] | [prev] | [next] | [standalone]
| From | Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> |
|---|---|
| Date | 2013-06-24 18:57 +0200 |
| Message-ID | <kq9tgp$8ct$1@dont-email.me> |
| In reply to | #24516 |
On 23/06/2013 10:21, lipska the kat allegedly wrote: > On 23/06/13 02:53, Daniele Futtorovic wrote: >> On 22/06/2013 20:41, lipska the kat allegedly wrote: >>> On 22/06/13 18:25, Daniele Futtorovic wrote: >>>> The aforementioned is mitigated in code that is internal to a >>>> component (in the spirit of encapsulation, code ought to be divided >>>> into components such that the density of interrelation of code >>>> within a component is always strictly greater than that of >>>> interrelation of code in different components). >>> >>> You mean it should be cohesive (the code in a component), still, why >>> use one word when fifty will do. >>> >>> as you say. >>> >>> "verbosity is but a pathetic front to mask either their lack of >>> professionalism" [sic] >> >> No, I did not simply say it should be cohesive. If you want to >> substitute "cohesiveness" for "density of interrelation" (which is fair >> enough), I said it should be more cohesive within the component than >> between components, and that this is what characterises something as >> being a component. Not the same thing. > >> But still, assuming it were the same thing for a moment (which, again, >> it is not by a wide stretch), do you really think that completely >> twisting my words, under the guise of quoting me, to proceed to >> advocate, for a natural and hence inexact language, a practice which you >> rebuke me for advocating for a computer and hence exact language is >> going to induce me to take you seriously? > > What is this obsession that people on this group seem to have with being > taken seriously? I couldn't care less if you 'take me seriously' I have > nothing to prove to you or anyone else so please don't waste any more > time on 'taking me seriously'. When you come out with complete bollocks > like ... > > "verbosity is but a pathetic front to mask either their lack of > professionalism" [sic] > > Then expect me to react. It's nothing personal fercrissakes. To conclude this discussion (as I am not inclined to debate with someone I can't take seriously), let me point out once more that that quote is the product of your very imagination; for by omitting the quotes around the word "verbosity" and by omitting the context from what I originally wrote, you have entirely distorted the original meaning of what I wrote, to wit, that to someone who argues they should leave out essential functionality out of their code because that essential functionality would make their code too verbose, "verbose" (that is, the argument of verbosity) is but a front to mask their lack of professionalism, and not what verbosity is actually about. You'd have to read that to which I was responding, viz. Arved's posting, to understand why I was making that distinction. -- DF.
[toc] | [prev] | [next] | [standalone]
| From | lipska the kat <"nospam at neversurrender dot co dot uk"> |
|---|---|
| Date | 2013-06-24 18:14 +0100 |
| Message-ID | <ycKdnQ0xhogN41XMnZ2dnUVZ8uOdnZ2d@bt.com> |
| In reply to | #24522 |
On 24/06/13 17:57, Daniele Futtorovic wrote: > On 23/06/2013 10:21, lipska the kat allegedly wrote: >> On 23/06/13 02:53, Daniele Futtorovic wrote: >>> On 22/06/2013 20:41, lipska the kat allegedly wrote: >>>> On 22/06/13 18:25, Daniele Futtorovic wrote: >>>>> The aforementioned is mitigated in code that is internal to a >>>>> component (in the spirit of encapsulation, code ought to be divided >>>>> into components such that the density of interrelation of code >>>>> within a component is always strictly greater than that of >>>>> interrelation of code in different components). >>>> >>>> You mean it should be cohesive (the code in a component), still, why >>>> use one word when fifty will do. >>>> >>>> as you say. >>>> >>>> "verbosity is but a pathetic front to mask either their lack of >>>> professionalism" [sic] >>> >>> No, I did not simply say it should be cohesive. If you want to >>> substitute "cohesiveness" for "density of interrelation" (which is fair >>> enough), I said it should be more cohesive within the component than >>> between components, and that this is what characterises something as >>> being a component. Not the same thing. >> >>> But still, assuming it were the same thing for a moment (which, again, >>> it is not by a wide stretch), do you really think that completely >>> twisting my words, under the guise of quoting me, to proceed to >>> advocate, for a natural and hence inexact language, a practice which you >>> rebuke me for advocating for a computer and hence exact language is >>> going to induce me to take you seriously? >> >> What is this obsession that people on this group seem to have with being >> taken seriously? I couldn't care less if you 'take me seriously' I have >> nothing to prove to you or anyone else so please don't waste any more >> time on 'taking me seriously'. When you come out with complete bollocks >> like ... >> >> "verbosity is but a pathetic front to mask either their lack of >> professionalism" [sic] >> >> Then expect me to react. It's nothing personal fercrissakes. > > To conclude this discussion (as I am not inclined to debate with someone > I can't take seriously), let me point out once more that that quote is > the product of your very imagination; for by omitting the quotes around > the word "verbosity" and by omitting the context from what I originally > wrote, you have entirely distorted the original meaning of what I wrote, > to wit, that to someone who argues they should leave out essential > functionality out of their code because that essential functionality > would make their code too verbose, "verbose" (that is, the argument of > verbosity) is but a front to mask their lack of professionalism, and not > what verbosity is actually about. You'd have to read that to which I was > responding, viz. Arved's posting, to understand why I was making that > distinction. I see, well thank you for clearing that up ... I'm also delighted to hear that you don't take me seriously. It means we concur in our opinion of each other. lipska -- Lipska the Kat©: Troll hunter, sandbox destroyer and farscape dreamer of Aeryn Sun
[toc] | [prev] | [next] | [standalone]
| From | lipska the kat <"nospam at neversurrender dot co dot uk"> |
|---|---|
| Date | 2013-06-22 09:03 +0100 |
| Message-ID | <Uv6dnWRtNKrTx1jMnZ2dnUVZ7qSdnZ2d@bt.com> |
| In reply to | #24498 |
On 21/06/13 15:24, Daniele Futtorovic wrote: > On 21/06/2013 04:33, Arved Sandstrom allegedly wrote: >> On 06/19/2013 11:42 AM, Daniele Futtorovic wrote: >>> I'm all for defensive programming, but I think that there's a limit >>> where it can be on the verge of silliness, and that that limit has been >>> grazed here. >>> >>> Less-than-bright programmers IMO cannot be a justification for crossing >>> that line; less-than-bright programmers have more ways to mess things up >>> than you could possibly ever guard against. "Do not underestimate the >>> ingenuity of complete fools", as the saying goes. >>> >>> And for me, there is an additional aspect: if a piece of code does >>> something simple, something basic, then I will want it to be short, and >>> vice-versa. Verbosity of code, to me, should hold a first-glance >>> indication of the complexity of the algorithm. In other words: be terse >>> IFF it's basic, be verbose IFF it's not. >>> >>> Perhaps your mileage does vary. No beef with that. Just throwing in my >>> two cents. >>> >> It's a good discussion. I'm not personally convinced that verbosity adds >> complexity, as a rule. There's really two types of complexity here: >> maintainability complexity - as in, can Joe Blow 12 months later >> understand the code best if it's compact versus unrolled, and formal >> complexity, cyclomatic and otherwise. >> >> I'll admit that verbosity does usually add maintainability complexity, >> if not the other kind. But not always. I've seen plenty of code that is >> conceptually quite complex but very terse. > > Sorry to nitpick, but I don't think you understood me right. I'm not > saying that verbosity adds complexity; I'm saying: if the piece of code > does something tricky, something complicated, tend to make it verbose, > otherwise, tend to make it terse. Thus, seeing a big blob of (e.g. > unrolled, step-by-step) code holds the message "here be dragons". (And > if it cannot be made verbose, then it means it absolutely requires an > in-line comment). > > At least the way I perceived it, this discussion was about making stuff > verbose indiscriminately, viz. basic code as well. I disagree with that > in the above sense. ... and who makes these seemingly arbitrary decisions about what is and what isn't 'complex'. This idea that some bits of code can be written differently (more/less verbosely) depending on someones definition of 'complex' is exactly the sort of thing that makes code less readable. Let's be quite clear about this, the *most important* thing is readability. Anyone who has experienced 'flow' when writing code will know that what was blindingly obvious yesterday can be arcane and obtuse today. You need to pick a style and stick with it, not chop and change between arbitrary styles on some whim. I'm tempted to say that this behavior typifies the too clever by half attitude that makes our job so frustrating sometimes but that might be construed as confrontational so I won't ... :-) lipska -- Lipska the Kat©: Troll hunter, sandbox destroyer and farscape dreamer of Aeryn Sun
[toc] | [prev] | [next] | [standalone]
| From | Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> |
|---|---|
| Date | 2013-06-22 19:26 +0200 |
| Message-ID | <kq4mee$fbm$2@dont-email.me> |
| In reply to | #24509 |
On 22/06/2013 10:03, lipska the kat allegedly wrote: > On 21/06/13 15:24, Daniele Futtorovic wrote: >> On 21/06/2013 04:33, Arved Sandstrom allegedly wrote: >>> On 06/19/2013 11:42 AM, Daniele Futtorovic wrote: >>>> I'm all for defensive programming, but I think that there's a limit >>>> where it can be on the verge of silliness, and that that limit has been >>>> grazed here. >>>> >>>> Less-than-bright programmers IMO cannot be a justification for crossing >>>> that line; less-than-bright programmers have more ways to mess >>>> things up >>>> than you could possibly ever guard against. "Do not underestimate the >>>> ingenuity of complete fools", as the saying goes. >>>> >>>> And for me, there is an additional aspect: if a piece of code does >>>> something simple, something basic, then I will want it to be short, and >>>> vice-versa. Verbosity of code, to me, should hold a first-glance >>>> indication of the complexity of the algorithm. In other words: be terse >>>> IFF it's basic, be verbose IFF it's not. >>>> >>>> Perhaps your mileage does vary. No beef with that. Just throwing in my >>>> two cents. >>>> >>> It's a good discussion. I'm not personally convinced that verbosity adds >>> complexity, as a rule. There's really two types of complexity here: >>> maintainability complexity - as in, can Joe Blow 12 months later >>> understand the code best if it's compact versus unrolled, and formal >>> complexity, cyclomatic and otherwise. >>> >>> I'll admit that verbosity does usually add maintainability complexity, >>> if not the other kind. But not always. I've seen plenty of code that is >>> conceptually quite complex but very terse. >> >> Sorry to nitpick, but I don't think you understood me right. I'm not >> saying that verbosity adds complexity; I'm saying: if the piece of code >> does something tricky, something complicated, tend to make it verbose, >> otherwise, tend to make it terse. Thus, seeing a big blob of (e.g. >> unrolled, step-by-step) code holds the message "here be dragons". (And >> if it cannot be made verbose, then it means it absolutely requires an >> in-line comment). >> >> At least the way I perceived it, this discussion was about making stuff >> verbose indiscriminately, viz. basic code as well. I disagree with that >> in the above sense. > > .... and who makes these seemingly arbitrary decisions about what is and > what isn't 'complex'. This idea that some bits of code can be written > differently (more/less verbosely) depending on someones definition of > 'complex' is exactly the sort of thing that makes code less readable. > Let's be quite clear about this, the *most important* thing > is readability. Complexity is an objective measure, relative to the environment constituted by the software as a whole, of how sensitive the process in question is. > Anyone who has experienced 'flow' when writing code will > know that what was blindingly obvious yesterday can be arcane and obtuse > today. You need to pick a style and stick with it, not chop and change > between arbitrary styles on some whim. > > I'm tempted to say that this behavior typifies the too clever by half > attitude that makes our job so frustrating sometimes but that might be > construed as confrontational so I won't ... :-) And who makes this arbitrary decision about what is and isn't "too clever by half"? Cleverness is not a sin. As it were, I strive for it. Cleverness is the path to betterment, individual as well as human as a whole. If you aren't clever or don't want to be, that's not my problem, but get out of my way. -- DF.
[toc] | [prev] | [next] | [standalone]
| From | lipska the kat <"nospam at neversurrender dot co dot uk"> |
|---|---|
| Date | 2013-06-22 18:51 +0100 |
| Message-ID | <d9Sdna3iJ_eEeVjMnZ2dnUVZ8s-dnZ2d@bt.com> |
| In reply to | #24512 |
On 22/06/13 18:26, Daniele Futtorovic wrote: > On 22/06/2013 10:03, lipska the kat allegedly wrote: >> On 21/06/13 15:24, Daniele Futtorovic wrote: >>> On 21/06/2013 04:33, Arved Sandstrom allegedly wrote: >>>> On 06/19/2013 11:42 AM, Daniele Futtorovic wrote: >>>>> I'm all for defensive programming, but I think that there's a limit >>>>> where it can be on the verge of silliness, and that that limit has been >>>>> grazed here. >>>>> >>>>> Less-than-bright programmers IMO cannot be a justification for crossing >>>>> that line; less-than-bright programmers have more ways to mess >>>>> things up >>>>> than you could possibly ever guard against. "Do not underestimate the >>>>> ingenuity of complete fools", as the saying goes. >>>>> >>>>> And for me, there is an additional aspect: if a piece of code does >>>>> something simple, something basic, then I will want it to be short, and >>>>> vice-versa. Verbosity of code, to me, should hold a first-glance >>>>> indication of the complexity of the algorithm. In other words: be terse >>>>> IFF it's basic, be verbose IFF it's not. >>>>> >>>>> Perhaps your mileage does vary. No beef with that. Just throwing in my >>>>> two cents. >>>>> >>>> It's a good discussion. I'm not personally convinced that verbosity adds >>>> complexity, as a rule. There's really two types of complexity here: >>>> maintainability complexity - as in, can Joe Blow 12 months later >>>> understand the code best if it's compact versus unrolled, and formal >>>> complexity, cyclomatic and otherwise. >>>> >>>> I'll admit that verbosity does usually add maintainability complexity, >>>> if not the other kind. But not always. I've seen plenty of code that is >>>> conceptually quite complex but very terse. >>> >>> Sorry to nitpick, but I don't think you understood me right. I'm not >>> saying that verbosity adds complexity; I'm saying: if the piece of code >>> does something tricky, something complicated, tend to make it verbose, >>> otherwise, tend to make it terse. Thus, seeing a big blob of (e.g. >>> unrolled, step-by-step) code holds the message "here be dragons". (And >>> if it cannot be made verbose, then it means it absolutely requires an >>> in-line comment). >>> >>> At least the way I perceived it, this discussion was about making stuff >>> verbose indiscriminately, viz. basic code as well. I disagree with that >>> in the above sense. >> >> .... and who makes these seemingly arbitrary decisions about what is and >> what isn't 'complex'. This idea that some bits of code can be written >> differently (more/less verbosely) depending on someones definition of >> 'complex' is exactly the sort of thing that makes code less readable. >> Let's be quite clear about this, the *most important* thing >> is readability. > > Complexity is an objective measure, relative to the environment > constituted by the software as a whole, of how sensitive the process in > question is. > >> Anyone who has experienced 'flow' when writing code will >> know that what was blindingly obvious yesterday can be arcane and obtuse >> today. You need to pick a style and stick with it, not chop and change >> between arbitrary styles on some whim. >> >> I'm tempted to say that this behavior typifies the too clever by half >> attitude that makes our job so frustrating sometimes but that might be >> construed as confrontational so I won't ... :-) > > And who makes this arbitrary decision about what is and isn't "too > clever by half"? Cleverness is not a sin. As it were, I strive for it. > Cleverness is the path to betterment, individual as well as human as a > whole. If you aren't clever or don't want to be, that's not my problem, > but get out of my way. Too clever by half ... it's an idiom, look it up. lipska -- Lipska the Kat©: Troll hunter, sandbox destroyer and farscape dreamer of Aeryn Sun
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2013-07-04 22:58 -0400 |
| Message-ID | <51d63640$0$299$14726298@news.sunsite.dk> |
| In reply to | #24454 |
On 6/18/2013 4:50 PM, Arved Sandstrom wrote:
> On 06/17/2013 07:13 PM, Daniele Futtorovic wrote:
>> On 17/06/2013 20:49, Eric Sosman allegedly wrote:
>>> On 6/17/2013 2:32 PM, Joerg Meier wrote:
>>>> [...]
>>>> Personally, I found your example considerably harder to read than
>>>> the one
>>>> liner, as well as harder to read than what would have been my solution:
>>>>
>>>> private boolean askYesNoquestion (String str){
>>>> if(str.equals("yes"))
>>>> return true;
>>>>
>>>> return false;
>>>> }
>>>
>>> Or, for even greater clarity:
>>>
>>> private boolean askYesNoquestion(String str) {
>>> boolean yes;
>>> boolean no;
>>> if (str != null && str.equals("yes")) {
>>> yes = true;
>>> no = false;
>>> } else if (str != null && str.equals("no")) {
>>> no = true;
>>> yes = false;
>>> } else {
>>> yes = no = false;
>>> }
>>> return (no != true && yes != false) == true;
>>> }
>>
>> Call me sceptical, but I'm sceptical: I find that one-line return
>> statement kinda confusing. For more clarity, it should be encapsulated:
>>
>> public static boolean isTrue( boolean b ){
>> boolean ret;
>> if( b == true ){
>> ret = true;
>> }
>> else {
>> ret = false;
>> }
>>
>> return ret;
>> }
>>
>> private boolean askYesNoquestion(String str){
>> ...
>> return isTrue( ! isTrue(no) && isTrue(yes) );
>> }
>>
>> Better, dontcha think?
>>
>> ;)
>>
> See my answer to Eric, all this is just ridiculing reasonable
> programming practices.
>
> Even given Robert's example where the NPE-safe equals() is wrapped in a
> method that constrains the type of object being compared to, it may not
> be expected or acceptable that the String is null. So perhaps you do
> want to check for that, maybe with Apache StringUtils.isBlank().
>
> Sure, the contrived absurd examples are retarded; so is the mockery of
> defensive programming. Oh well, there's a reason why most software
> projects still fail or go vastly over budget.
I don't think anyone is arguing against defensive programming - I
think some people are arguing against not necessary variables
and if statements.
Arne
[toc] | [prev] | [next] | [standalone]
Page 3 of 6 — ← Prev page 1 2 [3] 4 5 6 Next page →
Back to top | Article view | comp.lang.java.programmer
csiph-web