Software Development

I need a break so I thought I'd post a thought about the semicolon.Throughout much of its history the languages of computer science have required semicolons at the end of statements. This was a great help syntactically, making it easy for the compiler/interpreter to recognize the end of statements.Not all languages required semicolons, but most. Assembly languages didn't use the semicolon because it was one line per instruction, no statement separator needed. Fortran was also only one statement per line (per IBM card in the earlier days), so no semicolon. But almost all the higher level languages that came after required semicolons between statements, COBOL being a notable exception. Languages I've used that required semicolons were Bliss Bliss32, C, C++, Perl and PHP.Language requiring no semicolons that are increasing in popularity are Python and Swift. Semicolons are only necessary if you're including multiple statements on the same line.And then there's Javascript. In Javascript semicolons are optional. Mostly. These statements need no semicolon: But this will not work because the last line is illegal syntax: The reason that it's illegal syntax is that the "25" is followed immediately by an open paren on the next line, which causes the interpreter to interpret the 25 as a function and the open paren as the beginning of its argument list. So we have to add a semicolon after the "25": I've been writing Javascript since the early 2000's and have always used semicolons after every statement. Normally I would include a semicolon after every line, like this: That was my habit. Not using semicolons seemed blasphemous, plus I was writing copious amounts of code in Perl and later in PHP, both of which require semicolons. Switching back and forth between using and not using semicolons would have caused numerous errors of omission.But recently I've been working on a website that is Javascript only, and I've been leaving out the semicolons. The cases where a semicolon is required, like the example above, almost never arise is real code, especially in the NodeJS/ReactJS context I'm currently working in. Problems do arise when I make changes to the PHP code of this website where semicolons are required and which now I keep forgetting.But I plan to write increasing amounts in code in Javascript, so I'll continue leaving out the semicolons.--Percy

In my automation programming languages (PLCs -> mostly ladder logic) there are many, many different companies with their own language and way of doing things. To me, it all comes down to "many different ways to skin a cat"... to use a phrase with a horrible image to actually think about.I've come to the following (personal opinion) conclusions:

• There is no global sense of "right" or "wrong" way to code. Each and every language will have it's own correct and incorrect syntax and configuration, and one must learn those things to program correctly in that language. But it is wrong to think that some language's "way of doing things" is the "right way." It's really just "that language's way."
  ​
• There are those who have programmed in one language for most of their lives and they will live and die by "their language" and think that this is the only way to do things and everything else is wrong. I find this analogous to religious people thinking their own religion is correct - just because it's the one they know.
  ​
• Almost every language will have nice things you can't find in other languages, and bad things you can only find within that one language. Those who like that language will always have personal ways of dealing with the bad parts that they describe as "easy if you just do this..."
  ​
• For the most part, you do get what you pay for. AAA programming languages come with all the bells and whistles and attempt to improve upon programmer-friendliness. Rarely-used programming languages should generally stick to the niche-area they were created for and may lack the necessary abilities to perform all functions any programmer could require for "any" situation.
  ​
• Those who say a language is "garbage" or useless - generally simply do not understand how to use that language for the purpose it was created for. Perhaps it was a simple, cost-friendly language created for simple, cost-friendly projects and they're being tasked with using it for larger projects that are beyond the intended scope of the language. This is unfortunate... but is more an issue with project management than it is an issue with the programming language.
  ​
• In my field there are 3 main ways to program. Ladder Logic (used about 80% of the time); Function Block Diagram (used about 15% of the time); or Statement Logic (used about 5% of the time.) Although there are certain extreme-case situations where only one of the languages can be used... these situations are extremely rare and usually it's up to the programmer themselves which method they would prefer to work within. Again, there are those who swear that one is "better" or "worse" than the others... but, really, they're just different ways of doing the same thing. I generally use Ladder Logic because it's the most popular and most user-friendly to maintenance who will likely get stuck with attempting to figure something out years after installation.

So... my thoughts on the semi colon would be:

• I've always found syntax to be just that... syntax - the way you have to program when using whatever language/compiler you're using
• I don't find semi colons to be "better" or "worse" one way or the other
• In my limited "real programming" experience, I do like using python (after I realized how important the white space actually is... that was an interesting afternoon) I find it efficient in the sense of getting my ideas of "what I want the program to do" into the program as easy as possible. I understand that python isn't known for being "efficient" in the sense of energy usage... but that's not really any of my concern for the most part. So I don't care.

And, as all programming discussion should always conclude: "That's not the way I'd program it."

I agree with much of what you say. I never cared much about particular programming languages - they were all just a means to an end.Something's sadly lacking in my education, because I don't know what ladder logic, AAA programming, Function Block Diagram or Statement Logic are. I always used (and still use) the code outline approach where you distribute bare bones functions and data object definitions among code modules then fill in the details.Swift was the one language where I couldn't use that approach because the XCode IDE uses a graphical interface where you interconnect graphical boxes of a variety of types with lines representing control and dataflow. XCode then creates templates for each graphical box and you fill in the functional code. You can write bare Swift, but given that the target is an iPhone or iPad it doesn't come out well. For example, if you implement in bare Swift you have to manually handle device rotations, while the graphical approach takes care of it for you automatically.I might have miscommunicated my feelings about semicolons. I could care less about them. They're just a habit. But I am worried about a higher error rate if I have to move back and forth between semicolons-required and semicolons-optional environments.The smart thing to do would be to maintain my habit of using semicolons, because that way I would avoid simple errors, but I've opted to go semicolon-free in Javascript and am hoping I don't have to move back to PHP too often. But I fixed a PHP bug on 3/20, and I fixed another last night, and I kept forgetting the semicolons.--Percy

No, I don't think so.
"Automation programming" is a very small subset of "programming."I program the computers ("PLCs") that run assembly lines like auto-parts-making-things, pharmaceutical-making-things, food & beverage processes (like dairy), and even amusement park rides.But it's not "real" or "normal" programming.
Basically - they're computers that get a single program loaded into them, and they run that 1 program. Forever. They're very good at it - never getting windows or operating system updates because they don't have an operating system and things like that. These computers are meant to be up and running 24/7... forever.I would say automation programming is to normal programming the way... building a bomb shelter is like building a house.
The bomb shelter is amazing at keeping you safe and takes a specific skill set to build correctly... but most people don't need it, they need a house. Houses are way more flexible and customizable and popular. Ladder Logic
-Easiest to google that term and look at the images.
-is limited to automation programming, I wouldn't expect anyone outside automation programming to know what this means
-programming is done using a GUI that is reflective of looking at an electrical wiring schematic
-each "rung" is programmed by selecting the input structure (and/or...) and then firing an output like in a wiring schematic
-all the "rungs" together kinda look like a "ladder" -> Ladder Logic
-automation programming became a thing with electricians started making more and more complicated panels using relays, timers and counters
-they got real programmers to make the first "PLC" that could do this using a program... and an industry was born AAA Programming
-I just made this up
-was attempting to identify the difference between a big name brand programming language vs. small name brand programming
-in my world this would be companies like Rockwell or Siemens PLCs vs. say, DirectLogix or Carel PLCs
-in normal programming, I'm not sure if this analogy carries much weight (I don't know enough about the industry of normal programming to know either way)
-idea is similar to video games though... a "Triple A" game ("AAA") would be one made by a big name like Activision/Blizzard or Gearbox with years of experience and billions of $$$ as compared to an Indie game or other start-up company Function Block Diagram
-Easiest to google that term and look at the images
-looks kind of like a flow chart
-again, like Ladder Logic but just using a different GUI to do the same thing Statement Logic
-this is the one that's closest to normal programming
-but it's very basic, like loading values into registers, doing compares on those registers, and then setting outputs using lines of text as opposed to a GUI Sounds like real/normal programming.
I don't do a lot of that.
Although, more and more automation programs are getting away from PLCs and moving towards Industrial PCs (just expensive PCs, really) that run code like that (usually VBScript or C++, but I'm sure that varies as well.)PLCs were popular for automation because in the days of Win 95 (and even earlier...) you did not want your computer running 24/7. Because it couldn't do that.
Today, Windows 10 actually can run 24/7 quite well (if you protect it from requiring reboots due to automatic updates...). Especially on good hardware (or even a VM) which is why the shift from PLCs to regular programming is gaining popularity.Think of a bottling line with glass bottles zipping along on a conveyor. It never stops. Ever. If it stops - the company is losing money. 100% uptime isn't just a desired utopian goal... it's a requirement. It's still impossible, even with PLCs... but the efforts to get closer and closer and closer are much higher in automation programming. Shutting down even once a month for a planned reboot would be met with gnashing of teeth and screaming.I can see the line of demarcation between automation programming and regular programming slowly disappearing. But it's going to be many, many years longer before that happens. Quite easily decades or more.