Re: Future of programming

From: C (cc-news_at_hermes.mirlex.com)
Date: 10/07/04 

Date: Thu, 07 Oct 2004 19:58:36 GMT

KiLVaiDeN wrote:
> I'd like to point some facts out there, some of you guys seem to disagree
> with,

Now where did I put my flame thrower... :-)
I am tempted to brand this as a bit of trolling, but you put your
case well and bring up some valid points, so it is worth a reply
anyway.

> and some other of you are for sure aware of :
>
> In the evolution of programming, we've gone through lot of phases, which
> were :

You forgot...
0) Inventing dedicated hardware for each task.

> 1) Writing programs in Binary.
> 2) Writing programs in ASM using an assembler to convert source into binary
> files.
> 3) Using procedural languages to compile source code into Binary files, with
> linker, won't get into details.
> 4) Using object oriented languages with compilers, or even interpreters.
>
> Do you even care about the evolution ?

The forcasts of assembly being completely neglected with the
advent of HLLs never really came to pass. (Despite efforts
from both commercial and achedemic quarters.) There is some
plain truths, one of which is that you can only programme
some things with assembler. Another being that the more you
abstract away from the machine the more cycles is needed to
solve the problem, ie. the less efficient code becomes. I
can still beat optimising C compilers by 20-30%, sometimes
more depending on the problem.

On the other hand, your 'evolutionary model' hints that
technologyin the assembly area has remained static -- this
is not the case, as assemblers have become more and more
advanced since they where originally concieved.

> The next phase is probably :
>
> 5) Generate executable good code directly from conceptual models.
> (UML being an eventual candidate )

Trouble is that you would really need some form of working AI
to translate the model into anything resembling efficient code.
As I have mentioned, the more abstract the programming language
becomes, the less efficient the resulting code and hardwarewise
we are comming to the limit of the current technology, the break
-down of 'Moore's Law'. But still be want more from our soft
-ware, still there are those who dream of applications and games
which are beyond what even the latest hardware programmed in the
most optimal fachion can possibly manage.

My guess will be the next phase being multilevel languages -- ie.
a language which you can write machine oriented, portability
oriented and application oriented code with. Essentially being
able to tailor the langauge to the task, while still being able
to reuse components. This will probably be a language based
entirely generics/templates.

> ASM, C, and in some years C++ or Java, will be less and less used,
> to the profit of code-generators.

But how would we write a "code-generator"? All VHLLs have become
_very_ task specific, how would a language be designed which is
both very easy to programme and generates solutions for a wide
range of applications. While I can envisage CASE tools which
could help current languages, I cannot see a radical new way of
programming which would produce acceptable solutions.

> Going towards the evolution is a proof of great intelligence, remember that
> when C was invented, it was in a concern of improved modularity and
> portability,

Change is not necessarily evolution. Just because something is
new does not necessarily mean it is better. (And vica-versa.)

> why stick to pure and rude ASM assemblers, when you got powerfull
> compilers ?

Because compilers, even optimising compilers, cannot keep up with
the bleeding edge of processor technology. If you truely need the
fastest solution to the problem, then assembler is still needed.
(And besides, you have to know assembler to write the compilers
themselves.)

> And when you >know< that someday, it'll all be useless?

Yes, but we have to work with what we have _now_, if we where to
constantly wait for the "next best thing", we would never get
anything done.

> I understand the power you might feel, being experts of ASM, knowing all the
> low level algorithms and being able to bring an application pretending it
> was not much work

While I admit there is more one needs to know in order to write
truely efficient assembly code, this has little to do with
algorithms. I am unsure of what point you are making with this.

> ( while we all know it involves lot of effort compared to
> object oriented languages for example )

?!? You can still do object oriented assembly. Object-oriented
programming is more a mechanism of design, rather than a exclusive
feature of HLLs.

> but instead on focusing on making
> better tools for languages that have made their time, I think it'd be
> more profitable to use that time to work for what's coming next.

But we are, we (or at least I) just have the idea that the _next_
tool is a really advanced assembler, a language which transends
both compilers and assemblers not just inherits from them. But
this view is more revolutionary than evolutionary.

Firstly however, we are working on a truely modern assembler --
but, for me at least, this is with a view to writing a far more
advanced programming tool. You have got to learn to walk before
you can run.

> Just a though, I know lot of you gonna disagree but oh well !

Oh yes, but I am also sure we will also disagree why we disagree.

> if I get
> flamed at, at least give arguments. How do you think ASM will be in the
> future an option in front of the ever growing power of high level languages
> combined with UML ?

Why not combine assembly with UML? Why not combine assembly will HLL
features? Why not give assembly the advantages most commonly present
in HLLs -- a standard library of functions? And, for you, why not
look around; for many of these things have already been done.

C
2004-10-07

PS: For the Luxasm crowd, a CASE tool for editing UML diagrams and
auto generating procedure/class/method headers would be useful, plus,
maybe, adding extensions to the directives can help with this, so
that UML diagrams could be generated from the code.

Relevant Pages

  • Re: Future of programming
    ... but again, let's not forget in my opinion the main purpose of programming, ... the more abstract the programming language ... code-generators, or even efficient compilers, which is not the case ... > fastest solution to the problem, then assembler is still needed. ...
    (alt.lang.asm)
  • Re: How to make Forth interesting?
    ... In those days, the programming choice was between one of those horrible BASIC interpreters, or straight-out assembler. ... You could achieve 4 times as much in 1/4th the time, probably using 1/4th of the CPU and memory. ... Even assemblers are available in object oriented versions, BASIC no longer has line numbers, and in these new modern languages, dynamic memory management, advanced high-level data structures and garbage collection are the norm. ...
    (comp.lang.forth)
  • Re: low sugar - spotty vision
    ... Can't remember how many computer languages I've programmed in. ... CTL Modular One assembler ... "Assemblers" are not programming languages. ... into machine code before they can be run by a computer. ...
    (alt.support.diabetes)
  • Re: "STL from the Ground Up"
    ... The purpose of higher-level approaches to programming is to make more ... giving the .NET/Java compilers every ... The proponents of those languages just don't understand ... C++ is tremendously unproductive compared to modern languages. ...
    (comp.programming)
  • New edition of my NASM-based tutorial
    ... programming in 32-bit protected mode. ... Its main audience is the C/C++ programmer who wants to learn ... The assembler used is the Netwide Assembler. ... the C files in the example files for the other compilers were ...
    (alt.lang.asm)