Insights Computer Language Primer - Part 1 - Comments

Click For Summary
The discussion centers around a new article titled "Computer Language Primer - Part 1," which is praised for its informative content on programming languages and their evolution. Participants highlight the importance of referencing this article in future language discussions, noting that many misconceptions arise from a lack of understanding of programming origins. Various contributors share nostalgic experiences from early computing, including challenges faced in machine language and debugging techniques. Suggestions for future articles include covering more languages, such as LISP and Prolog, and discussing the distinction between scripting and interpreted languages. Overall, the thread emphasizes the article's value while encouraging deeper exploration of programming history and language usage.
  • #31
Yes,, don't give up. Remember the Stone Soup story. You ve got the soup in the pot and we're bringing the vegetables and meat.

You've inspired me to write an article too.

Jedi
 
  • Like
Likes phinds
Technology news on Phys.org
  • #32
jedishrfu said:
Scripting languages usually can interact with the command shell that you're running them in. They are interpreted and can evaluate expressions that are provided at runtime.
jedishrfu said:
Java is actually compiled into bytecodes that act as machine code for the JVM. This allows java to span many computing platforms in a write once run anywhere kind of way.

And of course something like Python has both these traits. But there are plenty of variations for scripting languages.

For example some scripting languages are much less handy, e.g. so far as I know, AppleScript can't interact in a command shell, which makes it harder to code in; neither did older versions of WinBatch, back when I was cobbling together Windows scripts with it around 1999-2000; looking at the product pages for WinBatch today, it still doesn't look like this limitation has been removed. Discovering Python after having learned on WinBatch for several years was like a prison break for me.

And I also like the example given above by @David Reeves of Lua, a non-interpreted, non-interactive scripting language: "Within a development team, some programmers may only need to work at the Lua script level, without ever needing to modify and recompile the core engine. For example, how a certain game character behaves might be controlled by a Lua script. This sort of scripting could also be made accessible to the end users. But Lua is not an interpreted language."
 
  • #33
vela said:
Another typo: I believe you meant "fourth generation," not "forth generation."

Also missing is the language Forth.

The forth language and dedicated stack processors are still used today for real-time motion control.
I had a problem with a semiconductor processing tool this week that still uses a Forth processor to control Y mechanical and X electrical scanning.
32392930540_5a1b396296_n_d.jpg

https://en.wikipedia.org/wiki/RTX2010
https://web.archive.org/web/20110204160744/http://forth.gsfc.nasa.gov/
 
  • #34
nsaspook said:
Also missing is the language Forth.
To repeat myself:

This was NOT intended as a thoroughly exhaustive discourse. If you look at the wikipedia list of languages you'll see that I left out more than I put in but that was deliberate.
 
  • Like
Likes nsaspook
  • #35
I should add that, regarding Lua, they say it is an interpreted language. "Although we refer to Lua as an interpreted language, Lua always precompiles source code to an intermediate form before running it. (This is not a big deal: Most interpreted languages do the same.) "

This is different from a pure interpreter, which translates the source program line by line while it is being run.

In any case you can read their explanation here.

http://www.lua.org/pil/8.html

BTW it is easy and instructive to write an interpreter for BASIC in C.
 
Last edited by a moderator:
  • #36
jim mcnamara said:
@phinds - Do you give up yet? This kind of scope problem is daunting. You take a generalized tack, people reply with additional detail. Your plight is exactly why I am loath to try an insight article. You are braver, hats off to you!
Yes, I've notice this in many comment threads on Insight articles. People feel the need to weigh in with their own expertise without much regard to whether or not what they have to add is really helpful to the original intent and length of the article supposedly being commented on.
 
  • Like
Likes Jaeusm and Mark44
  • #37
jim mcnamara said:
Your plight is exactly why I am loath to try an insight article.
No no no it's a great thing to do! Very rewarding and helpful! :)
 
  • #38
Greg Bernhardt said:
No no no it's a great thing to do! Very rewarding and helpful! :)
Yeah, that's EXACTLY what the overseers said to the slaves building the pyramids :smile:
 
  • Like
Likes Greg Bernhardt
  • #39
You kind of alluded to this point when you mentioned interpreters make debugging easier, but I think the main advantage of interpreters is in problem solving. It's not always obvious how to solve a particular problem, and interpreters allow you to easily experiment with different ideas without all the annoying overhead of implementing the same ideas in a compiled language.
 
  • #40
vela said:
You kind of alluded to this point when you mentioned interpreters make debugging easier, but I think the main advantage of interpreters is in problem solving. It's not always obvious how to solve a particular problem, and interpreters allow you to easily experiment with different ideas without all the annoying overhead of implementing the same ideas in a compiled language.
Good point.
 
  • #41
phinds said:
Yes, I've notice this in many comment threads on Insight articles. People feel the need to weigh in with their own expertise without much regard to whether or not what they have to add is really helpful to the original intent and length of the article supposedly being commented on.
The entire computer science sub-forum suffers from this.
 
  • #42
Jaeusm said:
The entire computer science sub-forum suffers from this.
Oh, it's hardly the only one.
 
  • #43
An excellent article. Thanks.

I would make one suggestion: I think of fifth generation languages as including the special-purpose languages like simulation languages (DYNAMO, SLAM, SIMSCRIPT, etc.), MATLAB, Mathcad, etc. I didn't see that mentioned anywhere and I think they are worth mentioning.
 
  • #44
I think Latex can go into one of those language categories, and if it does looks like markup language is a fitting candidate.
Anyway, great and enlightening insight.
 
  • #45
FactChecker said:
An excellent article. Thanks.

I would make one suggestion: I think of fifth generation languages as including the special-purpose languages like simulation languages (DYNAMO, SLAM, SIMSCRIPT, etc.), MATLAB, Mathcad, etc. I didn't see that mentioned anywhere and I think they are worth mentioning.
To quote myself:
One reason I don’t care for this is that you can get into pointless arguments about exactly where something belongs in this list.
and
This was NOT intended as a thoroughly exhaustive discourse. If you look at the wikipedia list of languages you'll see that I left out more than I put in but that was deliberate.
 
  • #46
phinds said:
To quote myself:

Although it's a good article, I don't get why you didn't include ____, _____, and _________. Especially _________ since it's my pet language.

By the way what does this word "overview" mean that you keep using?
 
  • Like
Likes DrClaude and phinds
  • #47
phinds said:
To quote myself:

and
Sorry. I thought that was an significant category of languages that you might want to mention and that your use of the term "fifth generation" (which refers to that category) was not what I was used to. I didn't mean to offend you.
 
  • #48
FactChecker said:
Sorry. I thought that was an significant category of languages that you might want to mention and that your use of the term "fifth generation" (which refers to that category) was not what I was used to. I didn't mean to offend you.
Oh, I wasn't offended and I"m sorry if it came across that way. My point was exactly what I said ... I deliberately left out at least as much as I put in and I had to draw the line somewhere or else put in TONS of stuff that I did not feel was relevant to the thrust of the article and thus make it so long as to be unreadable. EVERYONE is going to come up with at least one area where they are confident I did not give appropriate coverage and if I satisfy everyone, again the article becomes unreadable.
 
Last edited:
  • Like
Likes nsaspook and FactChecker
  • #49
phinds said:
FactChecker said:
Sorry. I thought that was an significant category of languages that you might want to mention and that your use of the term "fifth generation" (which refers to that category) was not what I was used to. I didn't mean to offend you.
Oh, I wasn't offended and I"m sorry if it came across that way. My point was exactly what I said ... I deliberately left out at least as much as I put in and I had to draw the line somewhere or else put in TONS of stuff that I did not feel was relevant to the thrust of the article and thus make it so long as to be unreadable. EVERYONE is going to come up with at least one area where they are confident I did not give appropriate coverage and if I satisfy everyone, again the article becomes unreadable.
In my defense, I think that the emergence of 5'th generation languages for simulation, math calculations, statistics, etc are the most significant programming trend in the last 15 years. There is even an entire physicsforum section primarily dedicated to it (Math Software and LaTeX). I don't feel that I was just quibbling about a small thing.
 
  • #50
FactChecker said:
In my defense, I think that the emergence of 5'th generation languages for simulation, math calculations, statistics, etc are the most significant programming trend in the last 15 years. There is even an entire physicsforum section primarily dedicated to it (Math Software and LaTeX). I don't feel that I was just quibbling about a small thing.
Fair enough. Perhaps that's something that I should have included, but there were a LOT of things that I thought about including. Maybe I'll add that to Part 2
 
  • Like
Likes FactChecker
  • #51
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
.Scott said:
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
phinds said:
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.
phinds said:
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.
phinds said:
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
.Scott said:
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
phinds said:
But that does NOT even remotely take advantage of things like inheritance.
Or polymorphism, another attribute of object-oriented programming.
 
  • #56
Mark44 said:
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
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
Mark44 said:
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:
 
  • #59
.Scott said:
What really defines a assembly language is that all of the resulting machine code is coded for explicitly.
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
 
  • #60
rcgldr said:
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?
 

Similar threads

  • · Replies 102 ·
4
Replies
102
Views
1K
  • · Replies 122 ·
5
Replies
122
Views
16K
  • · Replies 62 ·
3
Replies
62
Views
13K
  • · Replies 10 ·
Replies
10
Views
2K
  • · Replies 1 ·
Replies
1
Views
2K
  • · Replies 25 ·
Replies
25
Views
4K
  • · Replies 2 ·
Replies
2
Views
2K
  • · Replies 46 ·
2
Replies
46
Views
5K
  • · Replies 2 ·
Replies
2
Views
3K
  • · Replies 11 ·
Replies
11
Views
2K