Hacker News Reader

> Who are you "communicating" with?

I wrote this: "with the machines, and with fellow developers"

> A programmer does not communicate with a computer, through a PL

I disagree with this. The programmer describes the steps that the computer needs to perform, to the computer. Or the programmer describes the state which the computer should reach.

The communication is one way (except, arguably, during debugging sessions), but a communication does not need to be two ways.

> He or she writes it down, to later be executed or interpreted, so the computer can "communicate" with the user, through the User interface (not the PL).

You seem to set yourself in the end user perspective, but the developer is also a human, and I'm in the developer's perspective here.

> people should just be vary not to use language ideas for PL.

Agreed, some / many ideas applying to natural languages don't apply to programming languages. But some do.

> the vocabulary works very different

Absolutely. There are strong differences.

(of course, it's fine we don't agree, we are arguing on definitions)

Even if you consider it communication, that doesn't make it a language. Plenty if communication happens through other means.

If we look at the debug session or bash scripting, the closest thing of a two way communication. It doesn't "answer" in code.

I see code closer to something like a Floor Plan an architect may use or a CAD drawing from an engineer. Both of them also communicate, but they are not considered languages. They also have a rules (grammer?) and patterns (vocabulary?).

> Even if you consider it communication, that doesn't make it a language

In my first comment, I have broken down the definition of language I found and (supposedly) successfully applied each part of it to programming languages (communication being only one of the features).

Where is my mistake?

Either the definition is wrong, or incomplete, or one of the matches I made is erroneous, or I missed a match.

> an architect may use or a CAD drawing from an engineer. Both of them also communicate, but they are not considered languages. They also have a rules (grammer?) and patterns (vocabulary?).

Tough one, maybe those drawings are indeed expressed in a language, just that we don't usually see it as a language / think of it like this. That would apply to map symbols as well [1].

edit: Just noticed French Wikipedia [2] actually cites cartography as a language without a syntax, so that would check out:

> la cartographie est un exemple de langage non syntaxique

("Cartography is an example of non-syntactical language")

French Wikipedia broadly has the same definition for language as English Wikipedia, but makes the grammar part optional.

We could argue that the examples you cited are indeed not languages using the English definition because they don't have grammar (if rules you mentions are not grammar - and indeed you would probably not need a pass of syntactical analysis to "parse" a CAD drawing)

[1] https://en.wikipedia.org/wiki/Map_symbol

[2] https://fr.wikipedia.org/wiki/Langage

A language is ... does not mean ... is a language. A dog is an animal but an animal is not always a dog.

I think it's clear for the both of us that PLs are not the same as languages. I would just go a little further and calling it a misnomer. For me that is a helpful framing, especially once you go into visual programming.

> A dog is an animal but an animal is not always a dog.

In this sentence, "is" describes membership (a bit like isinstance in Python, or instanceof in Java or JS). In a definition, this is not the same "is".

In a definition, "is" is the definitional "is", and what is after the "is" is supposed to be a comprehensive list of things you need to match to be called the term preceding the "is" (a bit like "class" or "struct" when you define a type)

Given the definition "A dog is a domesticated animal that has four legs and barks", everything that is an animal, domesticated, that has four legs and that barks is indeed a dog, and something that misses even one characteristic is not a dog (though I made up the definition, it is likely wrong).

Again, polysemy. Not all uses of be are equal. So:

> A language is ... does not mean ... is a language

Indeed, though not for the reasons you had in mind when "A language is ..." is a definition of language: both things around your "does not mean" are indeed true (when you were probably hinting at the second part being false, given your dog example), but the first "is" is definitional, and the second is membership. Both are true because the definition actually defines membership for each individual object described by the definition, and by putting the list of requirements of the definition at the beginning of the sentence, you are describing a particular item that trivially matches the definition. Almost like I did in my example (except I used "everything that", instead of "a").

> I think it's clear for the both of us that PLs are not the same as languages

As natural languages, yes. Which, granted, we would call just languages in everyday life.

> visual programming

How is this related?

I respect your opinion that language in programming language is a misnomer but have not been convinced so far and the more you are writing, the more I'm convinced that your internal definition of language is just too restrictive and I'm also not seeing how this restriction/framing actually helps.

I'm a simple person. You give me a definition of A, you give me something S, if S has all the characteristics given in the definition, S is definitely a A according to this definition.

Now, we can discuss the definition and how it's not entirely (or at all) satisfying, complete, appropriate or useful, and how it could be improved, or how the trick of using qualifiers to further restrict the definition does not cut it.

On this last point, I, so far, have not felt the need to change the definition of language I know to express my ideas clearly, and have been happy to use qualifiers like "natural" or "programming" when needed and unclear from the context. In particular, I have not encountered a situation where calling a programming language a language lead to confusion or bad consequences.

> How is this related?

That is sort of my point, if you think of a PL as a language, visual programming is not related. You are drawing a line somewhere between PL and visual programming. If you think of a PL as a specification, it is the same thing just presented differently.

You can see the vocabulary and the rules of a language as a specification (for the set of productions of the language) if you wish. A language is a specification (although the reverse might not be true).

Visual programming certainly deals with a (visual) programming language, which is still a language. A language doesn't need to be textual. It only needs grammar rules and vocabulary. For instance, taking the example from [1]:

- the "set" block and the "for" block are elements ("words") of the vocabulary of "Snap!"

- 'an identifier i needs to appear in a "set" block before appearing in a "for" block' is a grammar rule of "Snap!" (I would guess)

- 'a "set" block can appear in the body of a "for" block' is also a grammar rule of "Snap!"

You can even build a 1:1 mapping between VL and TL, where VL is the visual language and TL is an equivalent textual language, so the notions are essentially the same.

For me, where the notion of language can be criticized is that for natural languages, the grammar rules and the vocabulary set are ever changing and not always well defined. The rules + vocabulary thing is a model at best.

[1] https://en.wikipedia.org/wiki/Visual_programming_language

Interesting! You seem take "language" really far / different.

How about something like editing an image in Photoshop? There's a vocabulary (the commands) they get applied to the image. There are also rules (constraints). One could argue using photoshop is communicating with a computer, what to do with an image.

So while I say language is a misnomer for PL, you say it's a misnomer for natural languages. ;-)

I guess you could argue for it. Command resize can only be applied after something is selected, and not deselected in the meantime. You might be able to describe the Picture Manipulation Commands language using a finite automaton, and if not, using a grammar.

My views on this are highly shaped by my university lessons on formal languages [1], which I also taught a bit teeny bit. You would have text in mind, but the mathematical concepts are actually more generic than this. One of the exercises was modeling a PIN electronic door lock with a finite state machine (how to unlock without unlocking too early?).

These formalisms look like computer science stuff but are actually directly taken from Chomsky's work [2], a (bio)linguist who was/is actually concerned with human languages (which another commenter implicitly mentioned [3])

I guess this stuff is probably valuable to study natural languages, given the correct scope, since it was made for it (xD). It sure is useful in computer science in any case.

One direct result of his work is the (in)famous stack overflow "You can't parse HTML with a regex" post [4] (since regexes can only define regular languages, and HTML is not a regular language - although I believe the answer is a bit wrong, you can find a regex to parse the regular subset asked in the question, though you need to watch for cdata sections (in XHTML) and script and style tags (in HTML), at which point maybe just use a proper HTML parser unless you are dealing with well known content with no such exceptions)

[1] https://en.wikipedia.org/wiki/Formal_language

[2] https://en.wikipedia.org/wiki/Linguistics_of_Noam_Chomsky

[3] https://news.ycombinator.com/item?id=40480913#40483454

[4] https://stackoverflow.com/questions/1732348/regex-match-open...

> people should just be vary not to use language ideas for PL.

(s/vary/wary/, I suspect.)

Why not? I thought of crafting a system as telling a story about what the system was going to do, whether or not it involved an interaction with users. The syntax and structure is extremely precise compared to literature, but if it doesn't tell the story clearly, it's less likely to be a successful effort, both in use and for maintainers.

To me, the biggest dividing line between mediocre and good programmers is who they write code for.

The mediocre ones write their code for the computer/compiler/interpreter. When it works, they're done.

The good ones write their code for human readers to understand, including their future self.