flat assembler
Message board for the users of flat assembler.

Index > Heap > hll vs fasm

Goto page Previous  1, 2, 3, 4, 5, 6
Author
Thread Post new topic Reply to topic
dogman



Joined: 18 Jul 2013
Posts: 114
dogman
I responded to part of this before but I'm going backwards in the thread and reading more now.

nyrtzi wrote:
I just meant that assembly languages usually don't have a lot of features that help keeping a big codebase consistent and error free.


Not everybody even agrees what those features would be. In my experience, code quality and stability are much more dependent on the designer(s) and implementer(s) than on anything else. But I have mostly worked on systems written in assembler.

I'm not convinced strong typing has that much of an effect on correct code simply because there are almost always ways for people to subvert it. If you type a language so strongly that you can't cast anything then the language is too annoying to use outside academia. I do see the value in strong typing when applied correctly, but this reduces to the direct relationship between developer quality and code quality. The best compiler in the world will not make a bad coder one bit better, it's just that nothing he writes will ever compile.

nyrtzi wrote:
After all some languages do help maintaining big codebases more than others. How many assemblers support proper compile-time type checking with user defined types?


None that I know of, but I'm not sure if that's relevant. In an HLL data has a type because HLLs are about abstractions. In assembler data is just data, and code can be data too, and type isn't something relevant. I think you have to be careful trying to go backwards from HLL to assembler and say that assembly code needs HLL features. Abstractions are done much differently in assembler and the kinds of problems we solve using it are much different than problems HLLs are designed to solve.

nyrtzi wrote:
C has more even though I don't think C has enough of them. With Java you can't fudge up pointer arithmetic because there isn't any.


This is a perfect example of what I am saying. Things have to be understood in context. Java is not a systems programming language. The lack of pointers is about idiot-proofing Java because most coders are unqualified idiots. Nobody should ever say, "you know, I just can't figure out whether I want to write this program in assembly language or Java. What to do, what to do?" I fire that guy and everybody he knows and he never works in my town again.

Most people who are coding C aren't qualified to code in it and most code written in C shouldn't have been written in C anyway.

This whole discussion is irrelevant because nobody should be unclear about when to use this or that language. Most application code should not be written in assembly language. Just because we can doesn't mean we should. And most stuff that's written in assembly can't be written any other way. This whole discussion is like arguing what's better, a screwdriver or a hammer. A place for everything, and everying in its place. When you have a few application languages to choose among, then you can start talking about the advantages and disadvantages of each one relative to the job you want to do. Otherwise, you're making meaningless comparisons by lumping things together than should not be lumped together.

If the discussion is about hobby coding then nobody cares at all about anything you or I said. They use what they like, no matter how hard or wrong it is, just because they want to. That's a completely different subject ha ha.

nyrtzi wrote:
You can get a null pointer exception though. With C and assembly it would be just a segfault though.


Is there no error recovery in the OS you guys are coding on? There is no error condition that gets past us where I work. We have to code recovery routines to handle errors. Bad pointers come up often. You just give the caller an error and he has to decide what to do next. Just crashing is not acceptable.

nyrtzi wrote:
It is better to catch as many errors as possible during compilation and development than later on during runtime especially after the software is already in production use.


Yeah but that statement tells me somebody has no idea what he's talking about. the kinds of errors compilers can detect are not the same kinds of errors that happen in runtime. You have to cover all the bases. Trying to get the compiler to do this is a false sense of security. I'm not against tools that can help, but I would never rely on them. At the end of the day, you have to test your code upside down and inside out and know what it does instruction by instruction (or for HLL line by line). If you get lazy or think it's the compiler's job to find your mistakes you're going to burn and be burned.

nyrtzi wrote:
Haskell, ML languages and so on have a nice type system as far as catching errors early on goes (if I've understood correctly how they work).


That's all well and good but there aren't any production systems running in those languages and there won't ever be.

_________________
Sources? Ahahaha! We don't need no stinkin' sources!


Last edited by dogman on 11 Sep 2013, 06:32; edited 2 times in total
Post 11 Sep 2013, 05:47
View user's profile Send private message Reply with quote
dogman



Joined: 18 Jul 2013
Posts: 114
dogman
Too much nested quoting so I'm trimming quotes.

nyrtzi wrote:
What I meant was that for example any program that grows big enough is going to contain a lot of identifiers of different sorts.


Before we talk about that we need to observe there's a problem here, because programs should never grow significantly. If they do, it means the guy who designed it had no idea what he's doing. OK, it grew, it was badly designed, and it has a lot of identifiers. There's nothing intrinsically problematical with lots of identifiers.

nyrtzi wrote:
Therefore any language that is used to write something big will encounter the same problem and will have to decide what to do about it.


What problem are we talking about? I really can't understand what you meant.

nyrtzi wrote:
Some languages help with this issue more than others. That was my point. Assembly less. C++ more.


I will refrain from responding to this until I understand what you meant with the sentence I quoted above earlier.

nyrtzi wrote:
Where Lisp concentrates on the values and their latent typing at runtime these others try to make the programmer build the whole conceptual model of the program specifically around the type system at compile time. I don't like their syntax though.


Yeah. I tried looking at ML/OCAML and Haskell and a few other F/Ls several times and they're just too damned ugly to take seriously. I'm sorry but that's how I feel about it now get outta here! Razz

_________________
Sources? Ahahaha! We don't need no stinkin' sources!
Post 11 Sep 2013, 06:29
View user's profile Send private message Reply with quote
nyrtzi



Joined: 08 Jul 2006
Posts: 192
Location: Off the scale in the third direction
nyrtzi
To summarize dogman I pretty much agree with everything you say so I'll just bring up some observations.

People don't agree on which features would help with big codebases? Yes, but in general they all seem to be different ways of trying to achieve modularity and perhaps even trying to enforce the contracts that interfaces of different modules usually involve. So in the end we are just talking about different ways to "divide and conquer" by breaking a complex problem into smaller ones which are easier to solve independently. Many features help with that in different ways.

Strong typing can be subverted? Yes, but then again why would I want to? People who are smart in a practical way tend to either not subvert helpful language features or when they do so they do it for a good reason and in the safest way they feel comfortable with.

Not being able to cast would be annoying and impractical? If I've understood correctly with some languages you'd no need for casting. They just require a different mindset for thinking about how programs should be designed and written.

Correctly applied strong typing reduces the benefit of hiring good programmers? Well yes, but then again some people prioritize being able to maintain a codebase properly even with only second-rate programmers.

A good compiler won't make a bad programmer a better programmer? No, but it will prevent him from making some mistakes which might not be that bad a thing. Isn't that a big reason for why they made Java?

Casting too can be used in good and bad ways. A good compiler should support the programmer in writing error free code. An even better compiler would allow the programmer to teach it new idioms and approaches which it could then check for the programmer so that he could automate more of the error checking work he'd otherwise have to do manually.

Assembly needs HLL features? The right tool for the job, right? If the job gets done better with some feature then I'd say I'm in favor of it. Then again if an assembly programmer doesn't need some feature then the feature would just be excess baggage slowing him down.

dogman wrote:
The lack of pointers is about idiot-proofing Java because most coders are unqualified idiots.


Laughing That is rather harsh. Laughing

dogman wrote:

Nobody should ever say, "you know, I just can't figure out whether I want to write this program in assembly language or Java. What to do, what to do?" I fire that guy and everybody he knows and he never works in my town again.


Oh well. There isn't always an obvious best choice but then again it should be rather obvious which language is suitable for what. Like you said.

dogman wrote:

If the discussion is about hobby coding then nobody cares at all about anything you or I said. They use what they like, no matter how hard or wrong it is, just because they want to. That's a completely different subject ha ha.


I think we've been covering both hobby and work here. Smile

Just crashing is not acceptable? I don't think it's acceptable either. Which is why I actually check for nulls in my code. I've seen a lot of code which doesn't. It ticks me off in a bad way.

dogman wrote:

Yeah but that statement tells me somebody has no idea what he's talking about. the kinds of errors compilers can detect are not the same kinds of errors that happen in runtime.


Obviously not. Isn't that much obvious?

dogman wrote:

Trying to get the compiler to do this is a false sense of security. I'm not against tools that can help, but I would never rely on them. At the end of the day, you have to test your code upside down and inside out and know what it does instruction by instruction (or for HLL line by line). If you get lazy or think it's the compiler's job to find your mistakes you're going to burn and be burned.


Yes, relying blindly on anything is a bad idea. Compilers and libraries can have bugs too. Even hardware can have bugs. And like you said they won't catch everything. Syntactic and type errors perhaps but logical errors like calling two functions with side-effects in the wrong order are things one needs to iron out without much help from the tools. Then again good tools should let you program themselves to do some of that.

dogman wrote:

That's all well and good but there aren't any production systems running in those languages and there won't ever be.


Their websites seem to list a few.
Post 11 Sep 2013, 17:37
View user's profile Send private message Reply with quote
nyrtzi



Joined: 08 Jul 2006
Posts: 192
Location: Off the scale in the third direction
nyrtzi
dogman wrote:

nyrtzi wrote:
What I meant was that for example any program that grows big enough is going to contain a lot of identifiers of different sorts.

Before we talk about that we need to observe there's a problem here, because programs should never grow significantly. If they do, it means the guy who designed it had no idea what he's doing. OK, it grew, it was badly designed, and it has a lot of identifiers. There's nothing intrinsically problematical with lots of identifiers.


The identifiers were just an example. Not a very good one perhaps. The main point was complexity. For some reason I imagine that a big program is more complex than a small program if all other aspects of the equation are equal (same language, code is similar, etc). Especially if a codebase just grows.

You seem to be programming in a completely different world than I am. In my world programs just grow all the time without end and a good and complete spec or design is something that only exists fairytales. Either the market changes or something else happens. This is the reason I'm looking for tools to help me keep the complexity locked up and in heavy chains (I'm on a fool's errand?).

dogman wrote:

Yeah. I tried looking at ML/OCAML and Haskell and a few other F/Ls several times and they're just too damned ugly to take seriously. I'm sorry but that's how I feel about it now get outta here! Razz


No need to feel sorry about that. Smile I don't exactly love them either. Shocked No, I'm actually being serious. The syntax is usually the biggest turn-off.
Post 11 Sep 2013, 18:21
View user's profile Send private message Reply with quote
TmX



Joined: 02 Mar 2006
Posts: 821
Location: Jakarta, Indonesia
TmX
nyrtzi wrote:
The syntax is usually the biggest turn-off.


I think I quite enjoy reading Haskell code, which is like reading math expressions. Python, which is my another favorite language, also exhibits some Haskell influence. Smile

Sometimes I still could not get "the pure functional mindset" though, probably because of too much procedural coding in C Embarassed
Post 12 Sep 2013, 02:33
View user's profile Send private message Reply with quote
dogman



Joined: 18 Jul 2013
Posts: 114
dogman
nyrtzi wrote:
People don't agree on which features would help with big codebases? Yes, but in general they all seem to be different ways of trying to achieve modularity and perhaps even trying to enforce the contracts that interfaces of different modules usually involve. So in the end we are just talking about different ways to "divide and conquer" by breaking a complex problem into smaller ones which are easier to solve independently. Many features help with that in different ways.


First you seem to have been talking about "keeping big codebases error free" which is related to but not identical to "help with big codebases". It's important to do both obviously but the things that help keep big codebases error free (as possible) aren't the same things that help you manage development of big codebases. Again, they do need to be combined in any good solution but they consist of different things.

For instance, modularity and contracts help build code. They don't necessarily keep it free of runtime bugs. Good recovery has to be part of the design. It usually can't be added later and if it is it is not usually nearly as effective if it would have been designed in from the beginning.

nyrtzi wrote:
Strong typing can be subverted? Yes, but then again why would I want to? People who are smart in a practical way tend to either not subvert helpful language features or when they do so they do it for a good reason and in the safest way they feel comfortable with.


But that's exactly the point. On big projects there are often many unqualified minions working on the code. Protective languages enforce things so poor programmers have a hard time subverting them. The problem is not the motivated, quality-oriented developer. The problem is more often how to protect the codebase while maintaining it with the cheapest commodity labor possible.

nyrtzi wrote:
Not being able to cast would be annoying and impractical? If I've understood correctly with some languages you'd no need for casting. They just require a different mindset for thinking about how programs should be designed and written.


No, languages that do implicit conversions are not safe. If the goal is correct code that works as intended, then strong typing is often a big help, if that typing is hard to subvert. Big difference between good and bad programmers, as always.

nyrtzi wrote:
Correctly applied strong typing reduces the benefit of hiring good programmers? Well yes, but then again some people prioritize being able to maintain a codebase properly even with only second-rate programmers.


That's what I said, if you want to "save money" and hire cheap labor then you have to use more protective tools. Actually, that will never work, at least in my experience I have never seen it work. Hiring the best possible people is always the fastest, cheapest, best way to work. But the time for that is past.

nyrtzi wrote:
Assembly needs HLL features? The right tool for the job, right? If the job gets done better with some feature then I'd say I'm in favor of it. Then again if an assembly programmer doesn't need some feature then the feature would just be excess baggage slowing him down.


You appear to have misread what I wrote. I can see the English wasn't unequivocal. Sorry about that. No, I said quite the opposite: you have to be careful about saying (that is, you shouldn't say) assembly languages need HLL features. But nevertheless, language features don't slow anybody down and are not excess baggage unless they're unavoidable run-time features. In my work there is no runtime, so I don't have to deal with this. Otherwise you simply don't use features you don't like. Big languages aren't necessarily a problem. Bloated code is.

dogman wrote:

If the discussion is about hobby coding then nobody cares at all about anything you or I said. They use what they like, no matter how hard or wrong it is, just because they want to. That's a completely different subject ha ha.


nyrtzi wrote:
I think we've been covering both hobby and work here. Smile


I don't think it's possible to do that and anyone who does hasn't ever worked on serious code. Everything needs a context and there is a big difference between working on stuff that sells for a million bucks a copy where the company loses a few million dollars for every minute of downtime and stuff you might like to toy around with on your on PC.

_________________
Sources? Ahahaha! We don't need no stinkin' sources!
Post 15 Sep 2013, 18:13
View user's profile Send private message Reply with quote
dogman



Joined: 18 Jul 2013
Posts: 114
dogman
nyrtzi wrote:
The identifiers were just an example. Not a very good one perhaps. The main point was complexity. For some reason I imagine that a big program is more complex than a small program if all other aspects of the equation are equal (same language, code is similar, etc). Especially if a codebase just grows.


Complexity has to be designed out from the beginning as much as possible. Then the implementation has to be as clear as possible, without resorting to parlor tricks and cheap shortcuts. True, a system with 2 million LOC is not as complicated as a system with 10 million LOC. Modularity and sane programming help a lot. And as usual, you need good people and time on the job and pride of ownership. I haven't seen that any of this is unmanageable. Except with today's MBA "managers" and budgets. Funny, it worked fine yesterday.

nyrtzi wrote:
You seem to be programming in a completely different world than I am. In my world programs just grow all the time without end and a good and complete spec or design is something that only exists fairytales. Either the market changes or something else happens. This is the reason I'm looking for tools to help me keep the complexity locked up and in heavy chains (I'm on a fool's errand?).


My work is unlike most general programming in a lot of ways. We have a lot of history and we have guys who know how to build and work on midsize systems as I said earlier. We have low turnover, sometimes you'll find a guy who has 20 or 30 years or more on the same product. The systems have grown, but in most cases they have grown sanely and evolved and because of the history we had people around who were able to give guidance about what to do and what not to do from the product standpoint. This helps a lot. We're not very market driven and we don't face the constant turmoil the PC world has to face, that is a very different battle. We have very few tools, they're all as good as they can get, and we've learned them and the OS and products over decades.

_________________
Sources? Ahahaha! We don't need no stinkin' sources!
Post 15 Sep 2013, 18:21
View user's profile Send private message Reply with quote
nyrtzi



Joined: 08 Jul 2006
Posts: 192
Location: Off the scale in the third direction
nyrtzi
dogman wrote:

nyrtzi wrote:
Not being able to cast would be annoying and impractical? If I've understood correctly with some languages you'd no need for casting. They just require a different mindset for thinking about how programs should be designed and written.


No, languages that do implicit conversions are not safe. If the goal is correct code that works as intended, then strong typing is often a big help, if that typing is hard to subvert.


What kind of casting are we talking about here? String to integer? Duck to Object and Object to Duck? Of course languages which do things implicitly (like PHP) are not very safe. Then again with Haskell for example (assuming I've understood the Haskell folks correctly) there is no need for Duck to Object or Object to Duck and String to Int and so on are handled explicitly. Obviously String to Int and so on are useful and pretty much mandatory but casting between supertypes and subtypes is only relevant to languages which have "is-a" relationships between types.
Post 16 Sep 2013, 15:26
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page Previous  1, 2, 3, 4, 5, 6

< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You can attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar.

Powered by rwasa.