It would be a good idea to update the assembler

Get msg, Rick!

17 Apr 97 18:15 -- Rick Murray told Vyacheslav Mednonogov about it would be a good idea to update the
assembly:

VM>> Wow! It would be nice for everyone to express what was the greatest
VM>> inconvenience, and what he could suggest about this.

/ skip the memoirs of the author zart :) /

REM: By the way, I accidentally found out that my first computer, like MOA himself,
was Iskra 1256 - with a Fortran interpreter and memory 4k. I’ll also tell you in detail how to thread another time :))))

RM> although, it seems to me, I’ll understand. In my opinion, this is precisely why, because there are no
RM> big good programs. but they don’t exist because there is no good compiler
RM> from a high-level language. why he didn’t appear at the time -
RM> is also understandable.

Why doesn’t he appear now? IMHO, the reason is sad and trivial - it was once described by Dmitry Grigoriev. Despite the fact that there are
Scorpion_256 and Profi_512 - the majority have Spectrum_128 (this can be seen from
most surveys). And, whatever one may say, he has 128k. And even if the author of a large project does not need high performance, he desperately needs compact code (what, for example, HiSoft C offers - twice or three times longer + library). But
usually, it also needs speed :(

RM> thank you, can you imagine a source code onassme? what about debugging? and algorithmization? How many days will you
RM> write and debug so much stuff?

Long. I even have a ready-made example - I pre-wrote the route calculation algorithm in C (2 days), and then spent a week (!) translating it into Spec's assembler and catching glitches. I haven’t had to work much in C
(or another language) for a long time, but, IMHO, with its (their) use the coding speed grows
4-5 times. I could do it at 10-20, but sometimes you also need to think :)

Actually, that’s why the whole market is...

RM> I don’t know how good these thoughts are. in general, if we were to reinvent the
RM> bicycle, at least with a chain and a gear change. and not a children's 3
RM> wheel. as you understand, everything written is my deep opinion.

I understood this idea, and I would like to agree with it, but I can’t - see above.
I hope you understand me too. If you can't invent a bicycle with gear shifting, let it be 3 wheels - it's still faster than walking :)

With warm greetings, Slava.

Thursday April 17, 1997 18:15, Rick Murray wrote to Vyacheslav Mednonogov:

RM> I don’t really understand the meaning of this at all. parcel number van - assembler
RM> is not a programming language at all, as for some reason most people think.
RM> it is just a mnemonic representation of processor commands. parcel
RM> number tu. Assembly coding is not programming, if you call a spade a spade.

This might have been the case if assembly language editors lacked
the concept of a mark and a relative jump. Then sophisticated compilers would not be required. Assembler is a language, but of a low level, and therefore highly effective,
if you call a spade a spade ;) And coding is programming to a greater
extent than writing programs in Java ;)

[missed...]

And for the rest, I agree - the appearance on Specky of a full-fledged high
level language would significantly increase the flow of truly high-quality and
multifunctional system programs for it. But until the screw on the Spectrum becomes a common thing and until the turbo button is forever frozen in the pressed position, very, very few people will use the product obtained as a result of compiling Java... Although, who knows... But when I see in some game updating the screen using LDIR, and I know that the more optimal method is significantlywould increase playability, for some reason it’s unpleasant for me...

RM> fingerprint: Rick Murray 27 F5

Sincerely, Dmitry (OLDMAN).

17 Apr 97, Rick Murray writes to Roman Khvatov:

RK>> Significantly sized source codes are difficult to write in anything, not
RK>> only in assembler :(
RM> it is generally difficult to write :-) what is significant size for assembler? and
RM> for, for example, C++? A? uh... incomparable things.

Completely comparable. It is necessary to compare the number of lines of source text. It is obvious
that when transferring a program from assembler to C, its size will decrease (and when transferred to the other side, it will increase :)
But for any language there is a certain limit on the size of source codes, after which
you can no longer do without project management systems (this the limit is very high, IMHO it
is measured in hundreds of thousands of lines)

Modernization of the assembler will not allow qualitatively changing the size of the source code or
pushing this limit (maximum several times, but we would like by several
orders of magnitude)

Roman

Friday April 25 1997 22:26, ​​Dmitry Grigoryev ─── Rick Murray:

[....]
DG> highly effective, if you call a spade a spade ;) And coding -
DG> programming to a greater extent than writing programs in Java ;)
Twenty-five again !!!! Please explain to the people what _you_ mean by the term “programming”? And for some reason, writing an algorithm is more “programming” for you than developing a conceptual model of this algorithm.

[.....]
Good luck! Evgeny.