Too many programming languages?

[Cerebus]

Oh yes, quite correct. The continuation mark was anything in column 6, between the label and the code. It's (thankfully) been almost 40 years since I did fortran.

More like 30 in my case, and even by then you could discard all the 'this language was written assuming it was going on punch cards' stuff. Oh, and that FORTRAN I was writing back in the late 80s? AI! AI in FORTRAN!<sup>*

*</sup>For those who don't get why this is 'a thing' and gains me serious street cred points: Real Programmers Don't Eat Quiche

[brucehoult]

Oh yes, quite correct. The continuation mark was anything in column 6, between the label and the code. It's (thankfully) been almost 40 years since I did fortran.

More like 30 in my case, and even by then you could discard all the 'this language was written assuming it was going on punch cards' stuff. Oh, and that FORTRAN I was writing back in the late 80s? AI! AI in FORTRAN!^*

The FORTRAN programming I did was on actual punched cards. Pre-scored ones such that you pushed out the chads with a paper clip or ballpoint pen or similar. The pre-scored stuff was only in every 2nd column of a standard card so you only got 40 columns. A utility was run between the card reader and the compiler to remove every second character from each line. But you could do that at the comfort of your own desk rather than booking time on one of the rare card punch machines. And 40 columns was usually more than sufficient anyway.

[Cerebus]

Back in my punch card days I had the luxury of proper punch operators to turn my scribbles into crisp 80 column cards. I might get to punch a few corrections myself but I used to work at times when there wasn't a queue for the punch machines so it wasn't too bad. Worst case I might have to use one of the manual desktop 'chord' punches. Slow overall, but it made you careful and you never ran out of bookmarks, or something to write your shopping list on.

[westfw]

It's interesting the way that improvement in editors has affected programming languages.  Fortran's column-oriented approach worked swell on the card punches of the day, which were easily configured with "tabs stops" at appropriate columns.  DEC's early fortran compilers supported use of the TAB character in source code, so you didn't have to type all those spaces, and could easily enter code on those interactive terminals like ASR33s that didn't have the keypunch tab stops.  (probably you can blame DEC for uses of actual tab characters in source code.  And the 8column default.   Saved space, you know.)
We eventually gave up on the "tabs vs spaces" arguments about source code in favor of "tab stops are every 8 spaces, and indent level is 4 spaces, but feel free to use whatever combination of tabs and spaces or just spaces or just tabs that you like, and configure your editor appropriately!")

In theory, python's use of whitespace to indicate syntax "bothers" me, but with any modern syntax-aware editor, it's pretty much a non-issue.  And Python seems to be very good at detecting indentation mistakes (much better than C's reaction to a missing brace, for instance.)

[Berni]

Yes Python will generally throw errors at you if your indentation does not make sense. Also if you are using any proper code editing software (I like Sublime Text myself) it won't even allow you to put a tab into the file (on default settings) as it will always save as spaces, yet still looks like a tab in the editor.

Even worse bugs can be caused in C by putting too many ; in your code.

For example:

Code: [Select]

i = 10;
while(i);
{
   printf("%d",i);
    i--;
}
What do you think this code will do?

[Mechatrommer]

For myself, I only care about whether syntax makes it easier or more difficult to make mistakes. The semantics of a language are far more interesting and important.

It's always easy to make mistakes.

afaik, there is no cure to semantics error. for example when you derive a formula by mistake, instead of the correct formula y = 2x + 30, you get the derivation of y = 3x + 30. you punch that in your IDE, eeek, wrong output. that is just a simple random example, in reality there are more delusive semantics errors. its not computer language thing, its more to human error thing, "procedural" errors is another thing. no magnitude of programming language and syntax can fix this. although in C/C++, it has syntaxes/operators that prone to producing semantics error such as when we just want to compare a variable to a value, instead of assigning to it, the correct syntax is if (x == 1), if we type if (x = 1) in C, something will screw up, programmers just need to be cautious in this matter. modern language like Basic is more bulletproof regarding this matter, it just know when we want to compare or assign. but we cant blame C for this because it was designed to be compact, provides shortcut (less typing, except the ; thing) and multi purpose in one line of code, and there will be always workaround to that or imposing some rules or coding style to avoid errors. drawback is we need to be really careful with precedences and the meaning of it, if.. one decides to use the compactness feature of C, but they are still free to use bloated feature one line for each purpose syntaxes (code lines). if a man cant cope with this, or things like buffer overflow handling, he should not touch C/C++ with a barge pole. otoh regarding the punch card... i have no objection to ";" if we are planning to go back to stone age.

[bpiphany]

Even worse bugs can be caused in C by putting too many ; in your code.

For example:

Code: [Select]

i = 10;
while(i);
{
   printf("%d",i);
    i--;
}
What do you think this code will do?

Oh my god, how that one has bitten me =P That works in Java too, right? I'm not sure. I mostly do python nowadays.

And btw, tabs are an abomination. They should be avoided at all cost. And don't even get started on putting curly braces on their own row =D

[legacy]

The language I am designing (hobby project)

can you tell me more?

[legacy]

Python seems to be very good at detecting indentation mistakes (much better than C's reaction to a missing brace, for instance.)

Sci-tools Understand and Stood are able to detect missing brace better than how gcc and llvm do.

[Nusa]

Don't forget that whitespace in C/C++ is a lot more than just tabs and spaces:

Code: [Select]

int test()
{
    return
    (

        2

        +

        2

        +

        3

    )

    *

    10
    ;
}
Perfectly legal code, even if it looks silly. Of course, with longer expressions instead of simple numbers, it might be done on purpose for clarity/self-documentation purposes.

[Cerebus]

In theory, python's use of whitespace to indicate syntax "bothers" me, ...

The reason for that is that somewhere, even if only subconsciously, you know that there's a horrible bodge going on, and instead of a well-defined formal grammar for the language there's some god awful hack going on somewhere.

Out of curiosity I 'git cloned' the cpython repository today and went off to find that hack. In the grammar for the language there are two terminals 'INDENT' and 'DEDENT'. Then buried in the tokenizing code is a 700 line monster procedure 'get_tok' that deals with the business of processing the current indent level and that's only part of the whole tokenizer, which is 1850 lines. By contrast, the tokenizer for most well specified languages is a few hundred lines in total. Pushing that context sensitivity (to indents) down into the tokenizer means that the grammar does not tell the whole story, and consequently the actual grammar of the language: (1) is not formally specified, (2) probably hides some nasty surprises.

[SiliconWizard]

It's interesting to know a bit about the history of Python to understand where it comes from, how and why it was designed.
https://en.wikipedia.org/wiki/Python_(programming_language)

As explained, its roots lie in the ABC language: https://en.wikipedia.org/wiki/ABC_(programming_language)

I doubt the author anticipated the traction that it would get.

[emece67]

.

[brucehoult]

Code: [Select]

i = 10;
while(i);
{
   printf("%d",i);
    i--;
}
What do you think this code will do?

Another reason to put opening braces not at a new line. Nobody will write:

Code: [Select]

i = 10;
while(i) {;
   printf("%d",i);
    i--;
}


But if they do, it will be fine.

The more important thing is no one will write:

Code: [Select]

i = 10;
while(i); {
   printf("%d",i);
    i--;
}

I fully support C# (I think?) forcing you to type the {} even if there is only one statement.

Where I depart from them is making it compulsory to write "break" at the end of every option in a switch. If fall-through is banned then just make it happen automatically and not need the break. What they've done goes I think too far in keeping nominal compatibility with C and Java syntax when it's not actually compatible at all.

[westfw]

detect missing brace better than gcc

gcc seems to be particularly horrible.  IIRC, one of the "teaching advantages" of University implementations (PL/C, WatFor, etc) was supposed to be MUCH BETTER error messaging than the industry equivalents.  We could do with another round of that sort of thinking.  Maybe Python "got it."

instead of a well-defined formal grammar for the language there's some god awful hack going on somewhere [in Python]

Yes, that could be it.  Well-defined Grammars were a big thing when I went to school; I think the world was essentially working on its first generation of languages that could be described that way (Pascal!)
OTOH, perhaps the strict separation of lexical analysis and parsing is partially responsible for the apparent inability to unwind things and produce reasonable error messages...

[brucehoult]

detect missing brace better than gcc

gcc seems to be particularly horrible.  IIRC, one of the "teaching advantages" of University implementations (PL/C, WatFor, etc) was supposed to be MUCH BETTER error messaging than the industry equivalents.  We could do with another round of that sort of thinking.  Maybe Python "got it."

That, plus fast compiling to code that was not close to the best possible, but much faster than an interpreted language and fine for something that was typically only run once or twice.

I thought I'd try knocking my HiFive Unleashed (64 bit RISC-V) back from its usual 1.5 GHz to 1 MHz and compiling gcc -O0 hello.c -o hello. Sadly, it turns out any setting slower than 37.75 MHz gives 37.75. Grr. I'd have thought it could run slower than that. I'm sad because the otherwise very similar (but 32 bit, and 180nm instead of 28nm) FE310  very happily runs at 16 MHz by default in the Arduino environment, and I bet it would go slower.

However, instead of the normal 0.275 real 0.2 user, at 37.75 MHz I get  6.1 seconds real and 4.6 seconds user time. So 39.74x slower clock gives 22.2x slower execution. I guess because cache misses and disk access gets a whole heck cheaper, relatively.

I don't remember exactly, but I think five or six seconds was about the time for compiling a small Pascal program on the VAX 11/780 or PDP 11/70. The PDP 11/70 ran the microcode engine at 6.7 MHz and the fastest instruction, register to register move, took 2 clock cycles. So effectively 3.3 MHz in modern RISC terms.

So, to a first approximation, modern gcc/as/ld is 10x less efficient than compilers on the PDP 11, even at -O0.

gcc -S (just producing assembly language), takes 2.35 real, 1.85 user at that same 37.75 MHz clock on the HiFive Unleashed, and gcc -c (running the compiler and assembler but not linker) takes 2.85 real, 2.0 user. So it's the gnu linker taking most of the time.

[chickenHeadKnob]

  IIRC, one of the "teaching advantages" of University implementations (PL/C, WatFor, etc) was supposed to be MUCH BETTER error messaging than the industry equivalents.  We could do with another round of that sort of thinking.  Maybe Python "got it."

Looks at Westfw flag, blinks.

Dude! you used Waterloo Fortran during your learn-denings? RESPECT

I thought that was only a Canadian thing. On punched cards I bet, I was pretty much in the last cohort punched card students. Maybe the year after me as well. We must be of similar ripeness antiquity.

[brucehoult]

  IIRC, one of the "teaching advantages" of University implementations (PL/C, WatFor, etc) was supposed to be MUCH BETTER error messaging than the industry equivalents.  We could do with another round of that sort of thinking.  Maybe Python "got it."

Looks at Westfw flag, blinks.

Dude! you used Waterloo Fortran during your learn-denings? RESPECT

I thought that was only a Canadian thing. On punched cards I bet, I was pretty much in the last cohort punched card students. Maybe the year after me as well. We must be of similar ripeness antiquity.

I used both WATFOR and WATBOL as a student in around 1981 to 1982. In New Zealand.

That was using VT52 terminals. I only used punched cards for Burroughs FORTRAN IV at high school, and for a statistics course at university using some home-grown array-processing stats language developed by Bill Rogers (who seems to still be there 38 years later... https://www.cms.waikato.ac.nz/people/coms0108)

[westfw]

you used Waterloo Fortran during your learn-denings? RESPECT
I thought that was only a Canadian thing. On punched cards I bet

University of Pennsylvania, EE81.  So my first Fortran Class was '77?IIRC, we had one or two assignments to be done on punched cards, and then they started letting us use the CRT terminals (with a whopping 2400bps local connection!  Still, there were a lot more CRTs than card punches, at the time.)
They had a Univac 90/70, which was an "IBM 360 Compatible" of some sort.  I was blissfully unaware of purchasing politics, but I imagine that that means they didn't have the IBM compilers (and, I guess, they had cheaper CRT support, and JCL was easier.)  I don't know if there were any native Univac tools.  So they had PL/C from Cornell, WatFor from Waterloo, a homegrown APL, a PDP/11 emulator from somewhere, and so on...
The DEC-10 I worked on was in the business school, and had a pretty full suite of DEC tools...
Post-GNU folks don't seem to realize how much of a hotbed of "open source" the University environment used to be.  Vendors would license source code to the universities, and they'd improve stuff and send it back.  OS, shells, networking code, languages, editors - all passed around the keg at a frat party...  (Businesses too.  It's not like there were enough SW engineers to work at the actual vendors!)

[obiwanjacobi]

The language I am designing (hobby project)

can you tell me more?

WIP:
https://obiwanjacobi.github.io/Zlang/

[obiwanjacobi]

In theory, python's use of whitespace to indicate syntax "bothers" me, ...

The reason for that is that somewhere, even if only subconsciously, you know that there's a horrible bodge going on, and instead of a well-defined formal grammar for the language there's some god awful hack going on somewhere.

Out of curiosity I 'git cloned' the cpython repository today and went off to find that hack. In the grammar for the language there are two terminals 'INDENT' and 'DEDENT'. Then buried in the tokenizing code is a 700 line monster procedure 'get_tok' that deals with the business of processing the current indent level and that's only part of the whole tokenizer, which is 1850 lines. By contrast, the tokenizer for most well specified languages is a few hundred lines in total. Pushing that context sensitivity (to indents) down into the tokenizer means that the grammar does not tell the whole story, and consequently the actual grammar of the language: (1) is not formally specified, (2) probably hides some nasty surprises.

It is not about the number of characters needed to make an indent (mentioned earlier) or how complex the code is in the lexer. It is about how readable and easy it is for the developer/user. More advanced features will take more code to create them.

I don't see why the grammar would not tell the whole story when the tokenizer creates the INDENT and DEDENT tokens? These tokens are still used by the grammar...
But then, I am just starting in this whole compiler stuff...
I have seen an INDENT/DEDENT impl within <guess> 50 lines of code so, perhaps your example was not the best?

[Berni]

But if they do, it will be fine.

The more important thing is no one will write:

Code: [Select]

i = 10;
while(i); {
   printf("%d",i);
    i--;
}

I fully support C# (I think?) forcing you to type the {} even if there is only one statement.

Where I depart from them is making it compulsory to write "break" at the end of every option in a switch. If fall-through is banned then just make it happen automatically and not need the break. What they've done goes I think too far in keeping nominal compatibility with C and Java syntax when it's not actually compatible at all.

Yeah its common to see same line curly bracket for control statements, but it depends on what kind of coding style they are sticking to as there are so many of them out there. Some coding style guidelines impose things that make the code more readable and less error prone, some make it ugly by forcing weird naming conventions and unusual ways of formatting.

And yes things like the break; in the switch statement annoys me more than having to put semicolons everywhere. But overall C is reasonably good in terms of syntax. Pythons use of indentation is just a different way of doing it in order to avoid mistakes in what code belongs to what statement, also throws errors if the indentation does not make sense, works just fine once you know not to mix tabs and spaces, but it has plenty of other annoying syntax quirks.

Where syntax really bothers me is HDL languages like Verilog or VHDL.  They both use "begin" and "end" keywords instead of curly braces, require ; but will get very confused if there is one missing, and get even more confused if there is one where it should not be. VDHL tries to be very universal and as a result really wordy where you constantly have to explain to it what kind of number something is and even tell it what it should do with a + sign. I prefer Verilog because its less wordy but then it still has the begin end if then else end... while making you write down numbers in the strangest syntax ever, like 16'hBAAD or 8'b01101001 and using <= as an assignment operator that gets used more than the usual = assignment operator, while the operator for less than or equal in a if statement is <=, yet equality comparison is still == while introducing even more variations on the equality operator such as the === case equality operator.

But with languages that run on CPUs i have plenty of choice to go to a different language if i don't like it. Don't like Python? Use Java, still no? Maybe C? Or C++? or C#? Maybe Go? Can still use Pascal or Delphi too... etc list goes on and on. But as far as HDL languages go you get VHDL or Verilog, that's it.

[legacy]

Programming on a VT525 vt-terminal with VIM is different from programming with Geany on an NSC 400 X-terminal 

[legacy]

Code: [Select]

i = 10;
while(i); {
   printf("%d",i);
    i--;
}

SafeC checkers have the rule ")" must be followed by a block {}.
Hence the above line ");" is detected as mistake.

[brucehoult]

But with languages that run on CPUs i have plenty of choice to go to a different language if i don't like it. Don't like Python? Use Java, still no? Maybe C? Or C++? or C#? Maybe Go? Can still use Pascal or Delphi too... etc list goes on and on. But as far as HDL languages go you get VHDL or Verilog, that's it.

We use Chisel for pretty much everything. It is essentially a library with some classes and stuff in the Scala language, and eventually it outputs Verilog. Actually, it outputs FIRRTL which is basically an explicit low level netlist, and then FIRRTL goes through a bunch of optimization passes (much as you get in the middle part of gcc or llvm, but for netlists), and then the FIRRTL is eventually converted to Verilog (or potentially other things).

Looks like this:

https://github.com/chipsalliance/rocket-chip/blob/master/src/main/scala/rocket/ALU.scala