Author Topic: Considering learning programming (Read 15256 times)

Abashi76 · « **on:** 2018-12-26 02:51:05 »

I was looking up programming classes in my local college; just thought of it today.

I often complain that a combination of the New Threat and Hardcore mods would be perfect with some changes in the ways certain enemies are used. I can't even figure out to make a simple mod myself because i think i need programs that only work on 64-bit and i have a 32-bit. I would think basic programming should be able to help make my computer compatible with modding programs for all sorts of games originally from the 1990s.

I could make a lot of things if i only knew more about programming, especially the random problems that tend to only happen to me.

The classes are at least four hours long based on my research. There are a very limited amount of choices based on my search. They are mostly basic programming classes needed for all programming. I don't know where the specific stuff is taught.

Is there any chance there are still colleges that teach programming needed to mod old video games?

blippyp · « **Reply #1 on:** 2018-12-26 03:00:24 »

I've been basically programming my entire life, and have used dozens of different languages, I promise you that all you need to get started is to pick up a basic programming book for dummies in whatever language you desire to learn. For the most part, they are all the same, but there are some pretty serious exceptions to that rule. Once you've learned the basics of one language though you will notice just how similar all the languages really are. They all store memory in variables and use conditions and loops to code. How you design a program/game in one language is still relatively the same way in another language, just the syntax is different in how you type it out.

You'll be hard pressed to find a good course on how to design games though. That just comes with experience. There are some references and books out there to learn how, but for the most part you're kind of on your own. You either get how to do it or you don't. Once you've been programming long enough you will realize there isn't much difference between making a game and an application or a command line tool anyway tbh.

It sounds like you're just starting out - So if I were you, I'd just go get yourself a 4 Dummies book or start reading up on one of those tutorial sites on whatever language you want to learn. It takes time, but can be very rewarding.

Good luck, hope that helps you out.

KnifeTheSky77 · « **Reply #2 on:** 2018-12-27 04:52:22 »

Learn Node for free on the internet, then electron + react for a UI if necessary -- it's all just JS. I wouldn't bother with other stuff tbh

Shard · « **Reply #3 on:** 2018-12-27 16:38:33 »

That's terrible advice given the question. The OP wants to learn programming so he can mod games. React and Node are primarily web-only and won't help him at all.
If you know nothing about programming, take an introductory class for c or java. Anything you learn in those will transfer to nearly everything else.
For modding, you'll have to have a much deeper understanding of file formats and/or assembly, which is not something you can just jump into.
For a good start, pick up a game that has an editor with a scripting language like rpg maker (you can find old versions of rpg maker for free) and just play around with it. If you like it, then I would suggest taking the higher level CS classes.

KnifeTheSky77 · « **Reply #4 on:** 2018-12-27 21:52:33 »

No.

Node can directly execute c++ if necessary and can easily modify system files, while also being simple to learn.

Suggesting c++ to someone with no prior programming experience is bad advice.

sithlord48 · « **Reply #5 on:** 2018-12-27 22:01:49 »

Suggesting Electron for anything is bad advice. Want to learn programming Learn some basic computer science and language along with it. I would recommend C++ since its low enough for to learn the concepts and high enough where its not to hard to do anything.

If you want to work on games C++ and C# are what you will find many are made in. (C# more recently since many newer engines use it for scripts.)

KnifeTheSky77 · « **Reply #6 on:** 2018-12-27 22:04:00 »

lol ok.

Covarr · « **Reply #7 on:** 2018-12-27 22:34:13 »

The first thing you need to ask is what are you modding. There is a big difference between changing a game's executable, changing its data files, or working from originals. Here's somewhat of a basic overview.

As far as modern engines go...
Unreal Engine 4 uses its Blueprints visual scripting system in-engine, which can be expanded at a lower level using C++.
Unity uses C# for its scripting. It also allows plugins written in C, C++, Objective C, etc., which can be called using C#.
CryEngine uses Lua and C# for scripting, and C++ for lower-level stuff.

Older games, especially from the '90s, are much more likely to have been built in a proprietary engine, which can vary heavily from game to game, particularly by genre, and typically not as publicly available as the popular engines today. Realistically, the best choice for modding will depend on the particular game, and whether it can be decompiled, but the best things you can learn are C, C++, and x86 assembly (the latter of which basically demands a decent understanding of computer science).

If you want an easy language that can interact with files or memory but don't necessarily need to directly change existing software, you might consider Python. It's powerful, extensible, reasonably fast, and all-around a good first choice for beginner programmers.

And Node and Electron and React? I can't strongly enough recommend avoiding them, unless you really want to make a career out of bloated webapps (or worse, bloated webapps as desktop apps). They don't integrate nicely into OS native look and feel UIs, they have really poor performance, and their growing popularity is a pox on the tech industry.

quantumpencil · « **Reply #8 on:** 2018-12-28 14:57:34 »

Don't try to take the easy way (because there isn't one). Realize that being a programming/CS are huge fields with a lot to learn, and prepare yourself for a multi-year journey.

I would suggest learning at least three languages, in the following order:

one classical systems language(C)
one functional language (Elixir/Erlang would be my bias cause <3 OTP and BEAM)
one scripting language (Python, probably).
If you want to learn specifically for modding, learn x86 after C

I would suggest C first, as it's the classical programming language and a lot of other popular programming languages are modeled on it. You can get close enough to the ASM to write code in C calling fist size structs in compiled executables, etc so it's by far the most useful languages for modding compiled code. C++ is also woefully complex for a beginner, I've worked in it for like 10 years and probably know 25% of the language spec cause it keeps getting more bloated.

Also take at least one systems programming course and one algorithms/data structures course, or familiarize yourself with the relevant material. Graph-traversals, dynamic programming, greedy/random algorithms, hashing and complexity analysis are tools you want in your toolbox for general purpose engineering. Systems programming will help you understand how code actually executes on your system, the various levels of virtualization involved, and is basically what you need to be able to mod a compiled executable.

I recommend this mostly to expose yourself to different paradigms and ways of thinking about code. Don't waste time on specific frameworks at first, this or that web-hotness is always changing and once you have a strong conceptual understanding of the foundations of programming picking up a new "framework" takes a few weeks of reading a codebase written in it + documentation.

To this end, remember to READ code, especially at first. Then try to use patterns you encounter in your own projects. You won't become better if you just write code, because -- well, you don't know how to write it. Gotta imitate before you innovate =p.

For getting started, I suggest you consider enrolling in Harvard's CS50 course: https://www.edx.org/course/cs50s-introduction-computer-science-harvardx-cs50x. It's free, and the first course in the series is taught in C and will do a good job familiarizing you with what I consider to be "the basics."

Abashi76 · « **Reply #9 on:** 2019-01-25 17:28:27 »

Quote from: Covarr on 2018-12-27 22:34:13

The first thing you need to ask is what are you modding. There is a big difference between changing a game's executable, changing its data files, or working from originals. Here's somewhat of a basic overview.

As far as modern engines go...
Unreal Engine 4 uses its Blueprints visual scripting system in-engine, which can be expanded at a lower level using C++.
Unity uses C# for its scripting. It also allows plugins written in C, C++, Objective C, etc., which can be called using C#.
CryEngine uses Lua and C# for scripting, and C++ for lower-level stuff.

Older games, especially from the '90s, are much more likely to have been built in a proprietary engine, which can vary heavily from game to game, particularly by genre, and typically not as publicly available as the popular engines today. Realistically, the best choice for modding will depend on the particular game, and whether it can be decompiled, but the best things you can learn are C, C++, and x86 assembly (the latter of which basically demands a decent understanding of computer science).

If you want an easy language that can interact with files or memory but don't necessarily need to directly change existing software, you might consider Python. It's powerful, extensible, reasonably fast, and all-around a good first choice for beginner programmers.

And Node and Electron and React? I can't strongly enough recommend avoiding them, unless you really want to make a career out of bloated webapps (or worse, bloated webapps as desktop apps). They don't integrate nicely into OS native look and feel UIs, they have really poor performance, and their growing popularity is a pox on the tech industry.

This game uses a really old language, and i've heard it was pretty bad.

For now, I was hoping there would be basic classes to teach universal programming language. I could use this to find out why certain programs don't work on my computer, and learn why this game messes up already just for changing the difficulty balance.

Later, I was hoping to make a perfect mod in a little less than 10 years. Unfortunately, games like these are almost dead, but I might find a few who will play again.

TY everybody!!!

Covarr · « **Reply #10 on:** 2019-01-25 19:44:45 »

Quote from: Abashi76 on 2019-01-25 17:28:27

For now, I was hoping there would be basic classes to teach universal programming language.

There is no such thing as "universal programming language". Most older games like this would've been programmed in C or C++, but once assembled, there is no access to that C++ code directly to change it, so everything would need to be done in x86 assembly, which requires quite low level understanding of computers and the game being modded.

This is not to discourage you, but this hole goes much deeper than you seem to realize. Nothing's impossible, but be prepared for a years-long journey to get to the point that you can do anything productive in older games.

nfitc1 · « **Reply #11 on:** 2019-01-25 20:52:32 »

How old are we talking? DOS-era? Some of those use some data compression voodoo in the code that can't be modified without unpacking it.

Start with something REALLY simple, like Perl. It doesn't do much, but almost every OS (Operating System. ie; Windows, Mac OS, Linux, etc) has the ability to run Perl scripts. If nothing else this will get you used to seeing syntax and how code executes when little things change. Perl is executed in real-time as a script.

From there, look to Scratch. Not the most powerful language, but it's hard to mess up. This can be compiled into a stand-alone executable.

The next logical transition would be to java (since Scratch translates 1:1 with java IIRC). You'll run into a lot of road-blocks with java when trying to access system resources. This can also be compiled and nearly every OS can run it.

So the next level would be C#. It's a less explicit form of C++ that is similar enough to java to look familiar, yet have far more functionality. This is where OSs differ. Any program can be written in C#, but it will have to be compiled with a particular OS in mind.

If you aren't scared away from that, you can dive into assembly. Start with whatever your favorite OS runs. Then you can really learn how processors work.

At least, this was my experience with a more modern linguistic twist (I learned QBASIC instead of Perl, but they can do similar things). I spent years (and still do) on each of the languages I learned and I'm still learning neat tricks they each can do.

Bosola · « **Reply #12 on:** 2019-01-26 22:24:33 »

Dropping my five cents into the ring: I don't think C++ is a great first language for programmers. Not because it is too low level, but because it is too hairy and inconsistent. It is very much a language that has been grown rather than designed; using C++ in the workplace tends to mean carving out a sane subset your team are all happy to work in (e.g. C++ 11).

C, on the other hand, is a great language. It's small, it's fast to compile, and it teaches all the basic concepts. You can "get" C within a couple of weeks. You won't get much work writing C, but if you're learning to program to reverse engineer things I can hardly think of a better way to encounter all those low level ideas whilst still being productive in a relatively high level language.

If employment is a motive...

Then the most obvious choice is Java, because pretty much everyone uses Java for systems programming. Then again you can do a lot with JavaScript these days - you can even call modules written in C if you're using Node (or a runtime that embeds Node, like Electron). This can be a nice way of threading together key modules that are run as native code with a very terse scripting language (JS). I know SithLord despises Electron, and it has its flaws, but there aren't many competitors for sheer cross-platform productivity. Node and NAPI also provide a surprisingly good C/C++ buildchain.

For my day job I tend to write mostly Java, Kotlin, TypeScript and JS. WebGL here and there, because I'm quite interested in things like WebVR. I do sometimes write a bit of C++ but it's not commonplace. I might get an opportunity to use Clojure soon, which is quite exciting.

Covarr · « **Reply #13 on:** 2019-01-27 18:54:15 »

Quote from: DLPB on 2019-01-27 00:17:29

To this day, people keep repeating the lie that it's faster than other languages. It just isn't. They all end up as assembly and all modern languages have optimization.

Well... (Warning: the following is generally true, but rather oversimplified.)

Many popular languages aren't compiled and don't end up as assembly. In particular, C# Java and Python are both interpreted in real time, not compiled, and in virtually all cases will run slower than compiled C++ code. While C++ may not have an advantage over other compiled languages, it absolutely will perform better than, say, Java in almost all cases.

Spoiler: show

nfitc1 · « **Reply #14 on:** 2019-01-27 20:05:25 »

Assembly is as close to machine code as you can get. Just because it uses aliases for codes that may or may not be multibyte instead of straight binary doesn't mean the two aren't practically interchangeable. They aren't the same thing, no, but the difference is only technical.

Bosola · « **Reply #15 on:** 2019-01-28 11:59:18 »

Quote from: Covarr on 2019-01-27 18:54:15

Yes, I'm aware of intermediate languages. As far as I'm concerned, though compiling to an IL or bytecode that then still needs to be interpreted still qualifies as an interpreted language, for the sake of a performance comparison to languages that compile straight to machine code.[/spoiler]

Yes, but remember that most runtimes / language virtual machines are able to do recycle generated machine code and perform 'hotspot' AOT optimisation on heavily used functions.

Even the JavaScript V8 runtime does it these days: Chrome will spot that functions keep getting invoked with a particular call signature and begin not only caching inline machine code, but actively running background recompiles to speed them up. Once "warmed up" things like V8 and the JVM can achieve some very impressive results.

As for speed, C++ must be the worst of all the 'fast' languages. Its design is so gangly, it inspired another language to fix its mistakes (Java). Here's hoping that Rust becomes the systems programming language du jour.

Quote

(And btw, DLPB, they don't end up as assembly. They end up as machine code.

They do, but don't forget, machine code isn't even the lowest level instruction set. Most processors actually unroll their instructions into microcode. How those get mapped onto permutations of NAND gates etc. I don't really know.

MysticLord · « **Reply #16 on:** 2019-02-06 17:33:57 »

Here's a good new tutorial on Java 9:
https://chortle.ccsu.edu/
http://www.programmedlessons.org/Java9/index.html

quantumpencil · « **Reply #17 on:** 2019-02-11 19:01:14 »

Quote from: DLPB on 2019-01-27 00:17:29

I don't think it's a good language for any user. It baffles me why it's so popular. Not to mention all the different compilers with their different quirks. The language doesn't promote good efficient coding. It's an annoyance.

To this day, people keep repeating the lie that it's faster than other languages. It just isn't. They all end up as assembly and all modern languages have optimization. The differences you will see at that level are not perceptible.

https://aplawrence.com/Unixart/C_is_for_Crap.html
https://www.radford.edu/ibarland/Manifestoes/whyC++isBad-printable.shtml

This is not true. It's strange to say that a language is faster than another language; obviously you could write horrible C-code that constantly cache missed, inefficiently allocated/de-allocated memory many times, is chock full of copies, etc. 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. There's a reason why it remains the only choice for real-time (deterministic) programming tasks, or embedded systems programming. It's also lean and contains a small but useful set of core language features that are fundamental to computer science as a discipline -- unlike C++ -_-. Also this difference is absolutely perceptible, usually can be as much as 1-2 orders of magnitude over similarly well written code in a more restrictive language.

That's not really why it's good for a beginner, it'll be a while before you're worried about structure your data and iteration loops in a way that allows the most efficient pre-caching, or aggressively pre-allocate to avoid mallocs, etc. Getting the most of the freedom C offers requires substantial maturity as a developer and it requires you to structure your code in a specific way. If you don't have that, then sure, some other compiled language might get close to C's performance -- but everything you depend on is written in C, including many interpreters/compilers/drivers, and this is the case because in the hands of someone who understands programming at a low level it is STILL the best choice available. It's also the best choice available for editing compiled executable files, as it will let you get very close to the metal and won't get in your way with annoying unsafe blocks or restrictions on casting like other language which are attempting to 1-up C (Rust, for example -- and have failed) do.

C is good for a beginner because in order to be able to use it all, it requires you learn common transferable skills and develop a deeper understanding of core programming craft/CS concepts, which is a huge part of being a competent software engineer. There's no chance you'll spend much time working in C and not quickly develop an understanding of memory management, calling conventions, all steps of the compilation process (linking in particular), encoding schemes, etc.

Better tools are useful, but one should not be reliant upon them. This is why it's crucial that every engineer, at some point in their career, invest in learning C well if they want to expand behind writing CRUD app code and really begin to understand not just "x web framework" but computer science more broadly.

The other thing I will say that hasn't already been said: Learn a text editor well (Emacs/vim) and learn bash.

nfitc1 · « **Reply #18 on:** 2019-02-11 21:54:04 »

Just want to throw another hat in the ring. I know Pascal was supposed to be "great", but I hate it. Still hate C more, of course.

quantumpencil · « **Reply #19 on:** 2019-02-12 00:07:31 »

Quote from: DLPB on 2019-02-11 19:53:50

The only reason Delphi died (although it hasn't) is because of poor decision making by Borland in their hay-day, coupled with the fact they were competing with the might of Microsoft (who also ship the libraries and even freeware compilers) meaning many gravitated towards C over Delphi. Also, I hear, MS bought out loads of Borland's team.

As a language, Pascal is superior imho. It was, after all, made to create good programming practices:

https://en.wikipedia.org/wiki/Pascal_(programming_language)

And came after C.

I think C is a terrible language and this becomes more apparent when you see mediocre code that will then not compile properly on another compiler.

If you want to create a portable, self sustained program that will work almost universally when you ship the source to another person, then Delphi - or any other high level language - is the way to go. I don't need to mess about with memory management, crazy syntax, and other annoyances.

Of course, no-one is going to agree on this - but I'll dance the day that C dies.

The trouble we've been having with Aali's source would never ever have happened with Delphi - the language simply doesn't allow for it.

The trouble with Aali's source is just due to it being a large project with no sensible build system, and no management for its dependencies, it has nothing to do with the C language specifically. Also the reason that similar C code may not compile on different compilers is directly related to other strengths of the language and it's very wide adoption, namely:

1: Unlike other languages, there are actually different compilers as no single organization "owns" C and it's useful enough in a wide range of domains to warrant compilers optimized for specific types of problems. Also competition leads to innovation and both gcc and MSVC are incredibly good compilers by pretty much any measure, capable of extremely sophisticated optimizations.

2: It does not have the additional overhead of an interpreter or a runtime virtual machine (like JVM or BEAM) so the machine code runs without any other layers of virtualization.

It's also actually the most portable language that doesn't require some immense amount of overhead, and there are many domains it is *exclusively* suited for.

Pascal (and probably Delphi too), for example -- is way less portable than C or C++, getting it to work on anything other than windows would be a nightmare. People program toasters in C, robots, and a large maority of embedded systems. As the easiest and most portable non-interpreted or runtime VM based language, C enjoys many advantages in a great number of circumstances. Those advantages have tradeoffs of course, but so does the convenience and hand-holding of C's competitors.

You may not like it -- but C and C++ (especially C) are the de facto languages of systems programming, embedded systems, games programming, drivers, vms, compilers, interpreters and any performance sensitive task for a very, VERY good reason.

I hate to say it, but you're gonna be waiting a long time if you're hoping for it do die =p. It's been forty years and nothing has really threatened it's position in any of the above domains.

Also Pascal (I don't know about Delphi's history specifically) lost to C because of the rise of Linux, crappy portability, poor (and late) advanced OOP extensions, and being too verbose (ok, the last one is just my opinion). No language with a single proprietary 'creator" which doesn't open source it's compiler is ever going to keep up with a language like C/C++, which has huge communities improving gcc/domain optimized toolchains and contributing to new new language versions to this day. So Microsoft may have played a role, but there was definitely more than that to the story

Bosola · « **Reply #20 on:** 2019-02-12 09:44:14 »

Quote from: quantumpencil on 2019-02-11 19:01:14

There's a reason why [C] remains the only choice for real-time (deterministic) programming tasks, or embedded systems programming.

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.

Quote from: quantumpencil on 2019-02-11 19:01:14

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.

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?

Quote

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;
....
}

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!

quantumpencil · « **Reply #21 on:** 2019-02-12 14:16:10 »

Quote from: Bosola on 2019-02-12 09:44:14

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!

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.

nfitc1 · « **Reply #22 on:** 2019-02-12 16:12:51 »

Quote from: quantumpencil on 2019-02-12 14:16:10

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.

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.

MysticLord · « **Reply #23 on:** 2019-02-12 21:11:15 »

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.

Bosola · « **Reply #24 on:** 2019-02-14 12:48:54 »

@QuantumPencil - how do you feel about Rust?