definition of a highlevel language?

[Stef Mientki]

Avowkind wrote:
> On May 27, 6:34 am, notnorweg... at yahoo.se wrote:
>   
>> (might not be the right forum for this but...)
>>
>> what is the definition of a highlevel-language?
>>
>> well there isnt one specifically and wikipedia and the like gives just
>> a very general description obv you can say it abstracts away lowlever
>> operations.
>>
>> yes but how?
>>
>> a function like map takes a function and applies it to a list for
>> example.
>> this abstracts away a common procedure like iterate through a list and
>> for every position do a computation.
>> so it is a higherorderfunction. is this how higher-level-languages are
>> built?
>>
>> so are they fundamentally differently built or is it just a lot of
>> lowlevel operations built on top of each other?
>>
>> haskell is considered a very highlevellanguage but can you do
>> systemsprogramming with it(yes maybe it is very unpractical i dont
>> know but can you)?
>>
>> is lambda calculus a more abstract and efficient way of modeling a
>> computer? meaning you start at a higher level of abstraction and can
>> work up to even higher even faster?
>>
>> how did lispmachines work? was the basic system programmed in LISP?
>>     
>
>
> A lot of the previous comments have been about levels of abstraction
> of the programming langauge - which may be the answer you want.
> Another way of looking at it is that we want to be able to move from
> the language of the solution domain - e.g. computers, bits and bytes
> to the language of the problem domain.
>
> When we think about 'level' we don't just want to look at how basic
> statements work. we also need to think about whether the language is
> capable of simply and clearly expressing the problem.
>
> If your problem domain is mathematics then mathcad and its ilk are
> near perfect high level programming languages as the programs look
> just like the problems.
>
>   
Andrew, that's very good description, and I totally agree !
> if your problem domain is controlling a water works then you may tend
> to write your problem like this:
>
> if the water level is over 10 metres then start pump
> if the water level is below 5 metres then stop pump
>   
I would go one step beyond that, and state the problem as:
"keep the reservoir full, but not too full"
> which in python might turn out to be
>
> if water_level > 10:
>     pump.start()
> if water_level < 5:
>     pump.stop()
>
> which is fairly close.
>   
And now the solution is less close ;-)
And it becomes even less close,
if we extend your solution somewhat more to a real world implementation,
something like this:

control = True
while control :
    if water_level > 10:
        pump.start()
    if water_level < 5:
        pump.stop()


And if you would propose this solution to a control system engineer,
he/she would say: "this solution works very bad" or even "this solution 
won't work"
A solution that would work, should incorporate at least a hysteresis and 
could look like this:

control = True
State   = False
while control :
  if State and ( water_level > 10 ) :
    pump.start()
    State = not ( State )
  elif not ( State )  and ( water_level < 5 ) :
    pump.stop()
    State = not ( State )

and now what's the resemblance to the orginal problem :
   "keep the reservoir full, but not too full"
;-)

So an adequate high level language,
should do exactly like a control engineer would do (btw I'm not a 
control engineer):
1- asking what do you mean by "full"
2- not asking what's the other level,
but asking what's the intended use: how often and how many water is 
added or used,
what are the costs of the pump, etc etc
after which
   the control engineer
       or
  the high level language
can calculate the optimal hysteresis.
> of course with the addition of some brackets C++ could be this clear
> too. The key though is the abstraction given by the pump class and
> implicitly by object oriented design.
>
>
> In this pattern Form designers, visual web page layout tools and their
> ilk are very high level - but only if your problem is that you need to
> design a lot of business forms or web pages.  Some problems are best
> described visually, some in text, some in mathematics.
>   
I agree that some problems are better described in one or the other form,
but it's not the major issue.
e.g. Flowcharts are a perfect high level solution for problems in many 
domains.
But flowcharts, just like computer languages, visual design languages 
and math,
are only valuable in the hands of domain experts.

What the major issue is,
    that makes a computer language or a design environment in general,
really high level,
is the availability of the domain expertise.

Therefor the only high level language I'm aware of is ...
... LabView

Labview offers a lot of domain expertise in almost any domain,
so anyone
  with just a little knowledge of the problem domain,
and
  with just a little programming experience or math knowledge,
can solve any problem in every domain with Labview.
Possibly I'm exaggerating a bit ;-)


cheers,
Stef

> Andrew.
> --
> http://mail.python.org/mailman/listinfo/python-list
>