October 29, 2010 Re: [nomenclature] systems language | ||||
|---|---|---|---|---|
| ||||
Posted in reply to Justin Johansson | On 14/10/2010 13:30, Justin Johansson wrote: > Touted often around here is the term "systems language". > > May we please discuss a definition to be agreed upon > for the usage this term (at least in this community) and > also have some agreed upon examples of PLs that might also > be members of the "set of systems languages". > Given a general subjective term like this, one would have > to suspect that the D PL is not the only member of this set. > > Cheers > Justin Johansson > > PS. my apologies for posting a lame joke recently; > certainly it was not meant to be disparaging towards > the D PL and hopefully it was not taken this way. It's those programming languages whose type systems can be used to move and navigate across water (but can sink if you rock it enough). Compare to other languages whose type systems merely floats on water, but don't move anywhere... (although some guarantee they will never sink no matter how much you rock it!) -- Bruno Medeiros - Software Engineer | |||
October 29, 2010 Re: [nomenclature] systems language | ||||
|---|---|---|---|---|
| ||||
Posted in reply to Bruno Medeiros | Fri, 29 Oct 2010 20:54:03 +0100, Bruno Medeiros wrote: > On 14/10/2010 13:30, Justin Johansson wrote: >> Touted often around here is the term "systems language". >> >> May we please discuss a definition to be agreed upon for the usage this term (at least in this community) and also have some agreed upon examples of PLs that might also be members of the "set of systems languages". Given a general subjective term like this, one would have to suspect that the D PL is not the only member of this set. >> >> Cheers >> Justin Johansson >> >> PS. my apologies for posting a lame joke recently; certainly it was not meant to be disparaging towards the D PL and hopefully it was not taken this way. > > It's those programming languages whose type systems can be used to move and navigate across water (but can sink if you rock it enough). It's probably very hard to find an accurate definition for this kind of term. The same can be said about terms such as 'functional language'. Many 'pragmatic' software engineering terms are based on emotions, broken mental models, inaccurate or purposefully wrong information. In my opinion these are all subtypes of a thing called 'marketing bullshit'. > Compare > to other languages whose type systems merely floats on water, but don't > move anywhere... (although some guarantee they will never sink no matter > how much you rock it!) You can easily create a language with guarantees about safety: no segfaults, no index out of bounds errors, no overflows etc. Some of these languages even guarantee termination. However, they're not Turing complete in that case, which reduces their usefulness. Another thing is, these guarantees can be expensive. However, the trend has been towards higher level languages. One reason is Moore's law, you have achieved the same results with a N times slower implementation using the N times faster hardware. | |||
October 30, 2010 Re: [nomenclature] systems language | ||||
|---|---|---|---|---|
| ||||
Posted in reply to div0 | div0 wrote:
> There's nothing special about a systems language; it's just they have explicit facilities that make certain low level functionality easier to implement. You could implement an OS in BASIC using PEEK/POKE if you mad enough.
I suppose it's like the difference between porn and art. It's impossible to write a bureaucratic rule to distinguish them, but it's easy to tell the difference just by looking at the two. "I know it when I see it!"
| |||
October 30, 2010 Re: [nomenclature] systems language | ||||
|---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | == Quote from Walter Bright (newshound2@digitalmars.com)'s article
> div0 wrote:
> > There's nothing special about a systems language; it's just they have explicit facilities that make certain low level functionality easier to implement. You could implement an OS in BASIC using PEEK/POKE if you mad enough.
> I suppose it's like the difference between porn and art. It's impossible to write a bureaucratic rule to distinguish them, but it's easy to tell the difference just by looking at the two. "I know it when I see it!"
Also known as the Elephant test: "is hard to describe, but instantly recognisable when spotted".
| |||
October 30, 2010 Re: [nomenclature] systems language | ||||
|---|---|---|---|---|
| ||||
Posted in reply to Iain Buclaw | Iain Buclaw wrote:
> == Quote from Walter Bright (newshound2@digitalmars.com)'s article
>> div0 wrote:
>>> There's nothing special about a systems language; it's just they have
>>> explicit facilities that make certain low level functionality easier to
>>> implement. You could implement an OS in BASIC using PEEK/POKE if you mad
>>> enough.
>> I suppose it's like the difference between porn and art. It's impossible to
>> write a bureaucratic rule to distinguish them, but it's easy to tell the
>> difference just by looking at the two. "I know it when I see it!"
>
> Also known as the Elephant test: "is hard to describe, but instantly recognisable
> when spotted".
Yeah. I think it's a waste of our time to try and define what a systems programming language is.
For example, sure, you can write a gc in Java. The problem is, it is not a useful gc. Ditto for anything else "but you can do that in this non-systems language, so your rule is wrong."
| |||
October 30, 2010 Re: [nomenclature] systems language | ||||
|---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | Walter Bright wrote:
> Iain Buclaw wrote:
>> == Quote from Walter Bright (newshound2@digitalmars.com)'s article
>>> div0 wrote:
>>>> There's nothing special about a systems language; it's just they have
>>>> explicit facilities that make certain low level functionality easier to
>>>> implement. You could implement an OS in BASIC using PEEK/POKE if you mad
>>>> enough.
>>> I suppose it's like the difference between porn and art. It's impossible to
>>> write a bureaucratic rule to distinguish them, but it's easy to tell the
>>> difference just by looking at the two. "I know it when I see it!"
>>
>> Also known as the Elephant test: "is hard to describe, but instantly recognisable
>> when spotted".
>
> Yeah. I think it's a waste of our time to try and define what a systems programming language is.
>
> For example, sure, you can write a gc in Java. The problem is, it is not a useful gc. Ditto for anything else "but you can do that in this non-systems language, so your rule is wrong."
Did the term "systems programming language" exist before C? I mean, asm isn't a "systems programming language", it's asm!
Seems to me that it's a market segment term, which just means "competes with C".
| |||
October 31, 2010 Re: [nomenclature] systems language | ||||
|---|---|---|---|---|
| ||||
Posted in reply to Don | Don wrote: > Did the term "systems programming language" exist before C? I mean, asm isn't a "systems programming language", it's asm! > Seems to me that it's a market segment term, which just means "competes with C". The first I encountered the term was the BLISS programming language. I think it means Basic Language for Implementation of Systems Software. BLISS predates C. http://en.wikipedia.org/wiki/BLISS | |||
November 09, 2010 Re: [nomenclature] systems language [OT] [NSFW] | ||||
|---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | On 30/10/2010 02:13, Walter Bright wrote: > div0 wrote: >> There's nothing special about a systems language; it's just they have >> explicit facilities that make certain low level functionality easier >> to implement. You could implement an OS in BASIC using PEEK/POKE if >> you mad enough. > > I suppose it's like the difference between porn and art. It's impossible > to write a bureaucratic rule to distinguish them, but it's easy to tell > the difference just by looking at the two. "I know it when I see it!" In the vast majority of cases, yes, but is it *always* easy to tell the difference? Because if a bureaucratic rule was to made, it would have to work for *all* cases, otherwise it would not be very useful. Consider Chloe Sevigny's blowjob scene in the end of The Brown Bunny (an art house film). Art or porno? Or the photograph "Portrait of My British Wife" by Panayiotis Lamprou: http://www.guardian.co.uk/artanddesign/2010/sep/17/panayiotis-lamprou-portrait-wife-photography which will be displayed in the National Portrait Gallery. Art or porno? -_-' -- Bruno Medeiros - Software Engineer | |||
November 09, 2010 Re: [nomenclature] systems language | ||||
|---|---|---|---|---|
| ||||
Posted in reply to retard | On 29/10/2010 21:30, retard wrote: > Fri, 29 Oct 2010 20:54:03 +0100, Bruno Medeiros wrote: > >> On 14/10/2010 13:30, Justin Johansson wrote: >>> Touted often around here is the term "systems language". >>> >>> May we please discuss a definition to be agreed upon for the usage this >>> term (at least in this community) and also have some agreed upon >>> examples of PLs that might also be members of the "set of systems >>> languages". Given a general subjective term like this, one would have >>> to suspect that the D PL is not the only member of this set. >>> >>> Cheers >>> Justin Johansson >>> >>> PS. my apologies for posting a lame joke recently; certainly it was not >>> meant to be disparaging towards the D PL and hopefully it was not taken >>> this way. >> >> It's those programming languages whose type systems can be used to move >> and navigate across water (but can sink if you rock it enough). > > It's probably very hard to find an accurate definition for this kind of > term. The same can be said about terms such as 'functional language'. Many > 'pragmatic' software engineering terms are based on emotions, broken > mental models, inaccurate or purposefully wrong information. In my > opinion these are all subtypes of a thing called 'marketing bullshit'. > > >> Compare >> to other languages whose type systems merely floats on water, but don't >> move anywhere... (although some guarantee they will never sink no matter >> how much you rock it!) > > You can easily create a language with guarantees about safety: no > segfaults, no index out of bounds errors, no overflows etc. Some of these > languages even guarantee termination. However, they're not Turing > complete in that case, which reduces their usefulness. Another thing is, > these guarantees can be expensive. However, the trend has been towards > higher level languages. One reason is Moore's law, you have achieved the > same results with a N times slower implementation using the N times > faster hardware. Why this serious reply? Perhaps I fell victim to an overly accurate analogy, but my previous post was a joke/satire. -- Bruno Medeiros - Software Engineer | |||
Copyright © 1999-2021 by the D Language Foundation
Permalink
Reply