Computer Language Primer - Part 1 - Comments

  • #51
.Scott
Homework Helper
2,536
914
As I read through the article, I had these notes:
1) The description of assembler having a one-to-one association with the machine code was a characteristic of the very earliest assemblers. In the mid '70's, macro-assemblers came into vogue - and the 1-to-1 association was lost. What really defines a assembly language is that all of the resulting machine code is coded for explicitly.
2) It was stated that it is more difficult to debug compiler code than machine language or assembler code. I very much understand this. But it is true under very restrictive conditions that most readers would not understand. In general, a compiler will remove a huge set of details from the programmers consideration and will thus make debugging easier - if for no other reason than there are fewer opportunities for making mistakes. Also (and I realize that this isn't the scenario considered in the article), often when assembler is used today, it is often used in situations that are difficult to debug - such as hardware interfaces.
3) Today's compilers are often quite good at generating very efficient code - often better than what a human would do when writing assembly. However, some machines have specialized optimization opportunities that cannot be handled by the compiler. The conditions that dictate the use of assembly do not always bear on the "complexity". In fact, it is often the more complex algorithms that most benefit from explicit coding.
4) I believed the article misses a big one in the list of interpretive languages: Forth (c. 1970). It breaks the mold in that, although generally slower than compilers of that time, it was far from "slower than mud". It's also worth noting that Forth and often other interpretive languages such as Basic, encode their source for run-time efficiency. So, as originally implemented, you could render your Forth or Basic as an ASCII "file" (or paper tape equivalent), but you would normally save is in a native form.
5) I think it is worth noting that Object-Oriented programming is primarily a method for organizing code. It is very possible (and unfortunately quite common) to code "object dis-oriented" even when using OO constructs. Similarly, it is very possible to keep code objected oriented when the language (such as C) does not explicitly support objects.
 
  • #52
phinds
Science Advisor
Insights Author
Gold Member
2019 Award
16,180
6,190
As I read through the article, I had these notes:
1) The description of assembler having a one-to-one association with the machine code was a characteristic of the very earliest assemblers. In the mid '70's, macro-assemblers came into vogue - and the 1-to-1 association was lost. What really defines a assembly language is that all of the resulting machine code is coded for explicitly.
I stopped doing assembly somewhere in the mid-70's but my recollection of macro assemblers is that the 1-1 correspondence was not lost. Can you expand on your point?
2) It was stated that it is more difficult to debug compiler code than machine language or assembler code. I very much understand this. But it is true under very restrictive conditions that most readers would not understand. In general, a compiler will remove a huge set of details from the programmers consideration and will thus make debugging easier - if for no other reason than there are fewer opportunities for making mistakes. Also (and I realize that this isn't the scenario considered in the article), often when assembler is used today, it is often used in situations that are difficult to debug - such as hardware interfaces.
No argument, but too much info for the article.
3) Today's compilers are often quite good at generating very efficient code - often better than what a human would do when writing assembly. However, some machines have specialized optimization opportunities that cannot be handled by the compiler. The conditions that dictate the use of assembly do not always bear on the "complexity". In fact, it is often the more complex algorithms that most benefit from explicit coding.
No argument, but too much info for the article.
4) I believed the article misses a big one in the list of interpretive languages: Forth (c. 1970). It breaks the mold in that, although generally slower than compilers of that time, it was far from "slower than mud". It's also worth noting that Forth and often other interpretive languages such as Basic, encode their source for run-time efficiency. So, as originally implemented, you could render your Forth or Basic as an ASCII "file" (or paper tape equivalent), but you would normally save is in a native form.
I never used Forth so may have shortchanged it. Intermediate code was explicitly left out of this article and will be mentioned in part 2
5) I think it is worth noting that Object-Oriented programming is primarily a method for organizing code.
I totally and completely disagree. OOP is a completely different programming paradigm.
It is very possible (and unfortunately quite common) to code "object dis-oriented" even when using OO constructs.
I completely agree but that does nothing to invalidate my previous sentence.
Similarly, it is very possible to keep code objected oriented when the language (such as C) does not explicitly support objects.
Well, sort of, but not really. You don't get a true class object in non-OOP languages, nor do you have the major attributes of OOP (inheritance, etc).
 
  • #53
.Scott
Homework Helper
2,536
914
I stopped doing assembly somewhere in the mid-70's but my recollection of macro assemblers is that the 1-1 correspondence was not lost. Can you expand on your point?
With a macro assembler, both the programmer and the computer manufacturer can define macros to be anything - calling sequences, structures, etc. Even the individual instructions were macros, so by changing the macros you could change the target machine.
I never used Forth so may have shortchanged it.
It's important because it is an interpretive language that it pretty efficient. It contradicts your "slow as mud" statement.
I totally and completely disagree. OOP is a completely different programming paradigm.
I suppose it depends on how much you include in the term object-oriented. Literally arranging you code into objects, making some "methods" public and others internal, was something I practiced before C++ or the term object-oriented were coined.
 
  • #54
phinds
Science Advisor
Insights Author
Gold Member
2019 Award
16,180
6,190
With a macro assembler, both the programmer and the computer manufacturer can define macros to be anything - calling sequences, structures, etc. Even the individual instructions were macros, so by changing the macros you could change the target machine.
DOH !!! I used to know that. Totally forgot. Thanks.
I suppose it depends on how much you include in the term object-oriented. Literally arranging you code into objects, making some "methods" public and others internal, was something I practiced before C++ or the term object-oriented were coined.
But that does NOT even remotely take advantage of things like inheritance. Yes, you can have good programming practices without OOP, but that does not change the fact that the power of OOP far exceeds non-OOP in many ways. If you have programmed seriously in OOP I don't see why you would even argue with this.
 
  • Like
Likes Jaeusm
  • #55
33,638
5,300
But that does NOT even remotely take advantage of things like inheritance.
Or polymorphism, another attribute of object-oriented programming.
 
  • #56
phinds
Science Advisor
Insights Author
Gold Member
2019 Award
16,180
6,190
Or polymorphism, another attribute of object-oriented programming.
Right. I didn't want to bother typing out encapsulation and polymorphism so I said "things like ... " meaning "there are more". Now you've made me type them out anyway. :smile:
 
  • #57
33,638
5,300
Paul, how come you didn't include LOLCODE in your summary?
Code:
HAI 1.2
CAN HAS STDIO?
VISIBLE "HAI WORLD!"
KTHXBYE
:oldbiggrin:
 
Last edited:
  • Like
Likes DrClaude
  • #58
phinds
Science Advisor
Insights Author
Gold Member
2019 Award
16,180
6,190
Paul, how come you didn't include LOLCODE in your summary?
Code:
HAI 1.2
CAN HAS STDIO?
VISIBLE "HAI WORLD!"
KTHXBYE
:oldbiggrin:
Mark, you are very weird :smile:
 
  • #61
.Scott
Homework Helper
2,536
914
But that does NOT even remotely take advantage of things like inheritance. Yes, you can have good programming practices without OOP, but that does not change the fact that the power of OOP far exceeds non-OOP in many ways. If you have programmed seriously in OOP I don't see why you would even argue with this.
I guess it's a matter of semantics. There was a time when OOP did not automatically include inheritance or polymorphism. By the way, the full OOP may "far exceed non-OOP", but there are still mission-critical and/or safety-minded industries where "virtual" is a dirty word.

Personally, I am satisfied when the objects are well-encapsulated and divided out in a sane way. Anytime I see code with someone else's "this" pointer used all over the place, I stop using the term "object-oriented".
 
  • #62
phinds
Science Advisor
Insights Author
Gold Member
2019 Award
16,180
6,190
...there are still mission-critical and/or safety-minded industries where "virtual" is a dirty word.
Yeah, I can see how that could be reasonable. OOP stuff can be nasty to debug.
 
  • #63
rcgldr
Homework Helper
8,691
522
What about the "dot" directives in MASM (ML) 6.0 and later such as .if, .else, .endif, .repeat, ... ?

https://msdn.microsoft.com/en-us/library/8t163bt0.aspx
Conditional assembly does not at all invalidate Scott's statement. I don't see how you think it does. What am I missing?
It's not conditional assembly (if else endif directives without the period prefix are conditional assembly). Some of the dot directives are like a high level language. MASM (ML) documentation refers to these a decision directives (.if .else .endif ...) and looping directives (.while .break .continue ...) . For example:

Code:
        .if     eax == 1234
        ; ... code for eax == 1234 goes here
        .else
        ; ... code for eax != 1234 goes here
        .endif
The dot directive code sequence will most likely generate the following code sequence, except that the coder didn't need to use any labels with the dot directives.
Code:
        cmp     eax,1234
        jne     short lbl0
        ; ... code for eax == 1234 goes here
        jmp     short lbl1
lbl0:
        ; ... code for eax != 1234 goes here
lbl1:
 
Last edited:
  • #64
scottdave
Science Advisor
Homework Helper
Insights Author
1,782
746
Where does something like Scratch fall in these? Just another high-level language? Interpreted, or compiled?
 
  • #67
phinds
Science Advisor
Insights Author
Gold Member
2019 Award
16,180
6,190
Where's part 2?
I've got it about 1/3rd done but it's a low priority for me at the moment
 
  • Like
Likes Greg Bernhardt and jedishrfu
  • #68
18,184
7,776
I've got it about 1/3rd done but it's a low priority for me at the moment
No no! high priority! high priority! :biggrin:
 
  • Like
Likes phinds

Related Threads on Computer Language Primer - Part 1 - Comments

  • Last Post
Replies
18
Views
8K
Replies
122
Views
8K
  • Last Post
Replies
18
Views
5K
  • Last Post
Replies
13
Views
1K
  • Last Post
Replies
5
Views
3K
Replies
1
Views
3K
Replies
14
Views
7K
  • Last Post
3
Replies
60
Views
14K
  • Last Post
Replies
4
Views
1K
  • Last Post
Replies
16
Views
816
Top