Programming thread -

[CrunkLord420]

How big is it?
.net core is like 600MB

It depends on your Linux distro, it's at least 300MB+. The packages are especially sprawling, installing mono from the official repository is 100+ individual packages. It involves running various additional tasks that are totally unique to mono. Regenerating certificates, recompiling itself (despite being a binary distribution), thousands of random bullshit non-code files. It's like it wants to be it's own little operating system unto itself. Nevermind WinForms is unsupported and extremely buggy.

Mono works, but it always feels like you're in edge-case city. It's like the developer needs to specifically make sure everything is kosher in Mono.

 

[Megatorg]

What are some common mistakes made by beginner programmers?

 

[Vecr]

What are some common mistakes made by beginner programmers?

When I started out, I found it hard to write complex programs that were maintainable and easy to find bugs in. That's not really one thing that I got wrong though.

 

[Kosher Dill]

What are some common mistakes made by beginner programmers?

Off-by-one errors come immediately to mind as a universal problem. And memory management issues of various sorts, in languages where you manage it yourself.
Misusing data types is another "noob mistake". If you say

int x = 3/5;

It'll do something but probably not what you were intending.
Strings typically have a number of subtleties depending on exactly what language/libraries/encoding you're using. (Did you forget the null-terminator?)

 

[Least Concern]

What are some common mistakes made by beginner programmers?

Good question. Some thoughts:

Contrary to what some people try to tell you, programming is not for everyone. If you're first trying it out and you're not having any fun or feeling very motivated after a while, that's okay. It doesn't mean you're stupid. Not everyone can be a programmer just like not everyone can be a car mechanic or novelist. I had a buddy who went to college for an IT degree but gave up after one semester because he hated programming. He now owns a chain of retail stores in the southwest and is probably a millionaire. He failed becoming a programmer but failed at becoming a failure. (Pretty much the opposite of me.)

Learn version control early and use it often. It will be a pain in your ass to learn, but your ass is also what it can save.

Beware the Dunning-Kruger effect. (Perhaps, specific to programming, we should call it the Yanderedev effect.) After programming for a while and being able to get the computer to more or less do what you want for a while and maybe even getting someone to pay you for it, it's easy to start thinking like you're hot shit. But there are always going to be people who have been doing this for far longer than you have and have much more experience. Stay humble and don't get stuck in your ways - always be willing to learn new ways of doing things and accepting that the ways you've learned to do things might not be the best, even if you've been doing it that way for years. Related to that, don't be afraid to ask questions on places like Stack Overflow or IRC channels. Even if you just lurk at these places, it can help to expose you to libraries and such that you didn't know existed. Always be learning. Related to this, beware the XY problem; if you're asking about how to do Y to do X, don't be upset if people challenge you about doing X. I often see conversations like this in IRC channels:

Noob: I'm emailing users their passwords in plain-text emails, but the emails sometimes take half an hour to send. Does anyone know how to make sure they get sent immediately?
Neckbeard: Uh, why are you sending users their passwords in plain text? You shouldn't be doing that; it's a major security vulnerability.
Noob: LOOK JUST TELL ME HOW TO SEND EMAILS IMMEDIATELY OKAY I KNOW WHAT I'M DOING GOD YOU PEOPLE ARE USELESS

Don't be that guy. If someone with more experience challenges some aspect of your code, there's likely a very good reason for it. Programmers generally do not knowingly give each other bad advice.

Don't reimplement wheels. Before writing code to do something, check to see if there's an existing library out there you can leverage which does what you need. Odds are that library was written by someone smarter than you and has been subject to scrutiny by other developers, so it is probably faster, more secure, and less buggy than what you would write by yourself, and of course you'll save a lot of time while you're at it.

There is no magic involved in the function of a computer. If something doesn't work as expected, it's effectively impossible that that was just a weird one-time bug that will go away on its own. If there's a bug, it's almost certainly in your code and not in the frameworks or libraries or OS or hardware that you're using. Okay, yes, it's theoretically possible that the bug is in someone else's code, or was caused by an errant magnetic wave flipping a bit in RAM, but very unlikely. 99.5% of the time, the bug is in your code. Look there first.

Value your time and your work. You have a valuable skill. Unless you're volunteering for a charity or working on an OSS project or something, don't work for free or for stock options or for exposure. If you're freelancing, have a clause in your contract which ensures you have the copyright to any code written that a client hasn't paid for, and if they don't pay you, cut them off from the code until they do. Always try to get $5 or $10 more per hour on your next contract compared to your previous one. If you're salaried, always be open to offers from other companies in your area, especially if your current company is screwing around with you and making you crunch. Don't think you have to be loyal to a company because they have a kegerator and a Ping-Pong table in the break room but gee, do you think you could come in on the weekend so we can get this sent to the client by Monday, I'll get some pizzas delivered to the office, it'll be fun. You don't have to put up with that kind of manipulation.

 

[SIGSEGV]

It doesn't mean you're stupid.

Wrong.

Don't reimplement wheels. Before writing code to do something, check to see if there's an existing library out there you can leverage which does what you need. Odds are that library was written by someone smarter than you and has been subject to scrutiny by other developers, so it is probably faster, more secure, and less buggy than what you would write by yourself, and of course you'll save a lot of time while you're at it.

Reinventing the wheel can be a fun and/or educational side project, but never do it in production code unless you have a very good reason for doing so. Don't roll your own cryptography, though. That's never a good idea.

 

[Kosher Salt]

What are some common mistakes made by beginner programmers?

Failing to understand pointers and references and whether things should be passed by reference or by value (copy). I'll second on memory management. Logic errors, of which off-by-one is a pretty common one but also including things like unreachable code or writing code with redundant or contradictory conditionals.

Oh, and comments. Write comments. Write good comments. Keep them up-to-date. Comments should describe, at a high level, what the code is doing, and sometimes why. For example, don't just write "add one to x." You can see that just by reading the code. Instead, write something like "increment the item count." That tells you what the code is doing and it gives enough context to understand why it's doing that. Having good comments will make it easier to find logic errors in your code.

I'll also add the whole issue of naming, although even experienced programmers sometimes struggle with this. When is it okay to name the variable x, and when should it be named item_count? It probably depends on how much code is using it. Naming can be difficult, but when in doubt, it's probably good to just err on the side of giving descriptive names.

 

[majorlyPickled]

What are some common mistakes made by beginner programmers?

Not learning college-level math because proofs are hard.
To be specific, you are definitely going to want to take a look at graph theory, at the least (I mean c'mon, finding optimal paths, efficient data structures, plus more niche stuff like finding longest subsequences etc. is all based on graph theory). Linear algebra and (multi-variable) calculus are pretty nifty too, to name a few.

Now, I am not saying you need to know lots of math to be a programmer. Hell, you could do without it completely. But designing algorithms is gonna get a lot easier, trust me on this one.

@SIGSEGV @CrunkLord420 @Kosher Dill et al any thoughts on this?

 

[Stock Image Photographer]

I'll also add the whole issue of naming, although even experienced programmers sometimes struggle with this. When is it okay to name the variable x, and when should it be named item_count? It probably depends on how much code is using it. Naming can be difficult, but when in doubt, it's probably good to just err on the side of giving descriptive names.

There's a book called "The Art of Readable Code" that deals with this. I think you can download it off libgen, but if you can't I have a pdf copy I can put on anonfile or something for anyone who wants it.

But designing algorithms is gonna get a lot easier, trust me on this one.

What you're saying is probably true, but how often is a programmer going to generate entirely novel algorithms?

 

[majorlyPickled]

There's a book called "The Art of Readable Code" that deals with this. I think you can download it off libgen, but if you can't I have a pdf copy I can put on anonfile or something for anyone who wants it.

What you're saying is probably true, but how often is a programmer going to generate entirely novel algorithms?

I think your definition of an algorithm might be a bit more specific than mine; what I was trying to get at, is that you would be better equipped to transform an informal computational problem into a more formal one, come up with a solution and ensure you chose the best one.

 

[Least Concern]

Not learning college-level math because proofs are hard.
To be specific, you are definitely going to want to take a look at graph theory, at the least (I mean c'mon, finding optimal paths, efficient data structures, plus more niche stuff like finding longest subsequences etc. is all based on graph theory). Linear algebra and (multi-variable) calculus are pretty nifty too, to name a few.

Now, I am not saying you need to know lots of math to be a programmer. Hell, you could do without it completely. But designing algorithms is gonna get a lot easier, trust me on this one.

@SIGSEGV @CrunkLord420 @Kosher Dill et al any thoughts on this?

We actually had a good discussion about the level of math that programmers need to know a bit earlier in the thread, starting here. The consensus was that while there are fields of programming for which college-level math is useful or required, you can still make a career out of only a high-school-level understanding of algebra, geometry, and trigonometry - as I have.

 

[Kosher Dill]

Now, I am not saying you need to know lots of math to be a programmer. Hell, you could do without it completely. But designing algorithms is gonna get a lot easier, trust me on this one.

@SIGSEGV @CrunkLord420 @Kosher Dill et al any thoughts on this?

I took "beginner programmers" to mean someone who's learning their first programming language and would typically just be using standard libraries or implementing common well-known algorithms. Getting into formal math I'd say is for more advanced programmers working on problems that require you to move beyond the canned stuff.

 

[SIGSEGV]

Not learning college-level math because proofs are hard.
To be specific, you are definitely going to want to take a look at graph theory, at the least (I mean c'mon, finding optimal paths, efficient data structures, plus more niche stuff like finding longest subsequences etc. is all based on graph theory). Linear algebra and (multi-variable) calculus are pretty nifty too, to name a few.

Now, I am not saying you need to know lots of math to be a programmer. Hell, you could do without it completely. But designing algorithms is gonna get a lot easier, trust me on this one.

@SIGSEGV @CrunkLord420 @Kosher Dill et al any thoughts on this?

I've never had to use anything that even resembles higher level math while programming. Most of my "I have to stop typing and think about this shit" moments are related to overall logic and control flow, but on occasion I'll need some very basic math for loop conditions or choosing between prefix/postfix increment/decrement.

 

[AnOminous]

Wrong.

Reinventing the wheel can be a fun and/or educational side project, but never do it in production code unless you have a very good reason for doing so. Don't roll your own cryptography, though. That's never a good idea.

That even applies to completely well known cryptosystems. Unless you're specifically a crypto genius you are going to fuck it up in some subtle way that completely destroys its usefulness.

 

[Marvin]

Speaking of crypto, this is a simple implementation of RSA in scheme. It's very educational. Or at least I found it interesting.

(Actually in general I'm a big fan of all of Matt Might's programming articles.)

 

[H.P. Lovecraft]

Behold I have seen the future!
In the future, everything compiles to Javascript.
Entire architectures are based around hardware implementations of Javascript. C? That compiles to Javascript in the future. Even PHP is compiled to Javascript!

It may as well. Everything is going to be made in electron, for no good reason either. Things like code editors being made with a web framework really peeve me. If I wanted my code editor to launch 20 other processes and take up a ton of ram, Iid use google chrome and edit my code in the text box on pastebin.

 

[MarvinTheParanoidAndroid]

So I was watching this video about assembly code and I encountered something that muddied the waters for me.

He mentions that C++, C# are for virtual machines, exes, and drivers, but he makes no mention of operating systems. Isn't Windows written in those languages? I thought a virtual machine was supposed to be an OS loaded entirely on random access memory as a security feature or for running backwards compatibility on old software, is he saying that operating systems and virtual machines are the same thing?

 

[jasamhehe]

I'm at the point where i see no reason to bother with C, C++ or anything else that isn't javascript. I'm pretty sure everything will switch to JS in the future.

 

[Isam]

So I was watching this video about assembly code and I encountered something that muddied the waters for me.

He mentions that C++, C# are for virtual machines, exes, and drivers, but he makes no mention of operating systems. Isn't Windows written in those languages?

Yes, I don't know what Windows is written in exactly, but Linux is written in C. What he's getting at is explaining what makes a "low level" language vs. a "high level" one. In the end the CPU only executes CPU instructions, the lowest level, everything else must be converted into these instructions somehow: higher level means more abstraction from machine code. That's my take on it in any case. I would not put "declarative structures" on that scale as they aren't programming languages, but declarative.

I thought a virtual machine was supposed to be an OS

That's what's usually meant by a virtual machine, but there are lesser VMs for executing stuff such as what Java JRE is. Wikipedia labels these "process virtual machines".

 

[Kosher Dill]

He mentions that C++, C# are for virtual machines, exes, and drivers, but he makes no mention of operating systems. Isn't Windows written in those languages?

It sounded to me like they're just assuming for this discussion that you're working within an operating system and not writing one.