Re: Future of programming

From: KiLVaiDeN (KiLVaiDeN_at_CaRaMaiL.CoM)
Date: 10/07/04 

Date: Thu, 7 Oct 2004 23:24:06 +0200

"C" <cc-news@hermes.mirlex.com> wrote in message
news:Mdh9d.211$8w1.136@newsfe1-win.ntli.net...
> 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.

hehe yeah I know my post sounds like a troll, but it isn't one, and I'm
thankfull you guys take your time to answer and give really clever and great
comments to messages, it's really motivating to keep on working on this
domain ;)

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

Yes but the logic behind those hardware are binary

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

Your points are interesting, as I posted on my answer to Randall Hyde, I
think that the use of ASM to optimize code is nowadays a need to make faster
programs in a world where users tend to have more and more programs and
games on their computers which push the hardware to its limits, but when
those optimizations will involve few ms or ns of time response I don't think
it'll be needed anymore. Of course, maybe "ethically" if I could say, having
programs badly written "low-level-wise" could be a problem in the mind of
some people, who would like to see that the fastest and best code written,
but again, let's not forget in my opinion the main purpose of programming,
which is "automating tasks" and when this job is complete, then there is no
need to go into further complications, unless you really like it.
Which analogy could I find, let's imagine a worker, who builds houses, and
who likes to have every wall absolutely perfect and straight, well ok if he
takes the time to make those walls perfectly straight he'll have a really
nice result, but was that time really needed, compared to the original need
of the wall ? I'm not sure..

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

AI is a domain which is in great evolution, and which will get into levels
we probably have no idea yet ( well we can imagine them though )
I am totally agree with you about the fact that to have efficient
code-generators, or even efficient compilers, which is not the case
nowadays, we will need to include something more that simple compiling
"mechanic" or code generating "mechanic" into them. Just think about what
makes you able to optimize code much better than compiler, what do you have,
that a compiler doesn't ? An experience ? It looks like having a chess
calculator, knowing all the possible combinations of chess, and being able
to compute the best possible solutions. How about projecting that into
code-generation, or compilation ? A machine could know all the possible
optimizations to apply to a code, and then apply them accordingly, don't you
think ?

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

C does all that already, doesn't it ? It can be used for all the machines
which have a C compiler, and it's portable and very usefull for application
coding. OK it's not the ideal programming language cause of some weaknesses,
but, why invent something more specific, when you could imagine something
more general, which would cover and solve more problematics ?

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

When we "think" about a program, we as programmers have an idea in mind on
how the program should work, simply knowing that fact, a code-generator
should get that kind of "intuition" into its circuits, to be able to produce
what a programmer could, probably faster even.. But I'm maybe going too much
to SCI-FI movies lately, but still, the future looks like that for me, and I
will be there I hope to see how it'll all evolve in the next decades.

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

You are totally right about that point, but it's at least a "try of
evolution", instead of staying in old positions.
All tries of evolution aren't successfull, but some were, and it's cause of
them that we live in such an advanced world, right ?

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

The cpu architectures are getting more and more complex, and maybe one day
we'll be able to produce cpus, that would be directly execute C code, who
knows ? All is possible...

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

That point is totally correct, and I myself involve time into learning ASM
or C everyday a bit more, to "stay in shape", every programmer does the same
I think

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

My point is that the logic of assembly, not being the same as procedural
languages or OO languages, leads to the fact that to achieve an indentic
task, you will have to use different algorithms. A good asm programmer knows
how to make ASM algorithms, even if there is macros and OO in assembly,
doesn't change the fact that the vision of the solution to a problem will be
different in procedural/OO/assembly logics.

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

You can also cook eggs with a hair dryer :) jk, I don't know about object
oriented assembly, but I'd guess it's not as easy to use as some class in
Java..

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

the next tool could be a really advanced assembler. The evolution is in
making something that beats the previous things we invented, but in all the
domains, and not only in one of them. If a really advances assembler beats
the portability / reusability / efficiency / understandability(?) of other
technologies, it'll for sure become the best way to go !

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

I think it's not all about agreeing or disagreeing, we should instead
understand each other point and learn from each other if possible ;)

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

Assembly could get all it desearves, when it'll be known as a true benefit
compared to other technologies, but let's say it's not yet the case, maybe
because of a simple reason : it's easier to obfuscate the world with HLL
which are easy to write, but hard to reverse engineer, than having a world
full of capable assembly programmers, who could become potentially dangerous
for the software development companies, or even OS companies !

Relevant Pages

  • Re: when to use proc
    ... > point out that these are not real 80x86 assembly language statements. ... >> first assembler only app after reading the documentation. ... But remember I come from windows programming for 10 years. ... transition to Spasm was easy since the API I allready know a little about. ...
    (alt.lang.asm)
  • A Friendly review of "Windows Programming in Assemble Language" chapter 3
    ... Programming in Assemble Language". ... Basically a commersial of HLA, and its ability to bridge the gap for asm ... ressurect HLA status to an assembler and positions HLA ...
    (alt.lang.asm)
  • Re: Survey
    ... >> There are a couple of things HLLs can do that an assembler cannot - ... >> programming population can read. ... No language can prevent the truly dedicated from writing unreadable ...
    (alt.lang.asm)
  • Re: Language design evolution vs. revolution
    ... Programmers prefer a language that is similar to what they ... I don't like typing lots of extra syntax that is unrelated to expressing ... I prefer structured programming. ... With NASM assembler, I don't have to understand what, why, or most ...
    (comp.lang.misc)
  • Re: Assembly Language
    ... > assembly language just for debugging. ... are sufficient for a large amount of code, but compilers cannot completely ... Web programming used to be lucrative. ...
    (comp.lang.asm.x86)
Loading