Talk:System programming language

Unnamed section

This page is largely redundant with Ousterhout's dichotomy. One of these should be assimilated into the other. --FOo 03:13, 4 May 2004 (UTC)

The concept of "system programming language" was around long before Ousterhout - I remember discussing the concept in 1981, and there was a minor industry in system programming languages before C came to dominate. "Ousterhout's dichotomy" could be redirected to reinvention of the wheel :-), or just cut down to say that he made the observation and to explain his viewpoint, while this article focuses just on the history and characteristics of system programming languages. Stan 12:54, 4 May 2004 (UTC)

I've added a para explaining the usage of "system programming language" as "a language for system programming" in the sense of system programming. In fact, I feel sure this is the dominant usage, and that the primary definition on this page is wrong. Mhkay 09:37, 13 September 2005 (UTC)

The description of scripting languages here is very dubious. They have little or no support for complex data structures? They typically have a lot more support than C, which doesn't even have a native string class. Perl, Ruby, and Python, are full of data-structure support out of the box that you don't have in C. Nor are scripting languages necessarily interpreted. Some are byte-compiled to run on a virtual machine. --OinkOink 05:27, 1 January 2007 (UTC)

I've now edited the offending paragraph accordingly. --OinkOink 06:11, 9 February 2007 (UTC)

I agree with the idea of editing this page to remove material that's redundant with Ousterhout's dichotomy. I've recently expanded that page, so the material on this page is less complete than what's on the other page. This page would be better if it just focused on system programming. And by the way, I'll be the first to admit that both system programming and scripting were around a long time before I started on Tcl; I'm not even sure I'm the first person to have observed the distinction between them. --John Ousterhout 05:08, 28 September 2007 (UTC)

I left the Ousterholt material alone, but agree it should go somewhere else. I added some material on the history of system programming languages, viewing them as being in 3 phases: first, assemblers with high-level syntax, second, general languages with `system programming' extensions (re LRLTRAN: only in Fortran IV could character processing be considered system programming; their point was they wanted to write compilers in it); and third, reduced high-level languages optimized for systems tasks (namely BCPL and C). I left the early discussion of BCPL alone, deciding it would be better to remove the scripting material and then rework the flow. Other things that could be mentioned in the article: ESPOL (Burroughs Algol, useful for writing systems software because the hardware (B5000 and successors) was already high-level; PL/S, IBM's PL/I-like language in which chunks of MVS and similar OSes was written; EPL and then PL/I, in which Multics was written; and PL/M. Vmanis (talk) 20:27, 17 December 2011 (UTC)

List of languages

I agree with the comment by vmanis. I added a somewhat idiosyncratic list of what I consider "major" system programming languages, leaving aside languages like PL/P, PL-6, npl (pretty much an extension of ESPOL?). The list is more or less in chronological order. Other people may have other thoughts on what's "major." Peter Flass (talk) 19:00, 22 January 2012 (UTC)

I think that Go should be removed from that list. Rob Pike has made concessions that his use of the term "systems language" did not match the common usage. This is most clearly stated in Lang.Next 2014 at about 6:50 (topic is about 4:00). Though he slightly reverts that statement after Andrei provides his criteria. --he_the_great (talk) 17:40, 26 August 2014 (UTC)

Should we split D into D1 and D2? They are quite different. 2601:9:8280:6BF:0:0:0:A180 (talk) 04:52, 11 June 2015 (UTC)

I/O

I added the following quote from the BLISS Language manual quoted in the BLISS article: "because a system-software project usually develops its own input/output or builds on basic monitor I/O or screen management services." Unfortunately I can't seem to find the actual quote to cite it. At any rate, I thought it was a valuable addition because it seems a feature of many system programming languages. After all, even C does I/O thru library calls rather than within the language. Peter Flass (talk) 14:14, 23 January 2012 (UTC)

Rework

Once you start editing an article, it's hard to know where to stop.

I rearranged some of the article, moving the definition to the top and putting "Osterhout's dichotomy" farther down in it's own section, though I feel there's still a bit too much here, especially as it has an article of its own and this just duplicates what's there. Also, this does nothing to describe the 80% of languages that are neither systems or scripting languages. Peter Flass (talk) 14:58, 23 January 2012 (UTC)

Osterhout's dichotomy

I compared this article and the Osterhout one, and they had almost exactly the same discussion. I deleted the Osterhout section here, and added a wikilink to the other article under "see also." Ont the other hand, now this article could use expanded discussion on the characteristics of systems languages. Peter Flass (talk) 20:01, 24 January 2012 (UTC)

SPL or SPL-3000?

All the languages in the HP3000 that I remember, were called Cobol-3000, Basic-3000, Fortran-3000, and so on. As far as I remember, the Systems Programming Language was called SPL-3000. The OS was called MPE followed by a roman number for the version. For example MPE-IV. At that time, there where no standards. The Fortran-3000 was a Fortran-IV extended with recursive calls. All the other programming languages which normally didn't support recursive calls, were recursive in the HP3000 version. The reason is that the CPU had a stack architecture. If I could find my dusty manuals, I could be sure that the name was SPL3000. If it is right I could change "SPL," to "SPL, really SPL-3000, " in the section about the HP3000 Systems Programming Language. The system calls called Intrinsics could be done in every other programming languages, with some limitations in Basic-3000, because it was an interpreted language although could be compiled, but I do not recall the limitations. However, Fortran could be used to do systems programing in that computer. — Preceding unsigned comment added by 189.233.107.254 (talk) 10:03, 16 March 2017 (UTC)

The Android app redirects every "C++" link to "C (third letter of the Latin alphabet)"

I've attempted to fix the issue mentioned the subject, but I did it the wrong way therefore the article has been immediately reverted.

Please, could any of the experienced editors here check this issue? I'd like to understand why those links don't work as expected and how to fix them properly.

I'd appreciate any help.

Fabio Maria De Francesco (talk) 15:30, 16 April 2019 (UTC)

OK, weird. Sorry. Must be an Android thing (Silk?). Let's leave it. Peter Flass (talk) 15:39, 16 April 2019 (UTC)

If I understand correctly your reply, you exclude any wrongdoing in using the Wiki syntax. Therefore this issue should be reported to the attention of the developers with Wimedia.org. I have their email address, that is mobile-android-wikipedia@wikimedia.org. If you agree, I would be glad to send them a copy of this section. Fabio Maria De Francesco (talk) 16:40, 16 April 2019 (UTC)

what is system software?

Another editor and I have been having a discussion about what constitutes system software, so I thought I’d bring it here to get a third opinion. I believe, as the article originally read, that assemblers, compilers, linkers, etc. should be included. As amended the article now excludes these. Thoughts? Peter Flass (talk) 02:28, 28 June 2019 (UTC)

Include Carbon in the list?

It isn't really major but due to its interoperability with C++ and similarity I feel like it would be used as a system programming language, however I don't know of any examples of its use. 240claytongearhart (talk) 19:59, 3 August 2023 (UTC)