Re: Born again


KiLVaiDeN wrote:
To drive a car, you need to have your hands on the wheel, and your feet
on the pedals. HLL is like driving a car, with buttons; It feels good
and easy, but you lose control, you make heavy moves, you can't fine
tune your moves, you are what i call "bloated" with unnecessary lines of
code ( a printf in C produces on some compilers a big binary, bigger
than 20 KB = bloated code; that's the 100 000 lines i'm talking about )

Like driving a car, the race of software quality is for me how to make
good, fast, small and efficient binary code. The only way is with
assembly. HLL are good ( i'm an engineer in new technologies, so I know
what I'm talking about, and i'm not a HLL hater ) BUT i really hope that
assembly rebirth, as Betov thinks about it, is going to bring GOOD to
the programming world, because we need to get back our hands on the
wheels, in order to have flawless software.

I don't think flawless software is result of a specific language but
the programmer and his ability to design. Implementation is another
matter and language steps into the picture at that point.

A language does affect the design the same way water flows where it is
easiest.

Assembly is by definition architechture specific where as C for example
is not, this is a major motivation of staying further away from
assembly when it is not a requirement.

When we have one screen of C code and one screen of assembly code it is
more likely than not that the C code does a lot more computation than
the assembly code. It's atleast my view that the C code has more
density. The syntax also allows to see the structure of the code
easier.

The assembly syntax in it's classic purest form is a line of code per
machine instruction. In C one line consists of full expressions which
compile into multiple machine instructions and hence into multiple
lines of assembly sourcecode.

C and other HLL's overcome a lot of basic burden placed on the
programmer but this does indeed not come without a cost. The cost is
added complexity. This makes the toolchain more vulnerable to error.
This also makes the learning curve for the tools and the language much
higher.

Assembly is easy to learn but requires much more effort to write
software with. The effort goes into keeping track of labels, registers
and other things compiler handles automatically.

Example:

for ( i=0; i<10; ++i ) {
a += b; b += i;
}

Here we implement flow control without keeping track of anything but a
single symbol 'i', no label or machine specific register to manage
here. Ditto for the expressions evaluated within the control structure.

Writing code like this does not require 'active' thinking, this kind of
stuff is written in autopilot all the time. We can completely replace
the contents of the loop and not consider if the register 'r12', 'ebx'
or what not needs to be pushed and where and how and why, or optimize
this sort of things every time we change something no matter how
trivial.

I think that's not any control away from the programmer. It's not
holding-hands, bloat or other undesirable circumastance. It's a
perfectly sensible way to get the job done. There is plenty of things
to burn thinking time on, for instance it would be interesting to think
WHAT we actually do within this control structure not HOW.

The above for-loop can be completely eliminated and replaced with a
single statement when the values of i, a and b are known. THAT is
relevant where the C vs. assembly debacle is most likely not.

.