Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 14 Jul 2020 05:16:56 -0400
From:      Aryeh Friedman <>
To:        "Steve O'Hara-Smith" <>
Cc:        Don Wilde <>, Brandon helsley <>,  FreeBSD Mailing List <>
Subject:   Re: Petite Cloud, CBSD, Intellij
Message-ID:  <>
In-Reply-To: <>
References:  <> <> <> <> <> <> <> <>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
On Tue, Jul 14, 2020 at 2:08 AM Steve O'Hara-Smith <> wrote:

> On Mon, 13 Jul 2020 20:46:02 -0400
> Aryeh Friedman <> wrote:
> > And Java is one the most natural languages I have used
>         Yes it can be, but the pile of excremental programming philosophy
> that started with EJB, swallowed several books on design patterns (to be
> worn on the sleeve in sentence length variable names) has festered for a
> few decades since is anything but natural and pretty much requires an IDE
> to write. Strangely it is surprisingly easy to write working code in but
> remarkably hard to debug when it doesn't work for subtle reasons.

Almost anything can be misused or used in the wrong situations.  Design
patterns are in this camp, when used to solve real architectural issues
(not just slavishly applying them without solving an actual issue) they are
extremely useful if used sparingly.   For example the MySQL interfacing I
mentioned in the thread is partially solved by a strategy pattern used to
fill in the dynamic parts of SQL statements for example the values and
field names in a insert or update.  If the DB we were interfacing too was
not so badly designed (likely the most idiotic DB design I have seen *AND*
the least understood by the programmers who work with it [for example
instead of using autoincremented ID numbers the DB still uses numeric ID
numbers but computes each one by counting the number of rows in the table
and then adding 1 [yet when pressed about an obvious potential bug with
this scheme the VP of Engineering in the vendor whose DB we need to
interface said "don't go down that rabbit whole" and when we asked about
the concurrency issues it raises we got "we will not answer irrelevent
questions, nor do we support external modification of the DB, if you have
any issues with the product contact tech support <slams the phone
down>".... this after telling us there where no concurrency issues when in
fact we could clearly see from the transactions log that there had to be
some concurrency going on because their app was referencing ID's in a
select that had not been assigned/stored in the DB yet [that was the next
query?!??!]... yes the orginal vendor app was also in Java but written by
idiots that like you said likely have no idea why certain things are
recommended they just use them and do so wrongly).

Also keep in mind that Java is not the only language that has abusable
features/debug nightmares, do I need to mention pointers when they are not
being used for the one there is no other way to do it (guaranteed ability
to address a specific segment of memory by it's address and the address
being specified by the programmer.... this is almost never needed outside
of a device driver and/or memory manager)... case in point of how hard
pointer bugs can be to fine I spent 4 weeks debugging a crap load of
unrelated bugs in a application I was writing in C++ that appeared to all
be unrelated (stuff like local variables changing there values when they
where in theory not in scope because the function had already called
another function with a different stack frame) and finally tracked down to
a really stupid typo in the memory manager I had also written for the app
where I said "void *ptr=malloc(sizeof(size))" where "size" was the number
of bytes the memory manager had been asked to allocate...

Bottom line not everything is a nail so using a hammer on everything is
wrong but it is equally wrong to use a screwdriver handle as a hammer when
you find an actual real nail

Aryeh M. Friedman, Lead Developer,

Want to link to this message? Use this URL: <>