Re: Smart programming languages

From: Eric Mutta (anon21h_at_yahoo.co.uk)
Date: 02/05/05 

Date: 5 Feb 2005 08:06:28 -0800

Randy Howard wrote:
> In article <1107547194.939572.114950@o13g2000cwo.googlegroups.com>,
> anon21h@yahoo.co.uk says...
> > Randy Howard wrote:
> > > > Just out of curiosity, if you heard the term "smart language"
or
> > > > "smart compiler", what would come to mind?
> > >
> > > That YASP (yet another silly programmer) was trying to make
software
> > > development foolproof.
> >
> > LOL, I don't think I explained myself very well. When I said
"smart", I
> > was thinking along the lines of "greater abstraction". E.g assembly
> > language would be 'dumb' in the sense that you have to spell out
things
> > like a For-loop.
>
> So you are describing a VVHLL (very very high level language). As
far
> removed from assembly as possible. I am probably not your best
source for
> this then, as I am quite happy with assembler and C as is.

Oh, I am cool with assembler. In fact, my last X-mas card came printed
with the code for a boot loader. Unfortunately it experienced a slight
page fault, so it was hardly legible. Postman said it was my fault, I
tried to interrupt him before he left, but he couldn't make an
exception and preempted my comments before my time slice had
expired...*sigh*...X-Mas cake was good though.

> > Over time, languages got 'smarter' in the sense that higher level
> > abstraction facilities were added.
>
> I guess the "smarter" term is bothering me. What you are really
saying
> is people tried to come up with languages that would allow the casual
> programmer to be "dumber", yet still productive within in their
limits.

Gotta love the cynicism in this group. No, what I am really saying, is
that people tried to come up with languages that would allow the
professional programmer to focus on getting the darn thing out of the
door instead of constantly having to map their high level thought
'language' to the lower level computer language. Why does the ideal of
simplification always spark the 'dumb programmer' comments, eh? :-)

> 'See how easy this is, says Bill G., anybody can do it!'
>
> VB is the perfect example of such a language...

This was bound to mentioned at some point...

> > In asking about "what things do you do over and over...", I was
trying
> > to get an idea of what current language constructs are being
combined
> > in the same way over and over again, and therefore could benefit
from
> > greater abstraction.
>
> I think that is being handled (along a different tack obviously) by
> things like STL, design patterns, etc. [...]

That phrase 'design patterns', just irks me. Everytime I hear it I
think Java, and then I think about how they handle events in AWT and
Swing and then I'd rather stop thinking.

<snip>

> > > A macro language without side-effects.
> >
> > Could you expand on that a bit, please?
>
> Hmm, this could be several pages long. I think I'll cheat. A
trivial
> example is here:
>
http://www.cse.ohio-state.edu/cgi-bin/info/info/cpp,Duplication%20of%20Side%
> 20Effects

Cheers, I'll take a look at that when I can.

<snip comments on 'volatile' for which I'll prowl the groups to find
more info>

> > > In fact, a language that was architected from day one to run on
> > > and support SMP and NUMA hardware, [...]
> >
> > I've had some exposure to programming with threads and one very
quickly
> > learns that it can get messy. [...]
>
> Very true. I don't expect this requirement to be anything like
"Easy"
> to implement or even design properly. [...]
>
> Imagine a compiler smart enough to do:[...] It might be impossible
> to pull off, or impose so many performance problems to not be worth
it.
> It also seems likely that the compiler might provide you with some
free
> race or deadlock problems for your benefit. :-) A pipe dream maybe.

Hmmm, I think it may not be such a pipe dream at all, and its this sort
of abstraction that I was thinking of in my initial question. I think
it would be quite straight forward to implement because if it can be
done by hand (like you showed in your code snippets), then all the
compiler has to do to provide the feature natively, is to generate the
code one would write by hand. Sure there are finer details but it
shouldn't be *that* more complicated, nay?

> > ... Although now that the Wintel monopoly is in existence, I find
> > that anyone wanting to make a commercially viable language seems to
> > focus on the Intel hardware for obvious reasons.
>
> So make it run on Intel, but not "married to it". Blow off embedded,
> funky mainframe hardware and EBCDIC and be done with it. If it ever
> does really take off, some standards body will take all your work,
> balloon the heck out of it, generate 835 pages of unintelligible
> legalese and ruin your baby anyway. :-)

LOL, or you can go the other way round and get the language defined by
a non-standard standards body(!). Then whenever you make a comment on
USENET, they'll cry "proprietary" then "vendor lock-in" and suddenly
you have a baby some people don't want! :-)

Just what is the solution to this age-old dilemma, anyway?

> > Talking about Intel
> > hardware, I looked at the AMD64 architecture and it seems much
simpler
> > than the IA-64 from Intel
>
> Both simpler, and far better. [...]

Indeed. After I'd spent a few months checking out Intel's processor
manuals, I decided to see how AMD was doing stuff and much to my
surprise it was incredibly simple and just felt, 'fresh'. I think Intel
is getting carried away with how much they are putting into the
processors. I mean the predication, the branch prediction, instruction
bundling, etc is probably going to turn out much harder to get right
and exploit effectively all the time. End result is compiler writers
ignore the more advanced features and we end up stuck with an over
engineered machine. Shame.

> > I suspect AMD will get
> > quite a following when 64-bit computing becomes common place.
>
> They already have [...]

LOL, quite right. I rebooted my machine and realised it was running an
AMD processor, all along!

> --
> Randy Howard (2reply remove FOOBAR)
> "Making it hard to do stupid things often makes it hard
> to do smart ones too." -- Andrew Koenig

Cheers,
Eric Mutta :-)

Relevant Pages