I'm pretty new to programming...

I'm pretty new to programming, right now I know Lua and JavaScript and I'm looking to learn languages that are a little more classic and free standing, I guess. I know a lot of you guys say that learning C and then C++ gives you better insight into how computers work. But others say that learning C first can train you into bad mental models for programming.

Can I get a further explanation of this?

Also, I don't understand why people would learn C, when C++ is the same stuff, but with object oriented models and other more modern features and THEN go learn C++.

Other urls found in this thread:

youtube.com/watch?v=HQYsFshbkYw
github.com/devkitPro/3ds-examples/blob/master/camera/video/source/main.c
github.com/xem/3DShomebrew/blob/gh-pages/tutorial.md
gbatemp.net/threads/guide-noob-guide-to-wii-u-hacking.451297/
gbatemp.net/threads/wiiu-homebrew-development.391050/
github.com/EbookFoundation/free-programming-books/blob/master/free-programming-books.md#algorithms--data-structures
shodan.me/books/Data Structures/
inspirit.net.in/books/placements/Cracking the Coding Interview.pdf
is.ptithcm.edu.vn/~tdhuy/Programming/Introduction.to.Algorithms.pdf
infolab.stanford.edu/~ullman/focs.html
youtube.com/watch?v=GazC3A4OQTE
youtube.com/watch?v=zBkNBP00wJE
twitter.com/NSFWRedditImage

Learn C first, then C++. That's the true way. After that all other languages will seem like a joke to you.

No FUCK OFF.
Don't listen to this guy.

Modern C++ is VERY different to C. Doing C++ in the "C-way" is only going to cause troubles. Ignore the stupid fucktards that say C and C++ are the same langauges.

Is C worth learning then? Assuming that I've got less than a year of serious programming under my belt (closer to 6-7 months, honestly), that is. I'd like to learn things in an efficient and practical way that'll set me up to be able to maybe use it in a job or (more likely, given that I'm going into web development) in hobby projects.

bump

c++ is TRASH

Yes, C is worth learning. It's far less abstract than C++, less complex and quite arguably less ugly. I know both, and I usually choose to use C simply because there's less friction when using it. Also, since C is less complex, you're working closer to the metal, which is good to have experience with even if you don't end up using it. And yes, the same thing can be said about assembly.

...

T. Pajeet java "Developer"

>Ignore the stupid fucktards that say C and C++ are the same langauges.
I get that they are used quite differently in practice, but it's disingenuous to say that they aren't very similar languages. They are very much built on the same fundamental modes of execution and data modelling.

no. just don't bother with C++ at all.
If you end up using C++ the only parts you'll be using are basically C anyway (with some added thing from C++11).
ignore any retarded "Nice Object Oriented" shit it will just cause headaches down the road

Okay, that makes sense, I'd say. I'll keep an open mind then. If it'd build my understanding of how computers work, I'd be game for that. And I really like the idea of it being a little more on the simple side.

See, people say this sort of thing all the time. I get that yes, C++ has OO and C doesn't. But what other stuff is there that's meaningfully different? I don't need a complete list, just some sort of conceptual stab at it. What does C++ do well that C doesn't?

>C++ is a horrible language. It's made more horrible by the fact that a lot of substandard programmers use it, to the point where it's much much easier to generate total and utter crap with it. Quite frankly, even if the choice of C were to do *nothing* but keep the C++ programmers out, that in itself would be a huge reason to use C.

>What does C++ do well that C doesn't?
To me, who regularly prefers C of C++, the primary features of C++ that occasionally draws me to try it again, are RAII and generic programming.

C over* C++

The only benefit of C++ over C are features of the C++11 standard, for example things like constexpr and lambdas.
I still prefer C because it helps keep out java-tier object kiddies, but if you have the restraint to not use classes (or use them minimally), then C++ is fine

Damn. See, this is usually the part of the conversation that loses me. So, I know what RAII is where initializing a variable also grabs the memory for it, right? But I don't have a firm conceptual grasp of what generic programming is.

Got it, I guess. That doesn't exactly mean a whole lot to me. I'll google those two terms.

>I know what RAII is where initializing a variable also grabs the memory for it, right?
More importantly, it's the part where once an (automatic) object has been initialized, the language also guarantees that it is destructed.

I'm not exactly sure what that means. Something about garbage collection and keeping memory clean?

I didn't go to school for this, but I'm interested in learning these concepts. Is there a resource you can recommend that can give me a basic gestalt on concepts like this, in a way that's not geared to people with considerable experience already?

C is the closest thing to how a computer actually works.
Haskell is a great second language, I've heard it gives you habits that are good for other languages.

As for Lua, that works good with C, so it's useful to know.

That's really good to know. I'll look into C.

Is it possible to do actual game programming in C? In a way that's... not super obtuse and terrible?

I know Doom and Doom 2 were both written in C, which is fucking awesome and a huge part of why I'm considering C in the first place. But I know that JC basically cast spells on the code to make it happen, and I'm no genius.

I would argue that it depends on what you want to do.

(NEARLY) Everything that you can in C, you can do in C++. But both have their places in relatively different worlds.

Creating software might be better in C++
Working with embedded systems might be better in C.

I'd argue you should really consider what you want to CREATE, then decide which language would be best for those goals.

the biggest problem with C++ is its programmes. C++ is fine if you're a 1 man team and can avoid its broken features but when you have to stsrt working with people who abstract everything out the ass it'll be a huge headache.

Heck. I'm most interested in game programming, on the whole. But I might as well stick to JS and Lua in that case. Or learn Haxe or Cx.

I'm just starting out on my programming path, and I don't have the luxury of a classroom with a dude who's gonna tell me all the things I need to know. So I guess in the short term, the thing I want to create is a better understanding of what exactly programming is, so I can better crystallize the knowledge and become a better programmer.

>Is it possible to do actual game programming in C? In a way that's... not super obtuse and terrible?

Yes and No.

You CAN create a game in C, and if your goal is a DOOM-style game (with raycasting and etc) then it probably wouldn't be too obtuse and terrible to do

youtube.com/watch?v=HQYsFshbkYw
lodev.org/cgtutor/raycasting.html

Anything more complex than this, however, then I'd have to recommend C++

I feel like this is a problem of leadership, not C++.

Someone should be enforcing a strict programming style guide, and any code not up to standards should be rejected from the pull request.

But I suppose if you want to avoid that entirely then C would be perfectly fine as well.

if your biggest issue is efficiency then C is your best bet.
If not then C++ is fine and its abstractions CAN make things easier to program.
However, i would not recommend learning C++ if you're new to programming because it can easily get you into bad habits with abstraction ad-infinitum that doesn't benefit anything.

I've come across a bunch of this guy's videos. Weird dude, but he's pretty great at explaining things.

But yeah, I'm interested in creating a rather simple Doom-style game, just for fun and to see if I enjoy making it. I'll check these resources out. Thank you!

One last thing though, when you say 'more complex than this' what exactly are you saying? What extra complexity would create a situation in which C++ is radically better for the job? Conceptually. So lets say I've got Doom, right? What features that are present in modern games wouldn't be possible, and would require a move to C++? (And if, say, I made a game, I could just stick it in a C++ environment and it would run more or less okay, and I could add in C++ stuff, right?)

it's not that C can't accomplish more complexities, it's just easier using C++

Okay. That's good to know. Right now I'm getting alright with JS, what would a good next language be that would teach me well? I've seen people suggest stuff like Nim, Erlang, Go.

When I say something more complex than this, I mean anything that would require creating an entire engine.

If, for example, you wanted to create the next cawadooty:

Probably simple in C:
VoIP
3D raytracing Graphics
TCP/IP Socket networking

Easier in C++:
Players (Usernames, weapons, customizability, etc)
Maps
A video game engine

All of these are POSSIBLE in C, but EASIER in C++.
My example is kinda shitty, but the general idea is: anything that requires a lot of changing variables in an object would be easier to manage in C++. You can use C-structs, though. I just like the OOP organization that C++ can offer.

meant to put 3D raytracing graphics in the C++ category

Ah! Okay. That makes a lot of sense. Very interesting. Can I possibly treat C++ as an extension of C with extra features, then? Or am I missing the point and being retarded.

It's frowned upon in professional projects, but for personal projects I do it all the time, so I don't see the harm.

Okay, cool. I'll give this a shot then. I really don't wanna learn things poorly and seem like a moron in my future workplaces.

God don't listen to this utter unemployable moron. C++ is not slower than C and every fucking AAA game and game engine is written in C++. Don't listen to NEETs on Sup Forums.

>All of these are POSSIBLE in C, but EASIER in C++.
>All of these are POSSIBLE in x86 assembly, but EASIER in C.
>All of these are POSSIBLE on a turing machine, but EASIER in x86 assembly.

Utterly meaningless statement.

they are separate languages, it's important to keep that in mind (example of this would be const keyword is different, and that sizeless arrays in structs are not C++ standard). but C++ has libc, and you usually won't have to change anything porting code from C to C++.

>t. C++ brainlet
how many levels of abstraction are you on?

>I know Doom and Doom 2 were both written in C
Those were different times. Making games in the 90s for the PC was a lot less of a hassle.

But there are things that are EASIER in C as opposed to C++

Like, again:
>Embedded programming

It's not a meaningless statement

and
>All of these are POSSIBLE in x86 assembly, but EASIER in C.

but there are literally things not possible in C that can be done in x86, closer to the metal

So to say that it's a meaningless statement, without a good example, i think is an unfair argument.

Enough to be employable.

Got it. Alright. Man, I feel like a brainlet, there's something fundamental about programming that hasn't popped into my head yet.

Pls no fight. I don't wanna be a brainlet.

Yeah but... I mean, Doom has really stood the test of time. Wouldn't the lack of floating point stuff have made building a FPS in the 90's a lot harder?

I doubt you're even out of school. Adults are talking here so why not go abstract yourself off a cliff you insufferable troglodyte

>go abstract yourself off a cliff you insufferable troglodyte

Holy shit my sides

t. Abstractlet

>Yeah but... I mean, Doom has really stood the test of time.
You probably never played it on the original engine and used a source port, which drastically impacts your judgement on how well it aged. My point is that back in the 90s you could get a LOT closer to the hardware which allowed for some insane low level optimizations. These days everything is locked behind a driver or an API, which means you as a programmer no longer have direct control and there is no guarantee how well it is going to run on a different PC. When Carmack wrote Doom there was no 3D accelerators or anything like that. The entire graphics are done in software by Carmack himself. Modern APIs like OpenGL and especially Vulkan are devilishly complex (like 1000 lines of code to render a single triangle complex, in the case of vulkan) and you will go insane without language features like metaprogramming and OOP to abstract away the madness. Not to mention, Dooms rendering technique is really really simple by today's standards. Game development for PC has gotten way too complex. And now you know why most devs either use an engine or just develop for consoles.

>Wouldn't the lack of floating point stuff have made building a FPS in the 90's a lot harder?
I'm fairly certain x87 floating point was quite common by the early 90s.

I'm in university and I already have a job. Your move.

Usually people don't like it when you write C and use a C++ compiler but it's not really that big of a deal.
Since your primary focus is game programming C++ is probably what you should use. Although use OO sparingly, the abstraction helps at times but don't overdo it

You're right. I played through it all in its original form on DOSbox, but then swapped to a port. I understand what you mean now, about going low level. I just want to git gud. Like that dude who wrote minecraft in C++ and openGL in 23 hours. But yeah, I hear you. You're totally right.

I'm wrong, I was thinking Wolfenstein. That wast written with fixed point, right?

>I'm wrong, I was thinking Wolfenstein. That wast written with fixed point, right?
No idea, but you probably wan't to aim higher than something like Wolf3D.

To add to my earlier point: Back in the 90s you just had a pointer to a fixed address that you interpreted as an array and BOOM, you could write pixels directly to the frame-buffer. No libraries and no drivers required. (You can still do that if write your game as if it was an os kernel, but good luck with that). These days you are fucked. You write some C or C++ code and you want to output sound or graphics and suddenly you are drowning in a mess of libraries, APIs and other nonsense. Of course, you could use Win32 to write to some sort of 2D framebuffer that windows provides you, but that will probably make you want to slit your wrists. As a failed C++ engine dev I can only advise you to forget both C and C++ if you actually want to make something resembling a game. Unless you use Unreal 4.

I definitely do. Part of me just wants to learn C++ and use my Lua and build something in Amazon's new Lumberyard engine. I'd learn C as a side project to better understand the computer and tinker with stuff, but the more y'all talk about it, the radically less practical doing anything interesting with it starts to sound.

But then what should I use? You tried to build your own engine in C++? I'm mostly looking to make games for fun (and to practice my programming without it being the same shit I do at my day job), and I'm looking to make the process as fun and as lacking in the wrist slitting as possible.

if you ever need to do anything low-level then C is really the best choice. or if efficiency is your main concern.
these things don't seem to be relevant to your interests through so maybe it wouldn't be so useful to you

>and I'm looking to make the process as fun and as lacking in the wrist slitting as possible.
Use a game engine then. Unless you want to make shit like tetris or snake. The vast majority of indie games are not written from scratch.

Cuphead is Unity. A Hat in Time is Unreal Engine 3. Hollow Knight is Unity. Risk of Rain, Hotline Miami and Undertale are made in game maker. There is a reason for that. If you are a single person and you want to make games that people actually want to play and not just shitty toy programs there is no way around using an engine.

That's the impression I'm getting.

This is good to know. I was aware of most of those. I wasn't sure if understanding how the engine works and all that shit was required for making a game on a platform that worked well. I don't know anything about anything, I guess. I'll keep this in mind.

Not him, i'm the and guy,

For me personally, I actually do a lot of hobbyist programming on Nintendo 3DS/Wii U homebrew. It really does give that same bare-metal feel to programming like back in the day

For example, talked about writing pixels to the frame-buffer. This is also done on homebrew: github.com/devkitPro/3ds-examples/blob/master/camera/video/source/main.c (Not made by me)

It's not really the LANGUAGE (c or c++) you use, but the PLATFORM you decide to program on

Pajeet, you should learn to use the toilet first and then you can advance to C++ etc.

Very interesting. I don't mean to put you out, but could you tell me more about this? Is it fun and engaging? Are you writing it all in C?

I'm literally pooping in a toilet right this minute as I type this response (thanks thinkpad) so I think I'm ready to ask about advancing in the world.

>if you ever need to do anything low-level then C is really the best choice. or if efficiency is your main concern.
Not true. You can go just a low level in C++ as you can in C. You could go as far as writing a program that runs without an Operating System in C++, aka a fucking Operating system.

>It's not really the LANGUAGE (c or c++) you use, but the PLATFORM you decide to program on
This a million times. I'm just assuming that he wants to develop for PC. The deeper I get into CS and computers, the more I start to understand why developers hate the PC. The entire platform is a nightmare to develop for. I would always use C++ if I have to go low level, but that depends if there is even a compiler available for the platform. You need at least support for C++11. Most of the C++ hate comes from people who only experienced C++98 and is 100% justified.

lets be real, learn only what you are going to use in your life

>You can go just a low level in C++ as you can in C
just because you can doesn't mean you should. C++ object features don't benefit low-level development at all

If you can implement new and delete, C++ would give you the entire fucking STL. Which is not even object oriented. And why woudln't OOP benefit low level development? Why not build your own abstractions on top of the low level stuff which you completely control? Windows is written in C++.

I don't think I'll ever need to (or want to) go that deep into computers. I just wanna do hobbyist shit. I do like the idea of developing for the WiiU, if it's stimulating.

I agree with you, which is why I'm trying to pin down a language or four that I, as a beginner, can pick up now and then keep in my pocket for my entire life as a programmer, getting better and better. C++ gets a lot of use, and I was curious as to if it might be one of those few

>I just wanna do hobbyist shit. I do like the idea of developing for the WiiU, if it's stimulating.
The WiiU is a computer.

>Very interesting. I don't mean to put you out, but could you tell me more about this? Is it fun and engaging? Are you writing it all in C?

Honestly, I personally write in C++ nearly everything. I just kinda use C when I have to. It's just personal project for fun, so i don't really do anything proper.

A github project I contribute to that has a full rundown of getting started is github.com/xem/3DShomebrew/blob/gh-pages/tutorial.md

I consider it very fun and engaging. For the 3ds, many of the exploits needed to get started in the scene have been patched. If you already have a 3ds that's on a early version, you should look at

Rust or go

Not that guy, but is homebrew PS4 a thing yet? The entire SDK got leaked after all.

Right... But it's a specific platform with specific standards, right? It's not like the PC.

>I do like the idea of developing for the WiiU, if it's stimulating.

Fortunately for you, wii U homebrew is easy to get started in.

gbatemp.net/threads/guide-noob-guide-to-wii-u-hacking.451297/

gbatemp.net/threads/wiiu-homebrew-development.391050/

>And why woudln't OOP benefit low level development?
because it's not needed and leads itself to inefficient, overly-abstracted programming models
>Windows is written in C++
>implying the Windows kernel is a shining example of good low-level code

I do have an old 3DS that I actually hacked already. I'll go look at what /vg/'s got for me and at your git link. This seems interesting. Do you use C++ professionally?

Thank you! This will be interesting to dig through

Windows NT is a solid kernel. Also OOP is not inefficient. It's literally just a way of organizing data. And function points are not faster than virtual calls.

Probably very, very, very soon. I do believe it's picking up a lot of attention and steam, so i feel like it's only a matter of time.

For that, too, i'd just keep checking every couple of days.

>Do you use C++ professionally?

I'm an CS student, so not yet. I have applied to some internships and hoping for the best.

Very cool. I wish you nothing but luck, you seem to have a passion.

>because it's not needed and leads itself to inefficient, overly-abstracted programming models

No. Only for idiots who use design patterns everywhere.

Learning programming languages is easy provided you have an idea on data structures and the most popular algorithms. Learning a new programming languange is learning the syntax, main frameworks made for said language, best applications and you are good to go.
If you want to get better at programming learn design patterns (mainly for objects oriented languages), abstractions, modularizing your program. All stuff that makes your code easier to understand, easy to modify and makes it reutilizable across other similar programs.

Thanks

If you ever have any questions, I suppose if you leave an issue on that particular repo i'll likely see it and answer it eventually. I'm not the owner of the git, i just contribute a lot to it

C++11 and lambadas literally deprecate 90% of shitty design patterns.

>OOP is not inefficient
are you saying something like pic related is not inefficient? because this is what ends up happening when people use OOP. the problem is not necessarily in OOP itself, but in how people use it.
If you remove OOP from your project it will absolutely be more efficient, because people won't create useless abstractions that don't benefit anything.

Sounds good to me. Where can I learn all that shit? I'm pretty much self taught in just about everything. What I haven't taught myself, I've had a senior developer at my job teach me.

Okay! I appreciate it. I'm going to investigate all this tonight.

Agreed. In fact design patterns seem to be most commonly used to work around the many limitations in Java instead of doing anything at all useful.

>because this is what ends up happening when people use OOP.

That's Java and it's a bad language which encourages bad practices and has a lot of bad programmers. Limitations on the language aren't going to make shit programmers good.

God dammit, you're a retard. Where do I even begin?

1. That's a managed language. Of course it's fucking inefficient.
2. Design patterns are cancer and have nothing to do with OPP. That's a shitty meme from the 90s.
3. Nobody actually writes code like that. Especially C++ devs.
4. You could create a similar level of abstraction in C.
5. This code is not actually inefficient if everything gets in-lined properly .
6. You're a moron who thinks that abstractions somehow translate 1:1 to CPU time spend. Hint: It fucking doesn't.

With Java 8 you don't need most of them. Who the fuck needs an observer pattern if you have lambdas and """first class""" functions?

name 1 thing OS programming or embedded systems would benefit from OOP abstractions

As far as I know there are books on design patterns, which are solutions that work for the most common problems that may appear in objects languages.
AFAIK, there are also some websites which explain them with examples.

That being said, they are not a golden rule, just guides. Like says, it's kinda like a meme, but helps to identify patterns quickly and not having to rethink everything.

If you've ever tried to write a gui application with nothing but a C api you will begin to understand. Also, like I said, my primary motivation for C++ would be the STL.

A lot of them already do use them to a certain extent. As soon as you start making non-trivial creation functions for structs and sets of helper functions which take consistently a single struct as the first argument, you may as well be defining a class.

And let's not get into the rampant preprocessor abuse in many complex C programs.

you didn't answer my question though. i'm talking about low-level (kernel/embedded systems)

github.com/EbookFoundation/free-programming-books/blob/master/free-programming-books.md#algorithms--data-structures

shodan.me/books/Data Structures/

inspirit.net.in/books/placements/Cracking the Coding Interview.pdf

is.ptithcm.edu.vn/~tdhuy/Programming/Introduction.to.Algorithms.pdf

infolab.stanford.edu/~ullman/focs.html

youtube.com/watch?v=GazC3A4OQTE

I'm not saying OOP is inherently bad. i know there are cases where it can be helpful. i'm just saying the way C++ handles it leads to bad programming practises.

>i'm just saying the way C++ handles it leads to bad programming practises.

What do you mean? C++ doesn't at all encourage any particular OOP practices.

Abstractions can be useful but they are an easy trap to fall into since they always have a cost. It's very easy to prematurely abstract a code or to overabstract it. I think the better way is to abstract when needed.

The hidden costs of an abstraction can be
1) development time for an abstraction. If it's a premature abstraction that turns out to be a bad one, removing it from a system isn't an easy task. Refactoring a more mature system into creating an abstraction by observing how the system is structured should be easier.

2) cost of understanding the code - abstractions make the code easier to understand on a surface level but they hide implementation details which can be vital for a newcomer to the project or even for you if you pause the project for quite some time. This cost is very high if you overabstract the code. So when abstracting you should consider if the benefits of the abstraction are worth that cost.

>Abstractions can be useful but they are an easy trap to fall into since they always have a cost.
>since they always have a cost.
Wrong. Wrong. Fucking WROOOOOOOOOOOOOOOOONG.

The problem with abstractions is that if they're too heavyweight they either come at a performance hit or they leak implementation behaviour.

And abstractions done correctly remove the unnecessary cognitive load when trying to understand portions of a system.

are you going to elaborate on this or what?

I'm going to guess he means that certain abstractions in C++ are completely optimised away and cost absolutely nothing at all. And in fact in some cases may even be faster than a naive implementation without the abstraction present.

There is no reason to learn any language other than Java in 2017 and beyond.

>certain abstractions
well that might be true in some circumstances but in general over-abstraction absolutely has a cost
(You)

template
struct Factorial
{
enum { value = N * Factorial::value };
};

template
struct Factorial
{
enum { value = 1 };
};

// Factorial::value == 24
// Factorial::value == 1
void foo()
{
int x = Factorial::value; // == 24
int y = Factorial::value; // == 1
}

Where is your god now?

>but in general over-abstraction absolutely has a cost

You need to watch this

youtube.com/watch?v=zBkNBP00wJE