Hacker News Reader

Comment by ungzd | Hacker News Reader

I don't know what are use cases for that. Nowadays, if you are coding in assembly, you are probably doing some kernel things, embedding asm in C/C++ (for SIMD or something like that and not because compilers generate bad code), embedded code for microcontrollers or retro computers (i.e. ZX Spectrum).

But Visual Studio-like IDE for making x86 application software, with GUI editor seems weird.

View on HN

I am using assembly language for all my programming tasks.

And most of they are application programming (Fresh IDE itself and many closed source projects in my work) or even web programming (https://board.asm32.info).

That is why I needed a powerful IDE, suitable for rapid programming of relatively big projects (500Kloc or higher).

This is interesting. Do you not find the dev process significantly slower than using a higher level language?

About twice slower than in HLL, with code reusing of course.

But the code is more reliable and the debugging process is much easier. After some short debugging stage, most of the projects runs for years without single bug report or other support issues.

I am not talking about the significantly higher speed, lower memory footprint and better UX (especially the response time of the UI is really much faster).

As a whole the advantages are more than disadvantages IMHO.

Interesting. Are you sure the increase in code reliability goes down to the language and not your skills? It feels quite contrary to my experience that a lower-level language would be more reliable.

Well, I am pretty average programmer. Not the worst, not the best.

The code reliability of assembly programs is better because programming algorithms in low level, the programmer controls every aspect of the execution. Notice, that excessive use of code generation macros will cancel this advantage.

Another advantage is that the bugs in assembly programs usually cause immediate crash of the program and this making the fixing easy.

Defer crashes and strange/random/undefined behavior of bugs in assembly programs is rare. IMO, this is because of reduced count of abstraction layers.

Thanks for sharing! This is really interesting, especially the part about the reduced count of abstraction layers. Do you think the abstraction layers are the problem, or the fact that the overwhelming majority of "abstractions" that materialize in modern high-level software are leaky?

Why adding abstraction layers makes programming easier?

Because allow the programmer to not think (and even know) about some things and leaving them to the layer/libraries.

But every layer adds also a level of obscurity. The interaction between multiply layers is even more undefined and random.

It is OK while everything goes as expected. But when there are problems, the obscurity can make the debugging a hell.

In addition, the behavior of the bugs hidden deep in the layers (or in the way the layers interacts in between and with the application) can be really weird.

That is why, IMHO, the programmer should keep the abstraction layers to the minimal count that allows solving programming tasks with minimal effort, counting not only the coding time, but debugging and supporting time as well.

In my practice, I decided that using FASM with Fresh IDE and set of assembly libraries gives me the needed quality of the code.

What about code maintainability and readability - I'm guessing that must be worse when compared to a HLL? Also, what made you get into writing complex programs in assembly - was it just the extra control? I've used assembly when I needed to optimise my C code, but it was a slow and difficult process! I would not really choose it for complex stuff, but I'm really interested to hear your point of view.

Code maintainability and readability depends only on the programmers knowledge of the language/framework/libraries used.

For example, I don't know Lisp, so for me it is much harder to read/maintain Lisp project than assembly language project.

This is a sad statement. Proficiency in a given language/environment dictates how long and painful a solution will be. Use cases for this are no different to any computing-related task, though I concede it isn't for everyone :-) Neither is Python, Perl, Java, JS, Node, and hey, lets throw in COBOL because you know, there was never a use case for that either. /sarcasm

Assembly IDEs are still quite common on embedded space, and TASM back in the day had a Turbo Vision based IDE on MS-DOS.

And on the Amiga we had DevPac.

Reply on news.ycombinator.com