Making some programming tutorials.

Great work , the presentation style was clear and concise . although i think the whole VM stuff was a bit of a mouthful especially if you're a newbie.
 
I don't have time to watch the whole thing, but a compressor effect filter would do the spoken audio wonders :)
 
I don't have time to watch the whole thing, but a compressor effect filter would do the spoken audio wonders :)

Yes, I should have recorded the audio separately and mixed it, rather than using my video capture software's sub-par audio recorder.
 
i must say you really have good presentation skills , there weren't any of those pauses (the aahs and umms) that you hear in other tuts.
 
Nice Video :thumbs:

I shall be tuning in next time :D
 
Nice job, some stuff though:

- The goal of a compiler is not to check code for errors but rather to turn high-level code into machine code (or bytecode in the case of Java). If the code contains errors, then the compiler often can't continue.
- Java is not slow. It's a label that it got in its early days and somehow it never got rid of it. It's not as finely grained as C/C++ in the sense that you get less control over your memory management (which has the benefit that there's much less hassle with that) but that doesn't make it "slow". I don't know for certain but I believe that in the early days of Java that the bytecode was interpreted instead of compiled into machine code like it is now. Today, Java programs are no slower than a program written in C/C++ other than the fact that it gives you less control over memory.
- From the video it wasn't clear why Java is able to run cross-platform. Perhaps that's because it's the first introduction, but it's not because it runs on a virtual machine, but rather because it's compiled into a universal intermediate language called bytecode instead of vendor-specific machine code, that the (vendor specific) virtual machine then compiles into the vendor specific machine code.
 
It really depends on the scale of the project . If you're programming a game with thousands of entities then you're probably going to see a substantial difference between languages that compile to native code and languages that are run on a virtual machine . multithreading goes a long way to deal with the issue but nothing really beats native code. having said that Java has come a long way, the official compiler has optimizers that boost things up and there are a number of native compilers for it. for me the most annoying thing about java and other languages like it is the fact that you have to install some kind of run time environment to use them which really hinders the mobility of your application. but i still think its an excellent choice for beginners because its based on the OOP programming style.
 
Awesome stuff! You speak very clearly!

:afro:
 
Nice job, some stuff though:

- The goal of a compiler is not to check code for errors but rather to turn high-level code into machine code (or bytecode in the case of Java). If the code contains errors, then the compiler often can't continue.
- Java is not slow. It's a label that it got in its early days and somehow it never got rid of it. It's not as finely grained as C/C++ in the sense that you get less control over your memory management (which has the benefit that there's much less hassle with that) but that doesn't make it "slow". I don't know for certain but I believe that in the early days of Java that the bytecode was interpreted instead of compiled into machine code like it is now. Today, Java programs are no slower than a program written in C/C++ other than the fact that it gives you less control over memory.
- From the video it wasn't clear why Java is able to run cross-platform. Perhaps that's because it's the first introduction, but it's not because it runs on a virtual machine, but rather because it's compiled into a universal intermediate language called bytecode instead of vendor-specific machine code, that the (vendor specific) virtual machine then compiles into the vendor specific machine code.

1. True, but I wanted to simplify things. Its useful for beginners to think of the compiler as an error-checker. In later tutorials I will go over bytecode and the virtual machine.

2. Java can be slower than C++ in many cases. I probably shouldn't have said "very slow" though.

3. I should have went over bytecode rather than talked about JVM. I will talk about that in a later tutorial.
 
I personally find the compiler a major source of error checking, especially in the case of C# and its case sensitivity, where my bugs are pretty much all logic errors rather than syntax errors.
 
Hehe, nice one. Wanted to shout at you for typing Class, but it turns out it was all a trick! Curse you!

I think you jumped into the actual programming a little too fast though, unless you intend to explain the theory behind it in the next video. Analogies always work nicely, try an analogy of a car for OOP. Like: a car is described by build plans (the class), the build plans can be turned into a working car (the object as the instance of a class) which has functions like drive and turn (methods) and members (door objects). This can also be used to explain inheritance.
 
Hehe, nice one. Wanted to shout at you for typing Class, but it turns out it was all a trick! Curse you!

I think you jumped into the actual programming a little too fast though, unless you intend to explain the theory behind it in the next video. Analogies always work nicely, try an analogy of a car for OOP. Like: a car is described by build plans (the class), the build plans can be turned into a working car (the object as the instance of a class) which has functions like drive and turn (methods) and members (door objects). This can also be used to explain inheritance.

Yep, I just wrote out an outline for my object lesson, and I used cars as examples.

"Let's say we have a class called Car. A car has wheels, it has seats, and it has doors, so we give it fields of class Wheel, Seat and Door. What can a car do? A car can drive, turn, and change gears, so we make the methods drive(), turn(), and changeGears(). Now, what is a car? A car is an Automobile. Automobiles have engines, and they can tun on and off. Now, we have a class called Truck. A Truck is not a car, but it is an Automobile. So, in programming terms, both Car and Truck are sub-classes of Automobile, and in Java terms, both extend Automobile. In Java, this means that both the Car and the Truck can use Automobile's methods turnOn() and turnOff(), and both have engines. However, the relationship between Car and Truck doesn't go any further than that. A Truck may have a special method, like openTailgate() that a Car can't use, and a Car may have a special method, like fillTrunk(), that a Truck may not use."
 
I'll definitely be keeping up with this.

Pretty interesting.
 
Thanks for these. I'm probably going to end up having to program in Java at uni, so this will come in very useful. I like the sneaky Portal reference in 3.1.
 
These are awesome. I'll be following them, because I feel like a complete n00b only knowing GameMaker's GML and some basic Python.

Does the main class have an instance of itself created automatically or something? Because I noiced that you had to create an instance of DemoMath to use its methods, but the main class exectued automatically.

And a method is just a function that's defined inside a class, right?
 
I've already seen C, but I am not acquainted with OO-languages. Very good tutorials, keep them coming :)
 
What a smoooooth voice. You could be a salesman.
 
These are awesome. I'll be following them, because I feel like a complete n00b only knowing GameMaker's GML and some basic Python.

Does the main class have an instance of itself created automatically or something? Because I noiced that you had to create an instance of DemoMath to use its methods, but the main class exectued automatically.

And a method is just a function that's defined inside a class, right?

The main class can have a constructor, but by default it initializes all of its fields to zero and null. The main class automatically calls its default constructor unless you specify another one.

Methods are functions. In C++ and many other languages, they are called functions because they don't explicitly have to be in a class. In Java, they are called methods because everything in Java must be inside a class. The term "function" can be misleading though, because they don't have to do the same thing as a mathematical function.
 
i'd like to see a toaster that is programmed in java. :naughty:
 
Dang, you're making these fast.

I once tried to learn Java but didn't make it very far. Maybe I will try again...
 
Okay so I'm starting to watch these beyond the first one now, and in the second one it really hit me just how similar the syntax in C# is with Java. I guess that's one of the areas they heavily drew from when they said a large part of it is based off Java.

I was thinking, wtf, this is exactly like C#! Other than the screen printing method of course.
 
Okay so I'm starting to watch these beyond the first one now, and in the second one it really hit me just how similar the syntax in C# is with Java. I guess that's one of the areas they heavily drew from when they said a large part of it is based off Java.

I was thinking, wtf, this is exactly like C#! Other than the screen printing method of course.

Java syntax is almost identical to C# in every way. Learning either if you know the other will be extremely easy.
 
That's very refreshing.

When I look at Visual Basic code, it really pisses me off because I have things called "dim" and "sub" and it's like... okay, those are really weird naming schemes. And I don't like the syntax at all.
 
You're a much better teacher than my Java teacher was back when I took a class in college. Stuff actually makes sense!
 
Now that it looks like the syntax is exactly the same as C#, I really want to see the source code for theotherguy's space game!
 
Java syntax is almost identical to C# in every way. Learning either if you know the other will be extremely easy.

Syntax: yes.

Programming conventions: not as much.

I've been using C# professionally for a couple of weeks now, and when I started a guy told me "forget everything you know about Java" and he's completely right. Syntactically, it's very similar although I think C# has Java easily beat:
- It has ref and out for multiple return values.
- Properties instead of methods for getters and setters (which turns the Java obj.setValue(e.getValue() + 1) into obj.Value = e.Value + 1, much more natural and readable, with all the functionality of a method).
- Everything inherits from the baseclass Object: there are no primitives, just a distinction between value types and object types
- It supports struct as a sort of lightweight "class"
- It has delegate for wrapping methods
- Has an unsafe keyword which you can use to program with pointers and stuff
- Operator overloading
- You can access any collection as if it were an array, so list[index] instead of list.get(index)

But for writing a console application, this isn't hard to learn. The biggest difference is in the libraries, .NET is nothing like the standard Java library. Building a Swing application is completely different from building a Windows Forms application. The event model in C# is very different (and better) from Java. There is also no such thing as databinding in Java as far as I know. For building an application, you really do need to forget everything about Java except the syntax that you already know, but syntax is easy to learn.

All in all, I must say I easily prefer C# and the .NET framework over Java, it seems like it's a language that has learned from Java. Just a shame I don't like Visual Studio compared to Eclipse.
 
Syntax: yes.

Programming conventions: not as much.

I've been using C# professionally for a couple of weeks now, and when I started a guy told me "forget everything you know about Java" and he's completely right. Syntactically, it's very similar although I think C# has Java easily beat:
- It has ref and out for multiple return values.
- Properties instead of methods for getters and setters (which turns the Java obj.setValue(e.getValue() + 1) into obj.Value = e.Value + 1, much more natural and readable, with all the functionality of a method).
- Everything inherits from the baseclass Object: there are no primitives, just a distinction between value types and object types
- It supports struct as a sort of lightweight "class"
- It has delegate for wrapping methods
- Has an unsafe keyword which you can use to program with pointers and stuff
- Operator overloading
- You can access any collection as if it were an array, so list[index] instead of list.get(index)

But for writing a console application, this isn't hard to learn. The biggest difference is in the libraries, .NET is nothing like the standard Java library. Building a Swing application is completely different from building a Windows Forms application. The event model in C# is very different (and better) from Java. There is also no such thing as databinding in Java as far as I know. For building an application, you really do need to forget everything about Java except the syntax that you already know, but syntax is easy to learn.

All in all, I must say I easily prefer C# and the .NET framework over Java, it seems like it's a language that has learned from Java. Just a shame I don't like Visual Studio compared to Eclipse.

Sounds very appealing. I might dabble in C# sometime before I take the actual C class in college.
 
Syntax: yes.

Programming conventions: not as much.

I've been using C# professionally for a couple of weeks now, and when I started a guy told me "forget everything you know about Java" and he's completely right. Syntactically, it's very similar although I think C# has Java easily beat:
- It has ref and out for multiple return values.
- Properties instead of methods for getters and setters (which turns the Java obj.setValue(e.getValue() + 1) into obj.Value = e.Value + 1, much more natural and readable, with all the functionality of a method).
- Everything inherits from the baseclass Object: there are no primitives, just a distinction between value types and object types
- It supports struct as a sort of lightweight "class"
- It has delegate for wrapping methods
- Has an unsafe keyword which you can use to program with pointers and stuff
- Operator overloading
- You can access any collection as if it were an array, so list[index] instead of list.get(index)

But for writing a console application, this isn't hard to learn. The biggest difference is in the libraries, .NET is nothing like the standard Java library. Building a Swing application is completely different from building a Windows Forms application. The event model in C# is very different (and better) from Java. There is also no such thing as databinding in Java as far as I know. For building an application, you really do need to forget everything about Java except the syntax that you already know, but syntax is easy to learn.

All in all, I must say I easily prefer C# and the .NET framework over Java, it seems like it's a language that has learned from Java. Just a shame I don't like Visual Studio compared to Eclipse.

Good to hear you into C#(I didn't read your entire post... I won't be able to do that until I put my glasses on...). I mention it because I vaguely remember you knocking on C# not too long ago, so it's great to see such a turnaround.

I also could be remembering false things. I just woke up and am going to lay back down, so maybe I'm wrong.
 
Good to hear you into C#(I didn't read your entire post... I won't be able to do that until I put my glasses on...). I mention it because I vaguely remember you knocking on C# not too long ago, so it's great to see such a turnaround.

I also could be remembering false things. I just woke up and am going to lay back down, so maybe I'm wrong.

You remember wrongly :p

The only things I dislike about C# is how it's a Java ripoff, which I don't mind except that it's trying to pretend it isn't sometimes. Like arbitrary renaming of classes just to make them different, it's like they went "wait, we can't name the internationalization class "Locale", that's what Java is calling it, lets call it "CultureInfo"!" Same for StringBuilder, aka StringBuffer. Don't try to be different, just be proud of what you steal!

I also dislike that you're pretty much tied to Visual Studio and Windows. Visual Studio sucks for actual code writing compared to Eclipse or even Netbeans, but for project management and form design it's OK.
 
Sorry, for some reason that was sticking in my head.

Anyways, what don't you like about Visual Studio?

And you're not bound to them, there are others out there.
 
Sorry, for some reason that was sticking in my head.

Anyways, what don't you like about Visual Studio?

And you're not bound to them, there are others out there.

Its actual code editing is shit. Debugging, project management, designing etc is all fine, but writing code is a pain compared to Eclipse.

It doesn't do any background compilation to check for errors like Eclipse and Netbeans (and I thought any self-respecting IDE) do. VS doesn't say anything about assigning a string to an int, or using too few arguments in a method, until compile time. This is annoying when you're used to it, but gets really annoying when you're building some huge project only to discover after a 10 second compilation that little syntax errors crept in. Tell me about syntax errors when I make them!

It's autocomplete is annoying, for example, say you have this piece of code:

Code:
DoSomething(obj);

But you decide you wanna wrap DoSomething with DoSomethingElse to get DoSomethingElse(DoSomething(obj)), and you place your carrot right in front of DoSomething, then type DoSom, then hit ctrl+space and select DoSomethingElse as your method to insert. When it's inserted, Intellisense thinks it's being smart but in reality it's being shit-for-brains retarded because it replaces DoSomething with DoSomethingElse. I did not want that! You have to insert a space before a method if you wanna insert another autocomplete method in front of it.

It doesn't autocomplete brackets and parentheses.

If you place your cursor on a variable or method, Eclipse puts markers in the bar on the left to designate where in the file that method or variable is being used, VS does no such thing. You gotta use Find All References, which doesn't work nearly as elegant as in Eclipse.

Refactoring is also more effective in Eclipse. VisualStudio isn't too bright with refactoring. Case in point: I declared a StringBuilder called sb, on compile (oh hai, a little late no?) I got the message that there was already a StatusBusy object called sb which I didn't know about. OK, fair enough, I rename the StringBuilder object to builder, say to VS that it must refactor it and I compile again. Now, I have like 10 errors (hai, late again I see?). What happened? VS also refactored the StatusBusy object, which wasn't even in the same scope! Eclipse just renames the local variable of the StringBuilder class and leaves anything outside of the scope untouched. But the least thing that VS could do is look at the type of what it's refactoring. If the things it's refactoring consist of more than one type, something went wrong!

There's some cool stuff it has, like a button to comment selected lines of code, but while Eclipse doesn't have it, it takes literally 10 seconds to create a macro that does the same thing (honestly, I never used the tool but I got a working 'surround selected code' macro for comments in 10 seconds). Eclipse is a more powerful IDE if you wanna do, you know, programming. VS is more powerful if you wanna drag and drop shit.

Also, where's my option to display line numbers in VS? Can't find it! How's that not an essential part of an IDE?

EDIT: Ah, found it, but why is it not on by default?
 
Back
Top