Avowkind wrote:
On May 27, 6:34 am, [EMAIL PROTECTED] 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
--
http://mail.python.org/mailman/listinfo/python-list
