Considering learning programming

  • Thread starter Thread starter Abashi76
  • Start date Start date
Status
Not open for further replies.
There's a reason why [C] remains the only choice for real-time (deterministic) programming tasks, or embedded systems programming.
Click to expand...
Not true. Lots of scientific simulation and maths code is still written in Fortran. And safety-critical embedded systems are often written in Ada - I have a friend who was writing new Ada code for satellite systems as recently as three years ago.

However C does not force you to rely on higher level "safety" features present in most other compiled language which means it does allow you to write much faster code than in most other languages.
Click to expand...
Yeah, maybe, but it is also almost impossible for 99% of human beings to write large applications in C that are totally secure, unless you've got some kind of cybernetic implants in your brain. For instance - quick q, what's wrong with this snippet?

static int podhd_try_init(struct usb_interface *interface,
        struct usb_line6_podhd *podhd)
{
  int err;
  struct usb_line6 *line6 = &podhd->line6;

  if ((interface == NULL) || (podhd == NULL))
    return -ENODEV;
  ....
}
Click to expand...
That second null check won't do what you think it will, at least at first glance.

Of course, fiendishness like this is exactly why I think C is rewarding to learn. But actually using it is a different story!
 
Last edited:
Not true. Lots of scientific simulation and maths code is still written in Fortran. And safety-critical embedded systems are often written in Ada - I have a friend who was writing new Ada code for satellite systems as recently as three years ago.

Yeah, maybe, but it is also almost impossible for 99% of human beings to write large applications in C that are totally secure, unless you've got some kind of cybernetic implants in your brain. For instance - quick q, what's wrong with this snippet?

That second null check won't do what you think it will, at least at first glance.

Of course, fiendishness like this is exactly why I think C is rewarding to learn. But actually using it is a different story!
Click to expand...
This is a very common C gotcha (attempting to dereference podhd via &(podhd->line6) is undefined behavior if podhd is NULL. The check for NULL belongs before the attempt at dereferencing podhd and really any C programmer will know that. There's nothing wrong with the "second check" except that it's misplaced, and most good compiler's (gcc, for example) will optimize it away as the attempt to dereference podhd in the previous line will let the compiler know (mistakenly) that podhd cannot be NULL.

Simple solution, check for NULL before you dereference pointers. These sorts of things are more of a hassle when you're learning than later on when you've developed good habits w.r.t NULL handling (responsible for about 90% of C's "gotchas"). Being able to propogate constraints like this and letting the compiler (or instructing it with __builtin_unreachable) optimize away unnecessary works/checks is another factor that contributes to the performance advantage well written C code enjoys over most other compiled languages.

While I may have exaggerated about C/C++ being the only choice in those domains, it definitely has by far the largest marketshare. Ada isn't used outside U.S defense/aviation as far as a I know (and as much of a chore as the language is to work with, the extremely rigid typing and so many extra security checks -- totally makes sense for "mission critical" software so I'm glad it's preferred in those spaces. The amount of work to get a similar level of reliability out of C would definitely not be worth it, but that's not C's niche and that's fine -- just as the vast majority of problems in the domain above are not so 'critical" as to warrant the 5x development  time that results from trying to use the Ada ecosystem and deal with inane number of error checks it mandates. For that fast majority of speed critical applications, C is faster, much faster to develop in/easier to work with, portable, and "secure enough" provided your team is experienced enough to avoid the most common pitfalls.

Fortran is still around in some legacy code (and numpy/scipy) but mostly seems to be a legacy code language still adored by academics (and hence scipy/numpy, and other scientific computing libs are often written in it). I don't have any personal experience with the language, having only briefly encountered in in undergrad in the context of simulating physical systems in physics class before I realized I wasn't very good at physics. It's not as fast as C/C++ and those sorts of numerical modelling tasks are HPC, so I really don't understand why it's the preferred language for physicists in particular... but it is =p. Maybe someone with more physics experience (I never got past QM I) could offer more insight there.
 
Last edited:
This is a very common C gotcha (attempting to dereference podhd via &(podhd->line6) is undefined behavior if podhd is NULL. The check for NULL belongs before the attempt at dereferencing podhd and really any C programmer will know that. There's nothing wrong with the "second check" except that it's misplaced, and most good compiler's (gcc, for example) will optimize it away as the attempt to dereference podhd in the previous line will let the compiler know (mistakenly) that podhd cannot be NULL.

Simple solution, check for NULL before you dereference pointers. These sorts of things are more of a hassle when you're learning than later on when you've developed good habits w.r.t NULL handling (responsible for about 90% of C's "gotchas"). Being able to propogate constraints like this and letting the compiler (or instructing it with __builtin_unreachable) optimize away unnecessary works/checks is another factor that contributes to the performance advantage well written C code enjoys over most other compiled languages.
Click to expand...
This is not unique to C. This is poor program planning and a violation of the Fail Fast programming convention which can result in runtime errors. Most, but not all, IDEs in more modern languages will detect this and some won't even let you compile. That's with pretty strict options as it will just throw a nullpointerexception (or that language's equivalent) which might be caught outside the method.

The actual solution is always check all your arguments' states before performing any logic on them. Almost all programming errors are the result of NOT performing these checks and handling bad states correctly. The others result from creating massively long methods that try to do too much so no human can keep track of what it's actually doing and it ends up contradicting itself or another method. These errors are universal to all programming.
 
Whatever language you choose is capable of making editors and writing scripts to automate boring tasks.  It's really up to you, your favored operating system, the OS your users use, and - if you want to modify other people's editors - the language those authors used.  This limits you to C-like languages: C, C++, C#, Java, and Python to a degree.  Hence why you should learn one of them as your primary language, and later master a language like C (one of the hardest, but still a very small language and standard library compared to the others).  Once you do this you can easily teach yourself any other language in the family.  Progression for most college students is Python/VB.NET -> Java/C# -> C/C++.

Don't fret much for Linux users, most Lusers can figure out how to run anything given enough time.

Last piece of advice is learn the basics of git useage - add, commit, push, git ignore, and how to make a repo - and set up at least private repos for all your projects.  This matters because:
1. Hard drives fail.
2. Sometimes you code yourself into a corner and can't figure out how you got something to work earlier.  Looking back on earlier revisions alleviates this problem.
3. It feels good looking back on how far you came.
4. I've heard employers like seeing them, but since I'm not employed in the field I can't say.
 
Last edited:
Do the editor programs for FF7 use "Java"?
Click to expand...
I have not encountered any that do, but there's no reason it couldn't be done.  Several of the programs I use at the office are Java-based, but they're not the kinds of things you're likely to see on an end-user's desktop.
 
I have not encountered any that do, but there's no reason it couldn't be done.  Several of the programs I use at the office are Java-based, but they're not the kinds of things you're likely to see on an end-user's desktop.
Click to expand...
Do you know what programming language they use? By that, I mean the programs that mod FF7 and the programming language of the game itself.
 
Another question is, how did the New Threat & Hardcore mods modify the battles on the world map? Also, the New Threat mod was originally going to add a forest to the world map. This suggests that changing the world map is possible. In that case, it should be possible to bring back certain places such as the Temple of the Ancients and Mideel starting the Disc 3 portion of the game. It should be possible to add new places too, such as the Lifestream sprite (from destroyed Mideel) to new caves and new forests.

I would think it would also be possible to add new maps, since there are plenty of extra black screens (I'm thinking Mako Reactor program).
 
Last edited:
Do you know what programming language they use?
Click to expand...
Probably C++ or C#, maybe .NET.  Just ask the authors ;)

As for the rest, again, ask the authors... Sega Chief is always talking about his work and adjustments for NT, and DLPB about Reunion.
 
Do the editor programs for FF7 use "Java"?
Click to expand...
IDK that any use Java I know these are used: C , C++ , C# , VB.Net, Delphi , Python by various ff7 tools.
 
Status
Not open for further replies.
Back
Top