Re: Smart programming languages

From: Randy Howard (randyhoward_at_FOOverizonBAR.net)
Date: 02/04/05 

Date: Fri, 04 Feb 2005 22:41:06 GMT

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.

> 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.

     'See how easy this is, says Bill G., anybody can do it!'

VB is the perfect example of such a language. Of course the cost
of this is the language makes a lot of assumptions,

> 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. Meaning that commonly used
data structures, software designs, etc. are being turned into widgets
that you can just grab and use. The days of every programmer (being
force into) rolling their own sort function seem long gone, and
the same thing is happening for a lot of other common tasks.

The language details themselves, loops and such that you are asking
about don't bother me that much as is. If you really want to
look at something radically different, look at functional languages
like Haskell. Better yet, spend a while with Lisp. In a lot of ways
Lisp is very old, but it's still very leading edge, it's just
not widely known and understood.

> > 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
>
> > A language that didn't try to use volatile as a band-aid to cover
> > up (but not successfully) holes in its threading capabilities.
>
> My understanding of 'volatile' is that it informs the compiler that a
> value may be modified elsewhere and should thus not be cached, say by
> being placed into a register. Could you expand on the threading
> capability holes, which if fixed would eliminate the need for
> 'volatile'? (Ofcourse I may have misunderstood what you are getting at
> here, so help a brother out, LOL).

Well, there have been endless very long threads on the topic, almost
all of which have the word "volatile" in them in comp.programming.threads
over the last year or so. Again I'll cheat and say read through them
(google groups archive) for all the gory details.

> > 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. I suspect that the reason most languages
> don't come with such support is the sheer complexity of it all (a lot
> of semantics must be rethought when placed in a parallel execution
> context).

Very true. I don't expect this requirement to be anything like "Easy"
to implement or even design properly.

And primitives in the language for things like atomic operations,
that must be there if the underlying hardware supports them. Again
c.p.t has a lot on this, lock-free solutions, etc.

One thing that would be nice, but perhaps approaching impossible to
implement generically would be a special variable type for global
shared data values for counters, state, etc. that you want to
ALWAYS be locked via mutex or something similar for threaded code.

Imagine a compiler smart enough to do:

/* global thread-safe variables */
   (thread_magic) unsigned long perf_counter;
   (thread_magic) size_t largest_value_seen;
   (thread_magic) bool some_tunable_parameter;

then, within each thread function you could take the value of them,
add/sub/mul/div, whatever and they would automatically have synchronization
around them (a really fancy macro expansion if you will) so that you
don't have to do something like declare mutexes for everything you want
to protect, and do:

    LOCK(some_mutex);
       perf_counter++;
    UNLOCK(some_mutex);

Where LOCK and UNLOCK are macros that call something like pthread_mutex_lock
and pthread_mutex_unlock() plus all of the error handling to go with them
and scatter that all over the place.

Instead, it would be guaranteed safe to just type:

      perf_counter++;

in any thread function without worrying about synch. 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.
 
> ... 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. :-)

> 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. The hypertransport memory system makes
the Intel approach and FSB speeds a joke. It is true Opteron systems
with Htransport support have memory performance with 1 CPU = that of
the best Xeon right now. With 2 CPUS it is 2X Xeon. With 4 CPUs, it
is 4X Xeon SMP performance. It scales beautifully, and it rubs Intel's
nose in the dirt *badly* on server class hardware right now. The
good news is that it will show up on gamer boy motherboards soon when
dual core AMD64 starts to show up and Intel will have to do something
dramatic to respond or be left with their pants down.

> I suspect AMD will get
> quite a following when 64-bit computing becomes common place.

They already have, in fact I have a very nice 64-bit AMD notebook right
now and it works very nicely. 64-bit Linux distros are readily
available, and XP64 RC1 is out for public eval right now. 

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

Relevant Pages

  • Re: VMS
    ... because it was tailored to the platform rather than the language. ... > best machine architecture (PDP-11, VAX, Alpha) and the best software. ... the hardware really didn't matter. ... applications and in the IT world bus speed is more important than ALU ...
    (comp.object)
  • Re: Cells compared to Flow-Based Programming
    ... Given that it's not even possible to proof hardware, ... a language with imperative features is inherently ... of the acquired company that they don't like. ...
    (comp.lang.lisp)
  • Re: a dozen cpus on a chip
    ... No nontrivial language can ever be proven to be imposible to crash. ... compilers still available which implement ISO M2. ... It is a common misconception that Lisp is always interpretted. ... various X86 machines the hardware does exist that could allow the OS ...
    (sci.electronics.design)
  • Re: How much intelligence?
    ... Curt believes in things that have hardware that enables them to talk. ... have the same language skills we have. ... These representations of reality are represented in long-term memory, ...
    (comp.ai.philosophy)
  • Re: Another transputer-inspired language?
    ... describe permanent ASIC/VLSI hardware devices. ... only support Verilog & VHDL. ... shrinking but the no of FPGA starts is exploding due to lowish NRE ... When I suggest the V++ language be modeled after ...
    (comp.sys.transputer)