Programming language: what to study after the basics?

[Noob of the Maths]

TL;DR Summary

what to study after the basics?

Hey everyone :).

after studying c++ and a bit of phyton in the university (not in a career related to programming), I was wondering what to study after the basics.

youtube tutorials are at about the same level as I was at (inheritance, class, pointer), not more advance...

what is the intermediate level? what is the upper-intermediate level? the advanced level?

I must study OPP? Databases and dataset?

what is the next step? ;)

Thanks for read-

 

[phinds]

Depending on what you end up doing, databases can be critical to getting it done. Their uses are very widespread.

 

[berkeman]

Summary:: what to study after the basics?

after studying c++ and a bit of phyton in the university (not in a career related to programming), I was wondering what to study after the basics.

It depends a lot on what you would like to use programming for going forward. Will you be writing programs to help your scientific computations? Or to help automate some of your computer tasks (like scripting comman activities that you do often)?

Learning and practicing different data structures and their manipulations can be a good general skill, IMO. Knowing when to use linked lists and arrays and other structures can be a useful skill to have.

If you are going to be doing some simulations/computations, then perhaps study basic numerical methods and work on some practical problems to see if your results agree with experiments.

And I'd recommend learning how to use Source Control to manage your software projets. If you end up writing software as part of your work, you will almost certainly be using Source Control to help organize the revisions of your programs, and to integrate your work with the software written by others. And even if you are just writing software on your own for fun, it's good to get in the habit of using Source Control to keep track of your projects.

 

[Noob of the Maths]

Depending on what you end up doing, databases can be critical to getting it done. Their uses are very widespread.

my intended use is related to electronics-automation, like PLC, microcontrollators. And a bit of software like MATLAB and simulations

 

[FactChecker]

my intended use is related to electronics-automation, like PLC, microcontrollators. And a bit of software like MATLAB and simulations

Then MATLAB, Simulink, and the associated Mathworks tools would be very good to learn. No other languages that I am aware of would be very good preparation for them.

 

[jedishrfu]

Or the free alternatives like Julia.

Another thought is to get into Arduino programming. It’s very lowlevel and more hardware specific.

 

[Tom.G]

I've done several PLC projects, you will need some background knowledge of the devices you will be controlling.

Things that aren't quite obvious until you have worked with the hardware can bite! For instance a series of conveyer belts; always start the exit conveyer and verify it is running before starting the one that feeds it. Then pay attention to which one gets shut off first. A pump? Open the valves first.

Another is pneumatically operated anything, they are not instantaneous in operation, nor are large motors.

The 2 biggest suppliers are Siemens and Allen-Bradley, I've used both A-B and Texas Instrument, along with some small ones that I don't remember the names of.

The A-B and TI have similar capabilities with the A-B preferred for medium projects (100+ to a couple thousand I/O points), the TI for perhaps 50 to 250 I/O points. The A-B has more built-in high level math and control functions. (You don't have to implement a PID control loop from scratch in the A-B.)

Often the customer will specify which brand to use because they have other equipment using that brand. This is important to the customer from a support/maintenance standpoint.

Small stand-alone machines would typically use low-end PLCs with perhaps 20 or fewer I/O points. IIRC, some are available for <$100.

In general, PLC programming requires a different mindset than what most people think computer programming is. It's sort of like writing a floating point math package for a processor having only 16 bit integer add/subtract, you are really getting 'down-and-dirty on occassion. But it is a lot of fun!

The Programming software varies widely in usability and overall approach. If you are working for BIG COMPANY the PLC brand may be pre-determined, then hope you can get the programming software you are comfortable with.

Here is a link for those that want to get started with small PLCs:
https://www.google.com/search?hl=en&q=small+plc+projects

Well, rather rambling but I hope it helps someone.

Cheers,
Tom

 

[Noob of the Maths]

I've done several PLC projects, you will need some background knowledge of the devices you will be controlling.

Things that aren't quite obvious until you have worked with the hardware can bite! For instance a series of conveyer belts; always start the exit conveyer and verify it is running before starting the one that feeds it. Then pay attention to which one gets shut off first. A pump? Open the valves first.

Another is pneumatically operated anything, they are not instantaneous in operation, nor are large motors.

The 2 biggest suppliers are Siemens and Allen-Bradley, I've used both A-B and Texas Instrument, along with some small ones that I don't remember the names of.

The A-B and TI have similar capabilities with the A-B preferred for medium projects (100+ to a couple thousand I/O points), the TI for perhaps 50 to 250 I/O points. The A-B has more built-in high level math and control functions. (You don't have to implement a PID control loop from scratch in the A-B.)

Often the customer will specify which brand to use because they have other equipment using that brand. This is important to the customer from a support/maintenance standpoint.

Small stand-alone machines would typically use low-end PLCs with perhaps 20 or fewer I/O points. IIRC, some are available for <$100.

In general, PLC programming requires a different mindset than what most people think computer programming is. It's sort of like writing a floating point math package for a processor having only 16 bit integer add/subtract, you are really getting 'down-and-dirty on occassion. But it is a lot of fun!

The Programming software varies widely in usability and overall approach. If you are working for BIG COMPANY the PLC brand may be pre-determined, then hope you can get the programming software you are comfortable with.

Here is a link for those that want to get started with small PLCs:
https://www.google.com/search?hl=en&q=small+plc+projects

Well, rather rambling but I hope it helps someone.

Cheers,
Tom

HI!
I would mostly use it for mechanical projects.

In the curriculum only the basics will be studied:
"Thyristor and TRIAC for control equipment and motor controlling".

Yes. A very applied and basic study.

I want to go further and study this type of process control in depth:

Counter, decoder, display, schmitt trigger.

Unfortunately it is difficult to find a good course on youtube, as most of them don't go that far.

 

[Svein]

The most important thing when writing software is - not writing anything before thinking about it.

I am deadly serious. The most important thing about writing software is to learn to write a software design document. The contents of this document should specify what modules the program should contain, what the allowable input parameters are, what should happen when presented with illegal parameters, and what the expected output should be.

Doing such documents will set you on the road to being a software architect instead of a mere programmer.

 

[pbuk]

The most important thing about writing software is to learn to write a software design document.

There are development paradigms where such a document is not the most important thing.

 

[jedishrfu]

The software design doc is an older style of programming discipline and is seldom used in current development teams.

I recall using them last at my old company where we were required to write several related documents for a given project:
-product marketing
- product requirements
- functional specification
- high level software design
- low level software design
- testing document
- user guide (written from the product docs functional specification never the design or testing docs)

Our project was to port existing code in one dialect of FORTRAN to another system and dialect of FORTRAN. The product was a fancy file transfer program between IBM PC and mainframe. By fancy I mean full blown accurate percent bars and GUI display for each file sent with error correction ... Things now commonly done under the covers by ftp.

Because I had the code it was easy to scan for error messages and related info to write the functional specification even though we hadn't gotten to the design issues. The original code was written by another company team "under the radar" not using the software documents approach (ala hacking).

I recall my boss wrote the product marketing and requirements documents and handled the internal politics while I got to write the functional spec. My doc was reviewed by various stakeholders like the quality assurance team, document team, customer service team, and the marketing team.

Customer service folks were concerned with error messages from the product and how to handle them as well as how to actually use the product. We went thru a lot of revisions before we even got to the design docs.

One guy tried an 11th hour objection to torpedo the whole thing but got shutdown by my boss. He was the project lead from the original team that wrote the undocumented version we were porting and I guess he wanted his team to do the port. Anyway, I never knew his real reasons for stonewalling approval and raising objections.

Company rationale at the time was to mitigate attrition of programmers who stayed on average no more than three years before moving on to other jobs often for better pay outside of the company (circa 1970's).

I got praise for the document I wrote but realized this was a very poor way to design a project in a timely fashion but being a junior programmer was ignored in favor of the praise. I left part way through the conversion and later discovered the project fell apart because the new programmer ignored what I had done and just started hacking things together.

My strategy had been to write a script to convert do the conversion of dialects to insure consistency across the code base. The new guy decided instead to throw away my conversion script and just do manual conversions as needed. Que sera sera.

 

[Tom.G]

The new guy decided instead to throw away my conversion script and just do manual conversions as needed. Que sera sera.

Yup, been there, seen that!
Was the 'new guy' fresh out of school/first job?

At one place I worked, a new graduate was hired for a small software project (a couple months).

Each function was written as a standalone homework assignment would be. Integration time was when he quit. The boss said he had to rewrite the whole thing! At least he had a skeleton to flesh out.

And the 'new guy' had a skeleton in his closet.

 

[jedishrfu]

Nope, he was an older retired military guy and maybe thought I was being too clever in my coding. Also I don't think he understood where I was going with it.

 

[Svein]

I still think it is important to know what you are trying to do before you do it. I have seen several examples of programmers starting to code something because they "know what to do". This invariably leads to misunderstandings, "quick-and-dirty" fixes, and unmaintainable code. Being a "fault-finder" for 35 years, I have seen it and am heartily sick of it.

 

[FactChecker]

There are development paradigms where such a document is not the most important thing.

Yes, but there are serious dangers with that. I once spent man-months to get software to exactly match one design (not documented, only word-of-mouth). The final customer was not available to monitor our work. When the work was done, we were told that it was not matching the correct design. The lesson learned is that the ultimate, final customer must be closely involved as the work progresses. If that is not possible, due to them being unavailable, then there are real dangers of the work going wrong.

 

[pbuk]

This is probably not the place for a comparative debate on software development paradigms but you should be aware that one motivation behind the Agile Manifesto (which I find hard to believe is now 20 years old) was that many projects had suffered from an over-emphasis on a design document created early in the process.

For three key reasons this often led to sofware which met the design document but was not fit for purpose.

The lesson learned is that the ultimate, final customer must be closely involved as the work progresses.

I can certainly agree with that, however this is more easily achieved with an iterative process as is now the norm rather than the previously favoured linear processes that you and others seem to be advocating.

 

[phinds]

I can certainly agree with that, however this is more easily achieved with an iterative process as is now the norm rather than the previously favoured linear processes that you and others seem to be advocating.

+1 on that. Been there (both styles) done that, prefer the iterative approach (WITH heavy end-user participation of course) for all but the largest projects.

 

[Kat-hi]

Depending on what you end up doing, databases can be critical to getting it done. Their uses are very widespread.

I agree with your post on learning databases - they are really extensive, robust and extremely versatile in many respects and adapt to most operating systems. Too often those who can put together a sad SQL think they understand the entire concept of databases and drag their systems into some major slowdowns.. then claim databases are useless when it's just a serious lack of proficiency.

 

[Kat-hi]

This is probably not the place for a comparative debate on software development paradigms but you should be aware that one motivation behind the Agile Manifesto (which I find hard to believe is now 20 years old) was that many projects had suffered from an over-emphasis on a design document created early in the process.

For three key reasons this often led to sofware which met the design document but was not fit for purpose.I can certainly agree with that, however this is more easily achieved with an iterative process as is now the norm rather than the previously favoured linear processes that you and others seem to be advocating.

My experience with the introduction of this to groups has proven your comment to be pretty valid.

 

[Kat-hi]

I still think it is important to know what you are trying to do before you do it. I have seen several examples of programmers starting to code something because they "know what to do". This invariably leads to misunderstandings, "quick-and-dirty" fixes, and unmaintainable code. Being a "fault-finder" for 35 years, I have seen it and am heartily sick of it.

True. And too often a programmer is most interested in being a great coder and not as adept at digging out the requirements - hence the need for a real analyst who can interface with the users. I agree also with the "quick and dirty" fixes comment - ugh. Lots of bandaids and trash code and yet no one wants to address the time and money to do a decent fix. Of course, the design itself could be so bad that only "quick and dirty" works. Design considerations are so important.

 

[Kat-hi]

Yes, but there are serious dangers with that. I once spent man-months to get software to exactly match one design (not documented, only word-of-mouth). The final customer was not available to monitor our work. When the work was done, we were told that it was not matching the correct design. The lesson learned is that the ultimate, final customer must be closely involved as the work progresses. If that is not possible, due to them being unavailable, then there are real dangers of the work going wrong.

I agree, if someone designs closely with the user, there is always a lot of satisfaction - also if possible a piecemeal approach to showing preliminary coding results and approval of some pre-QA type testing - along with, of course, user participation in QA testing. Lack of documentation seems to be another huge problem there. Many huge corporations here require a review of design with a group included systems people, users, database people, etc. before final approval. However even the local staff needs to step up and be a part of everyone's project at least to acquire some knowledge. Before I retired, not one person on my staff was willing to participate after a few classes in learning some new technology I was presenting... until I turned in my retirement resignation.. and in my mind that was too late.. because there was no time to actually every use this with some guidance.

 

[elcaro]

Summary:: what to study after the basics?

Hey everyone :).

after studying c++ and a bit of phyton in the university (not in a career related to programming), I was wondering what to study after the basics.

youtube tutorials are at about the same level as I was at (inheritance, class, pointer), not more advance...

what is the intermediate level? what is the upper-intermediate level? the advanced level?

I must study OPP? Databases and dataset?

what is the next step? ;)

Thanks for read-

Depends what you want to do, what do you want to program? Graphical user interfaces, data-driven programs, low-level programs, networking?

 

[hmmm27]

my intended use is related to electronics-automation, like PLC, microcontrollators. And a bit of software like MATLAB and simulations

Google "What languages are used for PLC's ?"

 

[elcaro]

Google "What languages are used for PLC's ?"

for example C and Forth.

 

[FactChecker]

Google "What languages are used for PLC's ?"

MathWorks has very good tools for PLC simulation and design. I don't know about their PLC tools, but they often have code generators that go from the design to the usable control code. I know some control law organizations that will not hire anyone who is not familiar with MATLAB.
https://www.mathworks.com/discovery/plc-simulation.html

 

[Twigg]

my intended use is related to electronics-automation, like PLC, microcontrollators. And a bit of software like MATLAB and simulations

I was in a similar position about 5-7 years ago. Here are the things I wish I learned earlier that bit me in the backside:

1) How to keep notes/documentation effectively (this could be a whole class on its own)
2) Source control!
3) Basic TCP/IP networking
4) Databases

 

[Pattern-chaser]

Summary:: what to study after the basics?

Hey everyone :).

after studying c++ and a bit of phyton in the university (not in a career related to programming), I was wondering what to study after the basics.

youtube tutorials are at about the same level as I was at (inheritance, class, pointer), not more advance...

what is the intermediate level? what is the upper-intermediate level? the advanced level?

I must study OPP? Databases and dataset?

what is the next step? ;)

Conventional wisdom - which is Just Plain Wrong - often refers to progress in software engineering in terms of which language you should learn [next]. You will pick up languages as you need them. But, to progress, you need to learn about design. This isn't easy, and this is only partly because design can't be learned from books or the interweb.

Ideally, you could do with a mentor, a good designer who can teach you what you need to know. Sadly, I was never able to find a mentor in my professional life. That's probably because I was in firmware, and firmware designers tend to work in teams of one.

As a lesser alternative, seek out the writings of such luminaries as 'Uncle' Bob Martin, James O Coplien, Kevlin Henney or Michael Feathers, to name but a few.

HTH

 

[Pattern-chaser]

I was in a similar position about 5-7 years ago. Here are the things I wish I learned earlier that bit me in the backside:

1) How to keep notes/documentation effectively (this could be a whole class on its own)
2) Source control!
3) Basic TCP/IP networking
4) Databases

Items 1 and 2 are universal and vital. Items 3 and 4 depend on what you program, and how.

But don't misunderstand me: I'm not criticising. Twigg's post is good advice.

 

[Pattern-chaser]

my intended use is related to electronics-automation, like PLC, microcontrollers.

In that case you'll be programming in Assembly Langauge or C. Maybe C++ if you're lucky enough to program a uC target with enough resources to run programs written in it. Most firmware is written on uCs that have 64k of RAM or less, sometimes a lot less. This can be limiting...

But as I said before, don't get caught up in languages. No language will explain to you the reason(s) why you need to master unit-testing and Test-Driven-Design (also called Test-First-Design), but you do.