[Sussex] RE: The 'D' programming language

[Steve Dobson]

Geoff

On 20 February 2003 at 12:45 (while Steve was at lunch) Geoff Teale wrote:
<snipped where not needed>
> Steve wrote:
> ------------
> > Wasn't that what APL was designed to be - and who uses that now?
> > Answers on a postcard please to:
> > I don't give a damn
> > 4 feet South of Western Pier
> > Brighton
> 
> ROTFLMAO! APL... stop it, it hurts when I laugh... :)

I didn't think it was that funny.

> Sorry it's a famous quote, I forget who from (else I'd have 
> creditied it) - it was there for humour value.

So famous that I don't know it and you can't remember who said it.
This must be some new definition of "famous" to which I was previously
unaware.

  [That last line was adapted from a line in the second radio 
   series of the Hitch Hikers' Guild to the Galaxy - By D Adams]
                    
> Because most developers are not "hackers", they fear change, they would
> rather expand the language they know than experience the simple joy of
> learning a new one.  Businesses compound this problem by frowning on
people
> straying from the norm.  Many company's will not allow the developers to
use
> anything other than VB even if the job is down right impossible in that
> language - this has several roots:
> 
> 0\ [valid] businesses need to ensure that they have staff with the skills
to
> support their software, in order to achieve this they try and minimise the
> number of languages in use.
> 
> 1\ [partially valid] A lot of people are taken in by the marketing blurb
and
> believe that any program can be written in VB in a quarter of the time it
> can be written in any other language (soooo not true for non-trivial
> applications).
> 
> 2\ [completely invalid] "We can't use that, it's not standard!" - almost
> always "not standard" means it doesn't come on MSDN subscription disks.

3\ Sometimes the pressures of the project also causes the developers to
go with what they know.  When managers do this is can get in the way
of building a better system.  

> <snippage>
> > But we have a response to this: eXtream Programming.  I may not solve
the
> > underlying problem but at least is has a cool name.
> 
> That's the best justification of eXtreme Programming I have ever seen.  My
> experience is that it works very well in a OO environment with a
responsive
> client who hasn't got their head up their bottom.  Even if you can't adopt
> it there are a lot of things to be learnt from it.

I tried using some of the eXtreme approach to a project I was running in
my last company - sort, phased release cycle was at it's heart.  The 
managers said that they like that approach - and then asked for detailed
plans, time-scale and why wasn't the whole think working at the end of the
first release.  I think you've just explained to me where their heads were.

> <snippage>
> > In this thread (on language syntax for what of a better term) the 
> > Java syntax is not a revolution - it far to close to C/C++ for that.
> > By removing the clutter the syntax is just another evolution.
> > 
> > How Java was execute was the revolution.  It showed that 
> > interpretation
> > was viable - which was not the think 20 years before when everyone 
> > jumped on the compiler bandwagon.
> 
> THis is of course what I meant.  The syntax is nice, but the selling point
> of Java was cross platform, web deliverable applications.  Java was truely
> the language of the internet boom in the 1990s.. now it has matured into
> back end systems  for the network world and it's bullying it's way into
> embedded space.

I don't think Java every really delivered on the internet front when it
first came out.  The browsers were to far behind in the JVM they bundled
in.  As a result Sun had to develop the Java-Plugin which helped.  Were
Java really scored was in the speed of develop.  JavaBeans forced one
to think of re-use and generising your classes.  It more or less forced
a company to split the developers into two camps: Bean writers and 
business logic writers.  Most changes to a project are changes that have
to be made the business logic - which, with the complexities of interfacing
to the other systems buried in a JavaBean, becomes very simple and quick
to change - well most of the time.

Then J2EE came along they took all this about partioning your system even
further.

I don't think Java would have had such a good time if the speed of hardware
was there.  I've found Java is a dog if the host starts swapping, but in
the 90s memory became dirt cheap, so this problem could cheaply be over
come.  In the server market server upgrades can be much cheaper than 
development time.
 
> > You are, of course, entitled to your preferences.  Personally my views
> > are that there are very, very few places where hand code assembler is
> > better than good C code compiled by a good compiler.
> <snip>
> 
> You misread me.. I meant I would find it more entertaining (and
challenging)
> to write assmebly language display hacks all day long - but this is not
> something that has any practical value to me so exanding my C/C++
knowledge
> takes priority.

Did I misread you?  If I did I'm sorry.

But to me both your posting suggested to me that if developing code to run
on an embedded system - with no constraints (hence embedded) you would
rather
write the firmware in assembler.  I, on the other hand, would rather use
Java, C++ or C (in that order).  To me, whether at work or for fun at
home,  assembly is a dead technology.

Don't get me wrong here, I value highly the code I wrote in 6502 when I was
doing by A-levels.  It taught me a lot on how the hardware works.  Anyone
new to programming I recommend writing some assembler just to learn how
hardware works.  But having learn those lessons I've now try to apply them
to the code I write in a higher level language.

Give me the same hardware as you and I will try and get C++ or better yet
Java running on it.  If I can't I'll cross compile from C.  The fun for
me is in trying to find the "right" object model for that system and to
getting it working.  I find little joy in coding for the sake of it.

When I had to write a device driver that needed to process some data from
the hardware very quickly - rather than write it in assembler I wrote it
in C - and spent time checking that the code the compiler generated was
efficient.

If getting the thing to work is what drives you then any language you 
already know will do, even [dare I say it] VB.  There are of course other
factors that come to play; the cost of the development environment is just
one.  I look forward to writing Java for small, handheld devices, just for
fun - but they program will have to do something useful for me at least.

I'm probably still misreading you, but it gave me another change to 
what myself type; which I assume is the same as listening to myself
speak ;-)

Steve