Eh, yeah. That's not really how that works for most people. High level languages, especially those with garbage collectors, are generally considered more productive and are generally more popular. Not to put any value in it, everyone should use what they feel most comfortable and productive with, but you are not describing reality.

Why do you consider it important to teach CPU architecture to new programmers?

But actually, our opinions aren't equally valid. Through scientific studies it would (theoretically) be possible to determine the superior approach. But since we don't have access to such science our arguments are pretty much equally nonsense/arbitrary

And most Android-based phones/tables, unfortunately. Most mobile platforms are locked down shit.

But at least the Android OS itself is free, so the producers that aren't idiots will allow you to install your own OS (CyanogenMod in my case)

If you're going to pick another language on the side, it's far more useful to learn a lower / assembly language, as that will make you truly understand how a CPU works ( and what the Pascal you're writing actually gets translated / compiled to ).

If you're going to pick another language on the side, it's far more useful to learn a high level language. It will teach you the actual craft of modern programming, keep things fun and you'll learn to optimize with regard to functionality/readability over pre-optimizing-bit-fiddiling.

Or that is at least a strong counter-argument, in my opinion

That being said, bit fiddling can be incredibly fun. So a better piece of advice may be: Do what's fun for you!

The fact that you have few static methods is very good. You should almost never use them, I only used one to simplify my example. You shouldn't do the same thing.

If you are creating lots of 3D-model-classes you can do something like this:

Code:

class MyModel {
   Object1 [] usefullshit1;
   Object2 [] usefullshit2;
  
   MyModel(Object1[] mesh, Object2[] waste) {
      //convert all the mesh and waste into useful shit
   }

...

public static void main(String[] args) {
   ...
   while(something) {
      Object1[] mesh = LoadMeshData();
      Object2[] waste = LoadWasteData();
      modelList.add(new MyModel(mesh, waste));
   }
   ...
}

At the end of this all the mesh and waste objects will be removed by the GC (as you don't hold on to them). But the MyModel objects are stored in the list so they remain, including the usefullshit1 and usefulshit2 arrays.

It's a bit rude of them to assume that only MS-OSes are safe (when it's usually the opposite). But the main problem only remains for ARM.

Microsoft also requires that manufacturers offer the ability to turn off the secure boot feature on x86 hardware, but they must not offer such an option on ARM hardware.

Not sure what you're trying to do. You should probably start a thread where people can help you with your Java-problems.

But is MyClass a static class, a singleton or will there be multiple instances of it? There are better ways of doing what you're doing either way.

The HP-red and background-grey melt together for some reason. You should probably adjust one of those colours.

There is almost never any need to explicitly set anything to null. The GC doesn't need to be coaxed into doing stuff, it automatically cleans things up for you. All local references are automatically dropped when the current method finishes running. And if you replace a reference with another reference the first reference is lost and the GC will clean up the hanging object (unless there are any remaining references to it somewhere else).

You should probably try to read similar Java code written by someone else, in order to learn some idioms.

It behaves just like primitive variables:

Code:

void static someFunction() {
   int x = 5;
   HugeObject obj = new HugeObject();
   ...  
}
// end of scope, so references x and obj are dropped

Note that obj was the only reference to the new HugeObject we created. So now that specific HugeObject instance is unreachable from our code. As a result the GC will remove it from memory at some point.

Dependency injection can be practical. But it isn't magic, so you should know that some things may become unwieldy. Here is a simple Java example, loosely based on my own code.

Big constructor:

Code:

QuestionPanel(EventBus eventBus, QuestionMetadata questions, UITexts uiTexts, String questionID) {

So every time you want to create a QuestionPanel you would have to inject lots of arguments:

Code:

new QuestionPanel(eventBus, questions, uiTexts, questionID)

This can be handled by having a factory that keeps track of all the things that are the same every time (singletons, mostly). The factory can be an inner class of QuestionPanel, at least in Java.

Code:

public class QuestionPanel {
public static class QuestionPanelFactory {
EventBus eventBus;
QuestionMetadata questions;
UITexts uiTexts;

protected QuestionPanelFactory(EventBus eventBus, QuestionMetadata questions, UITexts uiTexts) {
this.eventBus = eventBus;
this.questions = questions;
this.uiTexts = uiTexts;
}

public QuestionPanel create(String questionID) {
return new QuestionPanel(eventBus, questions, uiTexts, questionID);
}
}


QuestionPanel(EventBus eventBus, QuestionMetadata questions, UITexts uiTexts, String questionID) {
....
}

So I only have create the factory once. It can be used as a singleton, injected into classes that need to generate new QuestionPanels.

Code:

QuestionPanelFactory factorySingleton = new QuestionPanelFactory(eventBus, questions, uiTexts);


//Use instead of new:
questionPanelFactory.create(someQuestionID);

So now you have lots of extra boilerplate instead. You have to decide if it's worth it.

I have to use it, though. In order to get my auto-injection system to work (the GWT version of Guice, called Gin)

It does look a bit stuttery. Perhaps you should try to imagine how a ball like that would move in real life. It would contract and expand in order to move forward. Simple real-life comparisons could be a bouncing ball or jumping on one leg.

But maybe you should start a separate thread where you work on refining it. This is a bragging thread, rather than a feedback thread, after all

It's actually a decent choice if you want to teach fairly low-level programming. C can get a bit messy in comparison.

Personally, I think it'd be better to start with a higher level language (for example Python). But opinions differ.

Don't worry about it, you'll be able to pick up C# or JavaScript if you need to. It's just that schools should stay away from languages that "belong" to specific interests. Making C# problematic (and Java as well¹ ²).

1. Apparently OpenJDK (GPL2) is the reference implementation for Java7. So Java isn't all that bad since Java7.
2. Apparently the Java Test Compatibility Kit is Oracle-proprietary and they are being complete dicks about it. So Java does indeed have serious problems due to its ties to Oracle.

A related design pattern is dependency injection.

The idea is to give each new object/class the things it depends on, usually as a constructor argument. So instead of using MySingletonClass.getInstance() from inside the constructor, you do something like:

Code:

MySingletonClass singleton = MySingletonClass.getInstance();
DependsOnMySingletonClass dependant = new DependsOnMySingletonClass(singleton);

The benefit being that it's even more decoupled. So when you are unit-testing DependsOnMySingletonClass you can "inject" a mock-version of MySingletonClass.

Dependency injection can be done completely manually. But there are also frameworks that automate it and figure out in which order things need to be initialized and where they should be injected.

(I'm not sure how well it works for games, though. I haven't written a proper game since I started using dependency injection for my other projects.)

Yes. See it as a "most improved"-list, until next update

@zalzane:
Hm, I guess it's a matter of definition (and Wikipedia agrees with yours). Bytecode does fall in its own category.

However, Java/C# have to be compiled by a compiler before you can run them, so I find it less confusing to call them compiled languages.

bytecode is literally machine code. It's just read by a virtual machine rather than a physical machine, but it's still machine code.

I finally reached Level 3, with 75 problems solved!



I celebrated by updating the high score list in the first post. I added a few people and sorted everyone based on problems solved.

I had to use it in a university course and I really didn't like it. It's designed to teach good coding habits, but some of the habits it teaches are actually quite bad. For example, it forces you to declare all your variable up top.

However, when learning programming the language you use isn't that important. The important concepts will easily translate to other languages.

(C# would be the truly horrible choice. It's a Microsoft language with a proprietary Windows-only reference implementation. As such it has no place in academia, open source or in any serious context, really.)

Ah, good. I just wanted to make sure you knew how implausible the game (currently) is. Creating MMOs and realistic games will indeed become easier with time, but probably not easy for a very long time.

If you start small you may be able to explore some of the concepts and learn to refine them. You can keep adding details over time, eventually getting something really immersive. Dwarf Fortress is a good example of this; it is probably the most detailed game in existence (game-wise, not graphics-wise, mind you) and it's a 1-2 person project.

What you could do is to settle with fairly primitive graphics and animation and focus on refining the game-play elements. If you can make the game fun even without fancy graphics/animation/controls you'll know you are on the right path. Adding amazing visuals and animation can be a future project, once you have all the complex interactions in place.

But if you want to live on the bleeding edge of graphics/animation instead, you could try to pair up with some programmers and work on something limited. For example creating a monster-animation-system similar to Spore, but better.