Talk:First-generation programming language

Untitled

I don't think this is right.

A little less recently, in the early to mid 80s, code-injection was often used to overcome certain limitations of programming languages like the interpretive QBasic. This language had no means of inserting assembler code or to link to libraries made by other languages. By using the BLOAD (Binary Load) instruction, one was able to inject a certain piece of machine instructions in memory and then execute it. The opposite instruction was BSAVE, with which any part of computer memory could be retrieved. By being highly unportable, this was a very dangerous way of coding. Any typing error could result in a crash, or even worse, damage to the video controller or other equipment.

1) BLOAD and BSAVE were part of AppleBasic not QBasic 2) Typing errors happened all the time on PCs, CP/M machines... It was standard. They generally handled it well by just dropping to assembly or something 3) The video controllers weren't capable of hurting the monitors. This was problem with higher end equipment not the PCs of the day.

1) The part about BLOAD and BSAVE commands is SOMEWHAT correct. It's not the way I did it. Actually, both AppleSoft BASIC and IBM (BASICA, GWBASIC, QBASIC, QuickBASIC, PDS BASIC 7, etc.) had the BLOAD and BSAVE commands. Another thing they had in common is that they were all written by Microsoft.

The comments about low-level code being dangerous is debatable in my opinion. We had no other way of getting the job done in those days. But most meaningful code that I wrote was written in C and Assembler, which wasn't any less "dangerous".

The comments about "danger" represent just one point of view that seems to be popular with some of the newer programmers that maybe weren't even born at the time.

2) By typing errors, I assume that the author means "typing errors by programmers". I am being charitable in saying so, but any programmer who doesn't test their code before releasing it isn't a very good programmer.

--Bill Buckels 20:43, 31 May 2007 (UTC)

Programming language generations

This group of articles has problems. Please see current discussion at Talk:Second-generation programming language. Trevor Hanson 20:09, 7 October 2007 (UTC)

Reorganization

Pursuing the suggestions to reorganize this material, I have created a page called Programming language generations, using this and additional material, as explained on its discussion page. If interested, please go there and make further improvements. Thanks CSProfBill (talk) 14:31, 23 September 2009 (UTC)

machine language is a lot more difficult to learn?

Sounds rather odd to me. Assembler is not terribly difficult to learn and I don't see why machine code should be. I can see how it would be difficult to understand a machine language program, given the cryptic opcodes and lack of structure, but it shouldn't take long to learn the language. It is really the fancy concepts of high level languages that take a lot of effort to learn. —Preceding unsigned comment added by 86.139.133.189 (talk) 19:55, 28 March 2011 (UTC)

Huge Sections Removed

In this edit (see the diff here), the entire "Current uses" section was taken out by an IP user without an explanation. Does anyone know why this is? Shades97 (talk) 20:40, 19 January 2012 (UTC)

Definition/distinction?

It seems the critical question is, "What distinguishes a 1st-gen language?" ... and it seems we're not optimally answering that yet.

Here's a rewrite:....

The term "first-generation language" is retrospectively applied to direct machine languages, which are instruction sets tied to specific computer hardware designs. First-generation programming languages (1GL) were commonly used to program computers prior to the advent of tools to translate, compile or assemble first-generation languages. First-generation programming instructions were entered through front panel dials or switches. The critical distinction of first generation languages is they allow programming by setting the binary state of data to manipulate and instructions to execute directly. The only ease-of-use accommodation within the category of first-generation languages -- machine languages -- is the grouping of binary bits into higher numbers, e.g. octal, decimal, or hexadecimal.

Even when coded as higher numbers, 1GL instructions are essentially binary digits, 1s and 0s, bits. 1GL programming thus sets the computer's starting state precisely, in the computer's native binary code. But long strings of only 1s and 0s are difficult for human programmers to interpret, track, and manipulate. Higher level languages offer program reuse, hardware portability, and many accommodations to human cognition, greatly easing the human work of programming. Higher level languages so greatly ease programming that they are rarely abandoned for the direct control of first-generation languages.

Though modern tools produce machine language from higher-level languages, programmers do occasionally use machine code, e.g., when programming new hardware still in a development or testing phase.

Broadly, each hardware design for different (non-overlapping) functions has a different instruction set and requires a different machine language, However, differing hardware may execute the same functions, may use the same instruction set and may be programmed with the same machine language. The term "first-generation language" is not generally applied to complex instruction sets. Though complex instruction sets may be programmed in machine language, the hardware on such machines directly executes internal microcode which interprets the human-programmed machine language. In such a CISC, both the underlying hardware and the microcode may differ across machines executing the same instruction set, the same "second-generation machine language". The internal interpretation of a CISC takes its user-programmable machine language out of the first-generation category, making it a second-generation machine language.

Progress with higher level languages has made use of first- and second-generation machine languages rare outside of manufacturer testing.

Similarly, the interpretation of human-recognizable mnemonics shifts a language into a second-generation category. second-generation languages -- assembly languages -- commonly include mnemonics for operations, names for constant or variable data addresses, and names for instruction addresses. LoneStarNot (talk) 21:40, 26 December 2018 (UTC)

Reinstating vandalism?

This edit from an IP on 20 December 2017 appears to be definite vandalism to me. It deletes the single-sentence first paragraph of the article, where the article's subject is stated in bold and defined, complete with a citation (the only citation in the article). It also deletes the article's Ref-Improve tag -- sorely needed for an article with only one cited statement (or no citations after this vandalism). The IP provided no edit summary to explain any of this.

I only recently noticed this old vandalism, and reinstated this defining paragraph, citation, and tag, with the (admittedly terse) edit summary "Rvv" (revert vandalism).

Brian R Hunter then reverted my revert of the vandalism, again deleting the article's first paragraph, citation, and tag. The edit summary states that it's reverting my edit, but doesn't state why.

Per WP:BRD, it's better to discuss than revert a revert. So, here we are. Am I missing anything? --A D Monroe III^(talk) 21:48, 12 April 2020 (UTC)

Apologies, was too quick to undo your edit. my mistake (reverted) Brian R Hunter (talk) 17:20, 13 April 2020 (UTC)

No problem then. My edit summary was too terse; it's a bad habit I got from the early days before we had bots and rollback to handle the worst of this and we felt we had to rush to fight them all.

To all, the fact that we didn't notice the 1st paragraph of the lede was missing shows the lede still needs to be improved. --A D Monroe III^(talk) 22:41, 14 April 2020 (UTC)