Zompist Bboard Again

How different would they be if they had been, in the main, developed by speakers of agglutinative or polysynthetic languages, or even of fusional languages, rather than of largely isolating languages?

alice wrote: ↑Sun Dec 20, 2020 11:24 am How different would they be if they had been, in the main, developed by speakers of agglutinative or polysynthetic languages, or even of fusional languages, rather than of largely isolating languages?

The thing about programming languages is that they mostly represent operations upon data, either functionally (one takes old data and from it produces new data) or imperatively (one modifies existing data in place), and I don't see how that would change no matter what the native languages of their creators are. Also, programming languages lack many of the things that natural languages have that are represented differently depending on whether they are isolating, agglutinative, or fusional, such as person, number, tense, aspect, evidentiality, or so on (arguably programming languages do represent possession). However, language syntax may be affected, since the syntax of existing programming languages is mostly isolating aside from a few exceptions such as the use of sigils in shell, Perl, and PHP, the syntax of string formatting in languages such as C, and the syntax of regular expressions.

Programming languages are artificial languages. If our first conlangs mirror our native languages, then could it be that OOP would've been developed earlier and it would've been more tightly integrated with syntax?

PS. The first programming language, Plankalkül, was actually developed by a German speaker.

alice wrote: ↑Sun Dec 20, 2020 11:24 am How different would they be if they had been, in the main, developed by speakers of agglutinative or polysynthetic languages, or even of fusional languages, rather than of largely isolating languages?

Some things of programming languages would probably be indicated with morphology(+syntax) rather than punctuation(+syntax), I think. Or with a different syntax even.

One thing I notice is that the member access syntax in C structs, and therefore many other modern languages, is similar to the Arabic ʔidˤāfa indicating possession while requiring a strict order and nothing in between: student.name —the dot is basically like the Arabic space between possessum and possessor. I suspect this is so as a metaphor of English free noun + noun compounding, "this is a student name" (even the word order is reflected). If more early languages had been made by Spanish speakers, maybe we'd see
name de student
instead, or with a sigil to represent value loading,
$name de student.
And if it had been ancient Romans, maybe even
name student&
with "&" standing for a genitive inflection of the variable.

Recall how by convention most languages use !myboolvar, conventionally with no space (although spacing can often be added) in order to negate boolean variables, but Python uses not myboolvar, much like my imaginary Spanish-based language
name de student

Because of C, many programming languages have condition expressions that look like:
(myboolvar? "alice" : "bob")
which seems to imitate English "if he is an ZBB oldbie, alice, otherwise bob". Python does something Different:
"camilla" if myboolvar else "daniel"
but that is also readable as English, it just changes the constituent order so that instead of "?" and ":" the words "if" and "else" may be used. Classical Chinese has a condition syntax that can also look like (x? a:b), but it very often just uses "then" in the apodosis, literally "she is loved, it's then emilia, otherwise frankie". So an alternative programming language syntax could exist along these lines (with keywords in another language of course):
myboolvar then "emilia" otherwise "frankie"
or,
myboolvar then "emilia" or-if-not "frankie"
This is the same as (x? a:b) syntactically from the computer's point of view in the end, but it is a different metaphor from the human point of view (the "?" in C suggests it delimits the condition in question, rather than mark the result if true).

rotting bones wrote: ↑Sun Dec 20, 2020 2:34 pmProgramming languages are artificial languages. If our first conlangs mirror our native languages, then could it be that OOP would've been developed earlier and it would've been more tightly integrated with syntax?

I don't think so, because you can kind of do OOP in C as it is? Use structs for encapsulation, factory functions as class constructors that integrate inheritance, and then you fake polymorphism with appropriate identifiers in the structs + checks in the functions. Definitely not a normal way to write things in C though. Things like Python and C# just make this stuff easier to read and write, so you have incentives to use them.

Maybe OOP wasn't born earlier because no one really thought about that style of programming... Structs were deemed good enough data holders, and everything else could be parades of functions at the same level, with no encapsulation beyond the file itself, marching down the lines.

Many styles are supported by many languages. Nevertheless, they differ by the prominence of some features over others. The analogy I see is the following:

Non-analytic languages move qualifiers from vocabulary to grammar. Eg. Instead of using the word "tomorrow" in the appropriate way, you conjugate the verb to indicate that the action takes place tomorrow.

The OOP style moves the attributes of data from how it is used to how it can be used. Eg. Instead of manually updating the features relevant to tomorrow, you ask the data to execute the relevant method.

As for how syntax could be more tied up with OOP features, maybe Smalltalk's message passing would be the default syntax. Or maybe this would still be unusably crazy, but for slightly different reasons: https://esolangs.org/wiki/Glass

PS. I understand if people think this similarity is too abstract to matter, but does anyone think this similarity is not there?

PPS. Also, the whole point of modern math is to use symbols instead of words.

alice wrote: ↑Sun Dec 20, 2020 11:24 am How different would they be if they had been, in the main, developed by speakers of agglutinative or polysynthetic languages, or even of fusional languages, rather than of largely isolating languages?

COBOL would probably look different. I'm not convinced other language types would be affected; they are much more based on math notation than on natural language.

The thing is, natlang verbs-- where most of the complexity lies in agglutinative or polysynthetic languages-- mainly use parameters of inflection that are largely useless for programming: person, number, gender, animacy, time, aspect, evidentiality, valence, degree of reality, plus interpersonal things like politeness and (anti)benefactives. The speech acts relevant to programming are largely restricted to imperatives and declaratives.

You could make a better case that syntax affects programming languages. But English being SOV didn't prevent (say) predicate calculus being VSO.

COBOL was before my time. Inform 7?

PS. Then again, I'm not sure the presence of inflections would directly make a difference to any of these languages.

Personally, I don’t think programming language design has much to do with the typology of the designer’s language. (Writing system might have some influence, but it’s hard to know, and anyway that’s hardly a fundamental property of a language.) Rather I agree with zompist, in that it has more to owe to mathematical notation and similar DSLs.

This doesn’t mean that you can’t apply linguistic techniques to programming languages, though. For instance, one interesting observation is that programming languages are very consistently head-first (heads underlined):

function(value1, value2, value3)
structure.field
if (condition) { result1 } { result2 }
return value

MOV edx,len
MOV ecx,msg
MOV ebx,1
MOV eax,4
INT 0x80

SELECT column1, column2
FROM table
WHERE condition
ORDER BY column3

(defun quadratic (a b c) (/ (+ (- b) (sqrt (- (* b b) (* 4 a c)))) (* 2 a))

import Data.List
rle :: Eq a => [a] -> [(a, Int)]
rle x = fmap (\xs -> (fst xs, length xs)) (group x)

(And, interestingly, they seem to be getting more head-first rather than less: for instance, recently there has been a trend towards variable : type rather than type variable.)

Now why might this be? Personally, I think it has to do with the capabilities of computers: if you have various operations with varying numbers of parameters, it can be easier to parse the operation first, figure out how many parameters there are, and then parse those. This was the design used in the first assembly languages, and I’m sure the continuing influence of that design is a big reason why programming languages are still head-first today. One exception is stack-based languages, which are strongly head-final; for some reason, those never caught on, though I’m personally fond of them. (Perhaps if we all spoke Turkish and Basque they would have been more successful.)

Depending on how you look at it, I suppose you can also find other linguistic features in various programming languages, though it may be a bit of a stretch:

• J is a standout in this regard: even apart from classifying its operations into ‘nouns’, ‘verbs’, ‘adverbs’ and ‘conjunctions’, it also has what could be called number agreement (with the rank conjunction "), serial verb constructions (e.g. average is (+/ % #)), valency manipulation (e.g reflexive, x u x = u~ x), and noun incorporation (e.g. rounding to nearest integer is (<. @: (0.5&+))).
• You could, I suppose, call some shell commands polysynthetic, in that they have a ‘verb’ followed by many modifiers. On the other hand, you might consider those modifiers to be more like prepositions, in that they have relative freedom of position.
• INTERCAL has politeness levels, though more as a joke than anything else.

i noticed in high school that it seemed common when naming variables to put the noun first and descriptors after .... e.g. Door1, Door2, DoorFront, DoorBack, DoorHardToSee. I wonder if the precedent was set by numbers. Or maybe that's not such a trend at all .... I'd had limited exposure to programming at the time and really Im still only capable of scripting languages.

C does have some unusual either way constructions - preincrement ++x but postincrement x++, and as elements of an array, x[5] and 5[x] are equivalent.

rotting bones wrote: ↑Sun Dec 20, 2020 7:54 pm COBOL was before my time.

No it wasn't... or isn't. We are still in the COBOL era.

wikipedia wrote: In 1997, the Gartner Group reported that 80% of the world's business ran on COBOL with over 200 billion lines of code and 5 billion lines more being written annually.

...In 2006 and 2012, Computerworld surveys found that over 60% of organizations used COBOL (more than C++ and Visual Basic .NET) and that for half of those, COBOL was used for the majority of their internal software.

zompist wrote: ↑Sun Dec 20, 2020 9:17 pm No it wasn't... or isn't. We are still in the COBOL era.

wikipedia wrote: In 1997, the Gartner Group reported that 80% of the world's business ran on COBOL with over 200 billion lines of code and 5 billion lines more being written annually.

...In 2006 and 2012, Computerworld surveys found that over 60% of organizations used COBOL (more than C++ and Visual Basic .NET) and that for half of those, COBOL was used for the majority of their internal software.

These are legacy systems, right? COBOL ranks below Fortran: https://www.tiobe.com/tiobe-index/

Edit: "Should one consider writing new applications in COBOL? No." - https://medium.com/@jankammerath/why-an ... 0a0cc7ce74 As for Fortran: http://www.moreisdifferent.com/2015/07/ ... e-fortran/

rotting bones wrote: ↑Sun Dec 20, 2020 9:26 pm These are legacy systems, right? COBOL ranks below Fortran: https://www.tiobe.com/tiobe-index/

I wouldn’t trust TIOBE too much. Though in this case, it happens to be correct: no-one is writing new applications in COBOL now.

zompist wrote: ↑Sun Dec 20, 2020 6:02 pmI'm not convinced other language types would be affected; they are much more based on math notation than on natural language.

Yeah, I think that's right about many things. Do you (or anyone else) know if there's something in (commonly-used) math notation that resembles the use of the dot to access struct members?

Kuchigakatai wrote: ↑Mon Dec 21, 2020 1:17 am

zompist wrote: ↑Sun Dec 20, 2020 6:02 pmI'm not convinced other language types would be affected; they are much more based on math notation than on natural language.

Yeah, I think that's right about many things. Do you (or anyone else) know if there's something in (commonly-used) math notation that resembles the use of the dot to access struct members?

Not that I know of. It seems to have originated in PL/I (see the 1965 manual, page 27), and was then popularized in Simula 67.

bradrn wrote: ↑Sun Dec 20, 2020 10:15 pm I wouldn’t trust TIOBE too much. Though in this case, it happens to be correct: no-one is writing new applications in COBOL now.

The quote I posted about COBOL not being used is unaffiliated with TIOBE AFAIK.

rotting bones wrote: ↑Sun Dec 20, 2020 9:26 pm Edit: "Should one consider writing new applications in COBOL? No." - https://medium.com/@jankammerath/why-an ... 0a0cc7ce74 As for Fortran: http://www.moreisdifferent.com/2015/07/ ... e-fortran/

You realize that this article supports my point? It talks about how COBOL is widely used, effective for its purpose, and hard to get rid of; also that COBOL devs are well paid. And recommends that developers learn COBOL!

I'm not some sort of COBOL fan; I learned it in the 1980s just to have more options. But it's a blind spot of many developers to think that only the languages they happen to use are the most important ones.

(At my university, there were two separate majors. Mine was "computer science", in the Tech school, and focused on assembly and Fortran; we looked down on the "computer studies" people in Arts &Sciences who learned COBOL. For my COBOL course I had to run programs on the IBM mainframe in the admin building since Tech didn't even have any IBM equipment.)

zompist wrote: ↑Mon Dec 21, 2020 4:52 pm You realize that this article supports my point? It talks about how COBOL is widely used, effective for its purpose, and hard to get rid of; also that COBOL devs are well paid. And recommends that developers learn COBOL!

I'm not some sort of COBOL fan; I learned it in the 1980s just to have more options. But it's a blind spot of many developers to think that only the languages they were trained in are actually used.

Sure, thanks for the reminder. The textbook of the class I taught this semester mentions that COBOL is still widely used. Nevertheless, I don't know anyone in my generation who is learning COBOL. That's what I meant when I said it's from before my time. The math people are excited about Agda. The software developers are excited about Rust. The money people are talking about the Q programming language. Maybe I should be the one to master COBOL. Impressive that it's still on the list of the most used programming languages.

rotting bones wrote: ↑Mon Dec 21, 2020 5:02 pm

zompist wrote: ↑Mon Dec 21, 2020 4:52 pm You realize that this article supports my point? It talks about how COBOL is widely used, effective for its purpose, and hard to get rid of; also that COBOL devs are well paid. And recommends that developers learn COBOL!

I'm not some sort of COBOL fan; I learned it in the 1980s just to have more options. But it's a blind spot of many developers to think that only the languages they were trained in are actually used.

Sure, thanks for the reminder. The textbook of the class I taught this semester mentions that COBOL is still widely used. Nevertheless, I don't know anyone in my generation who is learning COBOL. That's what I meant when I said it's from before my time. The math people are excited about Agda. The software developers are excited about Rust. The money people are talking about the Q programming language. Maybe I should be the one to master COBOL. Impressive that it's still on the list of the most used programming languages.

I don't think you're getting what I'm saying. You think, in 2020, that COBOL was "before your time". The cool kids don't learn it. Your program doesn't teach it. I felt the exact same thing in 1980. Yet COBOL was thriving then and is still thriving today. It's like a whole stealth industry hidden from most developers.

Several people I know deliberately hide their COBOL knowledge, lest they be assigned to maintenance contracts...

(In much the same way, I don't mention IIS, Websphere and Windows Server on my resume...)

Typically it's not taught in university anymore. Companies provide the training.
From what I hear it's awfully boring but kind of relaxing. carefully considering night time batches is better for your blood pressure than the "everything should be in production yesterday web projects.