Yeah, except I'm not going around recommending people use my game engine, or D.

I'm perfectly happy to admit there are a long list of engines and languages a person should use before they use my engine or D. Ask a Rubyist to do the same and he'll probably pop a sprocket or something.

Using an unpopular / underdog language doesn't make you a hipster. Ignoring 12 perfectly viable languages and choosing the hipster language that nobody but hipsters use makes you a hipster.

And Rails... I never would recommend a beginner to start with that

The language is useless without Rails. Seriously, go find a project which doesn't use Rails. Maybe you'll find a couple. So... You are recommending Ruby why? Because that's what hipsters use?

Wait, wait, wait, wait... Hold your fucking horses! You criticize PHP for being "Web Centric" and then jump WAAAAAAAAAAAAAAAAY down the list to recommend Ruby (on Rails). The language where the only common use is for RESTful web services.

I mean, yeah, I get you on the PHP thing. I mean who gives a fuck about PHP anymore? But even NOBODYER gives a fuck about Ruby (on Rails). That's how embarrassing this list is for Ruby (on Rails don't forget the rails because otherwise Ruby is 100% pointless).

OP never said the language has to be "easy". He just said he hates forced indenting. PHP solves his problem. Or Javascript, or Perl, but let's recommend some obscure hipster language instead.

I mean, fuck, as long as we are recommending obscure languages, let's do it right and throw in D. It blows everything else in this list out of the water. But as much as I love sucking on the giant D, I don't go around recommending it, because I'm not a fucking hipster.

Plenty of unlikable assholes use PHP too. You're one. I'm one.

When did I ever say I use PHP? I don't (Not for years anyway.).

This isn't some stupid language holy war. I'm just stating a statistical fact about various languages. Nobody uses Ruby, (especially without it's famous crutch, Rails). You can talk about the 1.4% who do use it all day. But if 1.4% is all you have, you don't have much of an argument to stand on.

What you DO have is a bunch of hipsters. This isn't an insult. It is an accurate demographic landscape of Ruby (Don't forget the Rails)

I'm not here to defend PHP. All I said was PHP was the true successor to Perl, Ruby isn't a successor to anything. Which is a statement of fact, not ideology. In order to be a successor to something, people need to at least use it. Ruby ON RAILS (cough, cough) 1.4% market saturation is statistically insignificant.

As for all the examples you gave, yes sometimes hipsters make a good product. That wasn't the issue. The issue here is that it is hipsters who chose the technology. A statistically insignificant technology.

Writing a application in Ruby now is kind of like writing an application in Cold Fusion back in the 2000's. Did people make legitimate applications? Sure. Did anyone really give a fuck about Cold Fusion? No. Only the hipsters gave a fuck about Cold Fusion and only hipsters give a fuck about Ruby (ON RAILS).

TIOBE index pretty much solidifies my statement. When a language only represents 1.4% of the market place, it nears the category of "Statistical insignificance".

Furthermore, Ruby developers aren't really Ruby developers. They are Ruby on RAILS developers. Nobody (Except for hipsters) is using Ruby for the sake of Ruby. It's more accurate to say 1.3% of developers are Rails developers and only 0.01% are actually Ruby developers. Ruby wouldn't even make the TIOBE index if it weren't for Rails.

PHP is FUBAR.

I agree, which is why I don't use it any more. However, if we are using the TIOBE index to justify a language, it still beats out Ruby.

PHP was the successor to Perl. Ruby isn't a successor to anything of importance.

I would recommend Ruby as an alternative

What are you some kind of hipster or something? Don't use Ruby for scripting. Nobody fucking does that (Except for hipsters).

I have absolutely no clue why on Earth it is impossible to have a desktop version too

Because OP, (AKA "Alex Booker") is a hipster. For hipsters, such things are impossible.

Go into the /v/programming subverse. Take a look at all the submissions with downvotes. You'll find there really aren't any... Except for when it comes to drama posts.

People do speak up and downvote. Are you going to listen and stop this nonsense? Or are you going to pull some kind of victim complex and claim this is some kind of conspiracy against you.

Once again. This isn't a subverse that tends to downvote good content. Your content got downvoted. That should tell you something.

Your post isn't programming related. It doesn't have any code, or theory.

You are the clown performing at a fine restaurant and then complaining when people at the restaurant tell you "The Circus is down the street. Maybe that is a better place for your performance?"

Certificates are bullshit. What an employer really wants to see is a GitHub account full of activity. Personal projects which demonstrate your skill. An ability to complete something. Collaboration on projects.

Incidentally, I've recently started mentoring anyone who wants to learn and build, because this question gets asked every day. I have an open source game engine that I'm building. There are a number of people, just like you, helping me out. In exchange I provide guidance and goals.

Instead of getting a certificate, come join the team and get a verifiable record of work. Or if you don't join the team, at least work on something that can be verified.

Don't buy into the "Gamer Glasses" they are just yellow tinted glasses. Unless they are prescription, they are not worth the price.

Do they help? Our eyes are sensitive to the color green. Generally speaking the light indoors is blue shifted. Yellow lenses shift the spectrum back into what we are supposed to see.

Does it help? No. Why? Look around the room. How much green do you see. Almost nothing right? The walls are white. Your desk is beige. Your chair is grey. The carpet is brown. You're senses are going to be overwhelmed with or without the yellow tinted glasses. Look at the wall with yellow tinted glasses and you don't see green. You see yellow, which is just as bad as seeing blue.

I gave a fairly verbose answer on "Opinionated Language" to /u/frankenmine you should read that.

"Hipster Logic" just means that something has a lot of flair without any original substance. For instance, if you compare Ruby to more popular languages, you'll see that it doesn't really solve any problem. It's primary virtue is to aesthetically appeal to the ego of the programmer.

So, while the applications of Python are great in scope, (Academia, Systems Admin, Gaming, Application Dev, RESTful Web Dev, etc..), Ruby tends to almost only be used for RESTful web development. In fact, if it weren't for Rails, Ruby wouldn't even be on the charts. The only job you are likely to get as a Ruby developer is as a Rails developer.

Sure, the Ruby fan-boy will point out the odd application which is not a RESTful web service, but those are the exception not the rule.

Don't get me wrong. I like Ruby. But it doesn't solve any problem that a more popular language does just as well. And thus the only people who are attracted to it are "Hipster Types", who like it because the language appeals to their ego. Not because of Ruby's merit.

"Opinionated Language" I don't think is an official term of any sort. It's kind of like "Hipster Language" nobody in computer science has written a paper defining any of these terms, but we use them anyway.

Generally speaking, any language which has the ideology of "Only One Correct Way To Do It." is an opinionated language. So, you are going to have people talking about "The Ruby way of doing something", meaning you could do it this way, but the "Ruby way" is the way you are supposed to do it. But someone else is always deciding which way is the "correct" way. It's a matter of (someone else's) opinion and you are expected to conform to it.

In other words, there are many ways of skinning a cat, but there is a specific "Ruby Way" of skinning a cat. This culture gets much worse as you delve into Rails. I'm fairly certain Rails should be classified as a cult.

Python is guilty of being opinionated as well, but to a lesser extent.

C / C++ is the anti-thesis of an opinionated language in that it's philosophy is: "We expect our devs to be competent. They probably know what the fuck they are doing. So, do whatever the fuck you want."

A good source to show that Ruby is opinionated would be this interview with Ruby creator, Yukihiro Matsumoto.

Here are some snippets:

I emphasize the feeling, in particular, how I feel using Ruby. I didn't work hard to make Ruby perfect for everyone

I believe consistency and orthogonality are tools of design, not the primary goal in design.

Actually, Ruby is an "Opinionated Language" which means there is an ideology involved which reflects the opinion of the community. There is a great deal of "hipster logic" which has seeped into the language as a result. Of course, they won't call it "hipster logic", but you can read between the lines in the language manifestos and understand what I'm talking about.

Hey everyone, I found the hipster / Ruby programmer!

Calm down, princess. I haven't said anything that wasn't statistically accurate. There is a high correlation between Ruby and hipsters. There is also a high correlation between hipsters and nonsense.

Don't get mad at me for the irrational tendencies of hipsters. Might I suggest going back to Reddit? They have safe spaces for people like you.

Don't be silly. Code is code, business is business.

Yes, and hipsters are hipsters. The way they do code and business is not exactly based on logic. Which is the opposite of how someone should code and business. Hence, Ruby and MongoDB, etc.

I swear to fucking God. Ruby's tag line should be: "It's Python, but we put a bird on it and called it art."

I like GitLab. I use it for my private projects.

The only problem I have with it is it is written in Ruby. I'd like to contribute to the project, but I don't have a strong tolerance for hipsters.

When I hire, I typically tell the person to go on to Project Euler solve whatever problems he wants at any level he wants and send me what he has in a week's time.

It's pretty easy to look at the submissions and get an idea of what skill level the guy is at.

Let's say there is a package manager which uses git sources as packages.

It automatically downloads a git project as a package and it wants to compile. which version does it compile? Does it compile Branch 1.1.0? Branch 1.3.0? Branch 1.4? Branch 2.1? Which of these versions are stable? Which are alpha / Beta / unstable?

You can't tell just by looking at the numbers. But you can designate master to branch 1.4 (Which happens to be the stable branch). By your logic the package manager would use Branch 2.1 (Which is an alpha branch)

A package manager doesn't understand arbitrary versioning schemes. But it does understand that it is standard to include a master branch which represents the most important current branch. If there is a master branch the package manager always knows to compile whatever master branch represents.

Likewise with humans. When I download a git repository, I don't have to mess around figuring out which branch is the latest stable branch. I know I can compile master and everything will be the most important current branch.

and then months later you find want to add in a feature that lets you...

That problem was solved years ago with migrations. It takes a tiny bit more planning, yeah. But that's what developers do. We fucking plan shit.

A couple of days ago, I had to turn down a job because the guy in charge was being too enthusiastic about MongoDB. He might like it, but it's going to be nothing but trouble for me in the future.

Oh, yeah. It's great for:

1. Fast application development.

2. When you just want a damn database without the fucking hassle of setting up a traditional database.

The problem is, you sacrifice a lot of valuable features of the Traditional database. Such as ACID compliance. Also, it is very very poor for data science. It's easy to make an entry into a NoSQL database and find an entry in that database, but if you want to use that database to crunch data, you are going to have a bad time.

Despite my rant I actually use MongoDB for some projects. The trick is to know when to use it.

NoSQL isn't a "complete game changer", OP. The "complete game changer" is the flood of hipsters crowding the industry.

These are hipsters who would rather their code read like a haiku than be efficient. We would call them script kiddies if it weren't for the fact that 90% of these kids are SJWs and would find any excuse to label you a "Databaseist".

Seriously, ask any of these Ruby jackasses to replicate Active Record by themselves and they would be completely lost. So, we can't expect them to make an educated decision when it comes to choosing a database, now can we?

Showing trends in NoSQL databases is kind of like showing what happens when you let a 5 year old choose between vegetables and ice cream. Yeah, we see a trend toward NoSQL because you put a fucking retard inside Willy Wonka's Chocolate Factory.

The best thing to do would be to join a project with experienced devs.

I have some open source projects with some entry level / low commitment work that might be good training for you. I'd be willing to mentor you in exchange for contribution.

It has nothing to do with Pebble, but I can get you started on some web stuff, or game engine stuff.

PM me if interested.

I get the sarcasm at the beginning of your rant, but towards the end it started to sound as if you were serious. If only because of this:

But seriously, branch names should...

Which is perhaps a naive opinion.

All names are meaningless. That's the nature of abstraction. It's not the name which is meaningful, but what it represents.

In the case of "master" it represents a generic identifier for the most important current branch. At any given time during the development process, this could be "alpha", "beta", "v.1.0.0" etc. Since these are arbitrary, we have "master" to denote the most important current branch. It's a standard which works because it's universally understood... Except, apparently, by you.

/ Get off my lawn! / Shakes fist at cloud. / End greybeard rant.

Why? Because nobody is innovating in PHP anymore. PHP's glory days were over well past a decade ago.

When you look at charts like the Tiobe Index What you are seeing are numbers held up by the language's past inertia. The only companies hiring for PHP devs are run by greybeards who can't learn a new trick and companies maintaining legacy software, like Word Press and PHPBB.

PHP was designed to replace PERL and it has succeeded in becoming obsolete along side it.

Upgrading a LAMP stack is kind of like upgrading Geocities. If you are going to bother, you might as well just tear everything down and start from scratch.

I was mostly joking about keeping it a secret. The truth of the matter is, it's too early to do much of any use with it and I'd rather wait until I can at least make a pong tutorial before I can expect other people to get excited about it.

You can take a look if you like. I'm actually OK with productive criticism.

The general idea behind it is, if you like the idea of Rails or Django for fast web development, you'll like the idea behind this framework for game development. I admit, purists will hate it, but that's OK. This isn't for purists.

I too am in the "Don't prematurely optimize" camp.

I'm building a Game Engine / Framework myself. When I work on it, I think to myself, "Maybe I should invite some people to try this out, get some different opinions". Then, I remember my inefficient code and my pride gets the better of me.

So, the project remains a secret between me and my therapist.

I guess the next step would be to gather pertinent information and POST it back to your machine.

But at that point, you are getting into dangerous territory. Expect Agent Smith to show up at your door.

I guess, if you are curious, here are some questions.

1. What is the nature of the environment? Chroot? LXC? Nothing?

2. Is the environment ephemeral?

3. Is the environment shared?

4. Is the executed code hosted inside the environment?

5. Can the environment be hijacked to return false positives?

6. Does the environment have a timed kill?

7. Can I hijack it to mine Bitcoin?

Good luck with that.

Learning the IF conditonal is a terrible idea if the programmer doesn't know where the whole idea of an IF statement comes from.

I'd agree with you if the guy was writing Kernels, or Drivers. But the world wont end if the guy holds off on learning Assembly for a few months. Nothing he is doing requires that skill. He can acquire that skill IF and WHEN he needs it.

I've had to clean up a lot of code because previous programmers knew how to do something, but not why you do it.

Don't hire a level 0 newbie to do level 9 work. If that's what you are doing, you have only yourself to blame.

Programmers that start at the top are the bane of my existence because they almost always are the ones that are the most confident and the ones that most need cleaning up after

Once again, Don't hire a level 0 newbie to do level 9 work. If that's what you are doing, you have only yourself to blame.

OP said he wants to learn Programming, he didn't specifically say he wants to learn Computer Science. There is a significant difference between the two professions. I'm just recommending Python because it's the easiest general purpose language.

The problem with the "starting low level" approach is that it requires a level of knowledge / skill / theory a newbie just does not have.

Assembly is archaic and a strong foundation of Computer Science theory is a prerequisite to understanding what is going on. Also the barrier to entry is high in that the student needs to learn how to use the tools first before he can actually start programming.

The idea with starting with Python is the student can learn what a IF statement is TODAY with minimal barrier to entry. These concepts are pretty much universal. If and when OP needs to move on to other languages, he can.

Learning low language concepts is a good goal, but it might not ever be necessary. Probably wont ever be necessary for 99% of developers. This is something that should be worked toward as a goal, not a starting point.

1. Drop ITT

2. Register for your community college's Python course instead.

3. Join the local programming meetup / club.

4. Start solving Project Euler problems.

Glancing at the Python API, the code is checked on the Codecha's servers, not the websites servers. So, you aren't going to be able to run arbitrary code on Amazon.com if they, hypothetically, decided to use this.

I imagine the checking done on Codecha's servers is done in a protected environment, such as chroot, or a Linux container. If not, then they will get exactly what they deserve.

Ever watch "The Office" Remember that asshole Toby? He was HR.

HR is always like:

"You can't say butt in the office."

"You can't come wandering in at 11:00 AM hung over."

"You can't flirt with that intern at the front desk"

"You can't have the CEO's chair."

"You can't have the CEO's office."

"Yes, Gary is gay. But, you can't call him fabulous."

"I already warned you not to fuck that intern at the front desk in the ass."

"No, it doesn't matter if you did it in the CEO's office, in his chair."

HR is the official corporate sandy vagina.

Install SSH server on the Linux VM. Most IDEs have a way to edit files over SSH.

You might even be able to mount the SSH connection as a file system. Although it's been a long time since I've used windows and can't remember if this is a native feature, or if you need to install a program to do this. I think it is a native feature.

That's fine, whatever floats your boat. I have a few problems with the "Top Down via UI" approach though.

The reason I don't draw things out is because I consider the UI "marketing". For the same reason you wouldn't make the package for the toothbrush before you design the actual toothbrush. I won't design the interface before the model.

The model is the product. The UI is just what marketers use to sell the product.

UI is a subjective thing while the model is objective. Put 3 guys in a room and have them approve the UI and they will be there for hours arguing. Put them in a room with a model and

1. They tend to think more rationally about what the NEED and less about what the WANT

2. They would rather get out of there because models are boring to pointy-haired-boss types.

Also, a project is likely to have multiple UIs, especially if it's a RESTful project. So, when I have a prototype of the model I just send the marketing guy the API and tell him to do what he wants with it. He can build a UI for web. He can build a UI for Android, etc.

Generally, I think UI should be considered separate projects in the same way designing a toothbrush is a separate project from designing a toothbrush package.

Another thought continuing from my last post.

Find people who use and value your tool and provide incentive for them to donate. For instance, poll you user base on features they'd like to have implemented. Then provide a bounty program in which they can donate towards this feature.

So, for instance, you find that a certain % of users want XYZ feature. (Making it open source, etc). You determine it is going to cost $ABC to pay a programmer to do this. When you talk to the people who use your tool about feature XYZ refer them to the donation page, which is kind of like kickstarter, showing how much is needed and how much has been donated.

My advice then, would be to find a business which uses / values this tool and ask them to sponsor your project.

• Either sponsor you with money to pay a developer.

• Or preferably, ask them to lend 10% of one of their developer's time to contributing on your project.

Just say something like, "I am happy that you are using my tool and would like to continue to develop it for your use. Can we talk about sponsorship?"

In this way, it is win-win for both you and the business which uses your tool.

I'm writing a library now, and I made the effort to change the former "Parent" / "Child" relationship in my objects to "Master" / "Slave", just so when the inevitable sandy vagina brings it up I can tell them to FUCK OFF.

Self-host your own gitlab server. I use it.

Giltlab has a CoC for contributers to that project, but they can't enforce anything hosted privately.

I'm more concerned with the Ruby code base than I am the CoC. I can ignore the CoC. The code base, on the other hand... It's like they say, "You can't fix stupid Ruby."

Generally, the most planning I do is to create the model first. So, I open MySQL Workbench (of alternate database equivalent) which has a diagram browser of the relational structure of the database.

This gives me a good idea of how to plan the project itself. Because 90% of the project is going to be determined by the structure of the model anyway.

After the model is created, often a scaffolding script can read the model and make a bare-bones prototype of how the program would roughly work.

I like this approach because the planning isn't just "mental masturbation" It actually creates a usable prototype which can be demonstrated.

TLDR: don't draw things out. Make a prototype of the model.

Finding people to do it is easy. Providing the incentive is the hard part.

Give me enough incentive and I'll gladly develop it for you.

People have been talking about F# lately. I guess I'll have to get off my ass and take a look at it.

That's the problem. Code that reads like haiku should be a low priority on an engineer's list of reasons to adopt a language for a project. Thankfully most engineers are also rational beings, for that reason Python is the more popular language.

Unfortunately, we get the occasional hipster in engineer's clothing. And thus Ruby.

I'll give you this though... At least you aren't a NodeJS guy.

Reasons to "Roll your own":

1. You want control of the framework's IP.

2. A sufficient framework does not exist in your target language.

3. You want a better understanding of engines.

4. The available framework costs money to licence. (And you don't want to pay)

Reasons not to "Roll your own":

1. It's faster to learn an already available framework.

2. You will probably have a framework with a lot of unknown bugs without a large community which uses it and reports bugs.

3. You can hire professionals who already know a popular framework.

4. When the next guy comes along he's going to have to learn a new obscure framework when it's probably better to just have him learn an existing framework with better documentation and community support.

Popular culture != programming.

Yeah, it has programmers in it, but generally we come here for discussion of programming, not what was on TV last night.

If a post is here on this sub it should have some code, or at least theory.

Your post was a valid discussion... for someplace else. It's kind of like all the conspiracy theorists spamming /v/news. It's like, "Yeah, we fucking know that you believe the Jews did 9/11, but just because some conspiracy blog says so doesn't mean it's news worthy".

So, yeah. I back the mod on this one.

void main(){
    while(true){
        if(pigs.can_fly()){
            print("Hello World");
        }
    }
}

It's still a great language, but for 99% of the applications being developed it is cumbersome. Just because you spend an exorbitant amount of time doing things modern languages have solved. Like garbage collection. I'd point to D as an example of a language which has potential to supplant it in those 99% cases.

But when it comes to things like Drivers, Kernels, Micro controllers, Life Support Systems, etc. Nothing can take the place of C.

Seriously, go to your local community college and sign up for their C class. You could learn it by yourself, and a lot of people here are going to give you some solid advice about doing that. Having access to a professor and a lab full of peers learning the same thing as you is a valuable resource.

If you are already comfortable with other languages, like Python, C shouldn't be much of a problem, language wise.

Learning C is 10% learning the language and 90% learning how to use the tools. Here's what you REALLY need to focus on:

1. Learn the tools. Specifically, the gcc tool chain. Specifically the debugger. Learn how to use these tools without an IDE.

2. Pointers are a bitch, but they are useful. Unlike Pyhon, you need to actually know how pointers work in C.

3. Learn how to safely allocate and deallocate memory.

4. Datastructures. Walls and Mirrors (book) is a good resource. But you should probably also take a class for this for guidance.

Also, take the "self teaching" advice everyone else is giving here. It too is valid.

MongoDB is the Ruby of databases. You don't use it because it's a good idea. You use it because you are a lazy hipster.

Like I said, if there is a good reason to break the rule, It's fine to do so. It's more of a way of being self conscious about good practices.

Your comment got me questioning myself to see if I actually follow this and how strictly I do so. So I did an analysis on a library I'm writing. The average lines of code in my project (per file) are 55. This is excluding "Wasted lines" like comments, and "Documentation" lines which can be collapsed by my editor.

At my resolution, I can see 51 lines of code at any time. So, I'm breaking the rule on average by 4 lines. But I think it's within the acceptable margin of error.

Then I did an analysis on the code base which uses the library. the average number of lines was 46. So, I would have to say the technique works, in practice, for the most part.

Another thing to realize is I'm using "D" a language with a lot of syntax sugar, so that helps. C is a bit more verbose and tends to require more lines to do the same job. For instance, the garbage collector pretty much makes the de constructor unnecessary;

Also I prefer putting my code blocks on the same line as the declaration, for instance:

void foo(){

as opposed to:

void foo()
{

so that also helps.

Any language which uses garbage collection is automatically out when it comes to mission critical systems. For instance, life support.

Why? Because part of the cleanup process is to briefly halt all threads while the collector does it's job. This is fine for most applications, like a word processor. But you don't want arbitrary garbage cleaning on your space station. Do that shit in a predictable way, like C does.

My general rule of thumb is: A class, or file containing related sets of code must fit on the screen without needing to scroll.

It's kind of arbitrary because a person with a 4k monitor is going to have more code than my 1080p screen. But the general reasoning behind it is, a function should do one job. If it takes up more than a few lines it is probably doing more than one job and should be broken up into multiple functions.

Likewise with classes. If a class can't fit on one screen without scrolling it probably is really more than one class and should be broken up.

Sometimes there are good reasons to ignore this rule and in such cases the rule should be ignored. It's more of a smart guideline. If your code takes up more than one page there should be alarms going off in your head telling you there likely is something wrong.

Let me guess... You are the pointy haired boss? No, you sound like a shrill fan boy. So, you must be the lazy college student who only ever learned Java.

D is still young.

We need better environments to attract D newbies. Or, we need a killer framework to attract specific industry (Like Rails is to web developers).

Using a text editor and cli also doesn't make you a better programmer.

I never claimed using a CLI makes you a better developer. What I'm saying is, we need a way to determine if Java AS A LANGUAGE is intrinsically better than some other language. Therefore, we need to get rid of the cruch Java developers rely on. Which is the IDE.

Then we can watch the Java monkey's futile attempts at creating library and then we realize that it's not the LANGUAGE that makes work easier, but the tools the IDE provides.

Then we can happily go back to work using the IDE but with the new wisdom admitting that "Writing a library in Java is easier" is just an old wives tale.

Writing a library in C++ is no more difficult than in Java. The difference, once again, isn't the language. It's the tools and the competency of the developer.

Tomorrow, ask the monkey in the cubicle next to you to create a library without his favorite IDE. Just give him notepad and a CLI. He will be outed for the magnificent fool he truly is.

(for instance maintainability, ease of development, deployment) Java wins by a fair amount.

All you are doing here is advocating for sub-par developers who are locked into specific tools. None of these things actually have anything to do with code base. All of these things generally require a non-langage tool. Like an IDE. So, you can't really credit Java as a language for any of these gains.

Basically, your argument is: "The tools for Java are made in the mindset that Java developers are lazy retards. The GCC tool chain assumes that programmers are competent and know how to do it themselves."

Which isn't a good way to describe Java developers. Basically, you'll attract the 2 kinds of people I described above. 1) The college student who never bothered to learn. 2) The Pointy Haired Boss.

C / C++ / D is going to outclass Java on every last metric you picked. (In the hands of a competent programmer). D isn't even what I would consider a mainstream mature language and it still makes Java look like the kid licking the windows in the back of the short bus.

Now, I'll agree with you about the scripting languages. Most people who are scripting are just as bad as Java developers. But that's kinda the point of scripting languages. It's a solution for retards.

People program in Java because that's the ball the monkey was given to play with.

Generally speaking it goes like this.

1) Programmer learned Java in college and never bothered to learn anything else.

2) Pointy Haired Boss looks at charts like this and sees Java at the top. Then hires people who only learned Java in College.

Nobody uses Java "Because it's a good choice". Because given any metric there is always going to be a better choice.

The way I see it is, hopefully people will put Objective-C related articles in that sub.

That way I don't have to be bothered with hipster languages clogging up my news feed.

Cool concept.

Just replace Ruby with a useful language and get rid of that awful soundtrack.

I've already warned OP against purists. If someone wants strict dogmatic OOP they should drag their sandy vagina over to Ruby and play with the script kiddies.

I mean, OOP is great. But it's not really a solution to a problem so much as syntax sugar.

Polymorphism and clever use of templates will solve those problems. I didn't mention it because OP's use case didn't require it.

If you are really interested, I'd look into Python and Ruby which have the somewhat ignorant philosophy of "Everything is an object". These are "opinionated" languages in that there is a "Python" way of doing things, or a "Ruby" way of doing things and they are both OOP heavy.

The problem is, they are not really "correct" in any sense. They are simply "opinionated" about the way things "should" be done and people who use these languages generally conform to the standard.

I tend to prefer Python myself. Python coders tend to understand that the "Everything is an object" philosopy is bullshit. Meanwhile, Rubyists have drank the coolaid.

Can you point me to a resource that explains and defines what the OOP way is?

Not really, most OOP languages are actually "Multi-Paradigm" languages. In that, the language supports "OOP", but also supports "procedural", "functional", and other common paradigms. So, now we are back to skinning cats. Which is fine, you shouldn't feel pressured into purely OOP programming styles.

The main thing here, and someone already said this. Be consistent in the way you program. If you choose OOP try not to mix it up with "functional" unless there is a good case for it.

It should also be noted that OOP (in compiled languages) doesn't give you any performance gain or loss. (Exception being virtual methods (usually). This is the rule with a few exceptions)

All OOP is, is a method to organize your code to be more manageable for YOU the human reading the code. That is all.

OOP is an illusion. It doesn't exist after it's been compiled. Keep this in mind.

the second snippets cater more to immutability

It could be. I'm not very familiar with C# and less so with F#. But I'm not sure he is correct if immutable works the same way in other languages. I'm assuming that if you are using the "point" object for a car, that "point" data is going to change as the car moves around the track. This would make it unsuitable for immutable data because immutable data isn't supposed to change.

But, I'll admit my ignorance, maybe C# and F# have this covered. I'm fairly sure that such a thing would not fly in C++ though.

As others have said, there isn't a "correct" way to do this... skinning cats and all.

but there IS an OOP way to do this.

My opinion is that the "distance_to" method should go in the "point" class. Why? Because the point of OOP is to marry data to the methods which manipulate that data.

This way, everyone knows that if you want to measure distance between two points the methods to do that are in the "point" class. (Where else would it be? the "Calculator" class? Why the fuck is it there?)

It also keeps code DRY.

A legitimate use case would be to reduce abstract concepts like a for loop into a symbol which universally represents a for loop.

Kind of like how we have symbols for radioactive waste and such.

For instance, read this I have a fairly good understanding of what is going on here without even read what the symbols are supposed to mean.

💭 is obviously a comment.

I believe 🌜🌛 indicates a container probably an array, list, or some datastructure.

🔃🚩 is the equivalent of saying while(flag){}

Would I use it? probably not. But if I were to want to program on an IOS or Android device, an emoji language might be more practical.

If you are asking these questions now, it probably means you don't have the background to really understand the significance of what I am about to tell you. The upside is, "Why" and "How" doesn't really matter. I don't reccommend worrying about the underlying mechanics just yet

But anyway, here are some pearls:

The difference is that C is a machine language and Python is an interpreted language.

The C compiler converts your C code into binary which your CPU can understand natively. It requires no interpreter. The benefit of this is the code is very efficient. But, you must compile a different binary for each architecture you want to support.

The Python interpreter, on the other hand, is compiled to "non-native byte code" (".pyc" files) which isn't architecture dependent. That code is executed inside of an interpreter which is similar to a virtual machine. Since it is the virtual machine which runs the instructions you don't need to compile for each architecture. However, the cost that there is a lot of overhead so python programs are much more CPU and memory intensive.

C and python are in no way similar. First of all, you don't need to compile Python. Just run the script. But first you need to do a few things.

step 1: Make sure your file has the "shebang" as it's first line. here is a sample "Hello World" program:

#! /usr/bin/python
print("Hello World")

step 2: make sure your file is executable:

chmod 777 ./filename.py

step 3: execute using

$ ./filename.py