Two down, n to go...

Posted by Astryl on March 3, 2012, 1:13 a.m.

I've officially got another two programming languages under my belt. C# and LUA. And by officially I imply that I can do something useful with them, not that I have a piece of expensive paper saying I know them. ;3

I'm running a test for myself this week to see if I can make a simple program the performs a basic database-like function in all the languages I profess to know. I want to see if I'm still remembering some of my earlier languages. The list is here:

> C (ANSI standards)

> BASIC (I'm going to hate myself later)

> Pascal (And Delphi)

> Java

> C++

> Assembly (x86)

> Python

> PHP (CLI, probably)

> Java ME (Mobile. Why not :3)

> Lua (In ComputerCraft 1.3 for teh lulz)

Not a bad list if I do say so myself. I left some obviously useless-in-this-situation languages out. Like ARM7 Assembly. Also, I dropped COBOL (May it burn forever).

Anyway, now that I have studied both C++ and Java in whole, I can see the use and potential of C#. It's a beautiful language, but if it wasn't for MONO I wouldn't even be considering it (I hate non-portable languages).

XNA was my motivation for learning C#, but I see it's usefulness in a variety of other areas too (Custom content tools, especially).

And now that I've gotten over my prejudices, I have a new opinion on the Eternal Language War. It shouldn't exist. Each language has it's strong points:

> C - ROM/Integrated Systems development sans Assembly

> Assembly (X86) - Kernel and Driver programming

> Assembly (ARM7) - GBA and DS programming (ARM9 as well)

> C# - Windows GUI and Game Development with XNA

> C++ - Heavy console/PC game development.

Development of complicated service applications for

Windows and Linux.

> Java - Highly portable GUI/Service/Game development.

> PHP - Web development, of course.

> Python - Rapid Algorithm Prototyping

Tool development

Integrated scripting

> LUA - Scripting language for a multitude of programs

JavaScript - Ditto

> Pascal/Delphi - OK… I have to admit, this one isn't really

necessary.

> BASIC - Not recommended anymore, but still useful in some

areas (Basic256 in schools has been used for real-time

math graphing)

> Visual Basic - KILL IT WITH FIRE [/nonPrejudiced]

Now my current project is to figure out the applications of an Object Orientated system on a web-site (Such as this) and whether it makes things easier to understand/use or if it just syntactically sugar-coats everything into an unreadable/unmantainable mass of spaghetti.

This is, naturally, being done in PHP. And on my local test-server.

And as always, it's all very well to go and make good looking code, but it must be efficient in the end. Because we don't want to wait 10 seconds for the site to load.

On the design of programs

In retrospect, I began programming in the PASCAL language; specifically Turbo Pascal 5.5, the same variation that Notch began with.

Now, and you've heard it before, I learnt the basics of the language by touch-and-feel. I had no documentation, just the example source code (Which was more or less well commented) and ambition.

Naturally, considering the fact that TP5.5 wasn't really an Object Orientated Language, I ended up becoming a Brute Force Top-Down Designer.

Actually, TP5.5 had some supposed 'OOP' thrown in, but it was poorly implemented. That was because of Borland trying to compete with Microsoft at the time for the "King of the Compiler" award. Microsoft won.

This meant that I'd try to create my entire program in one go: I'd create or include every possible header file I could think of (UNITS in Pascal),

try to define every possible data structure I might want to use, and then try to make all the functions I'd need before writing the Mainline (The main Begin: End; block in Pascal).

So it's no wonder that my old Turbo Pascal folder is full of incompleted programs. (I still have it on disc somewhere).

Then, to help matters somewhat, I got my hands on the excellent "Mastering C" by somebody-or-other. Can't remember that far back, but I remember the amusing first chapter about design. (I think the name of the author was Charles Franklin. I'll have to check up on that).

The design process offered in this book was the top-down method based on Stepwise refinement (And the careful layout of your design on paper first).

This meant a slight increase in the number of finished programs (Though my discovery of the Super Nintendo Emulator ZSNESW kinda had a lot to do with my lack of development).

Anyway, the thing to note about these design methods is that they're strictly procedural. And useless. My 'modern' design course that I took (And passed with 92% average because they didn't like some of my 'opinionated' answers) was so focused on "Getting your design onto paper first", and so vehement that this was the only way, that I decided to try it…

… And nearly drove myself to giving up on programming forever.

Fortunately for me, I then gained full access to the internet, and it's gigabytes of information related to the topic.

And the conclusion is: There is no perfect way to design a non-static program. That is, a program dealing with dynamic types and data cannot be safely boxed by a fixed design document. Bruce Eckel mentions in his books the concept of the design "Wild Card". Bits of a program whose functions are indeterminate until most of the coding is done, or in the case of a script interpreter: Indeterminate until runtime.

I find that the best way in a real-life situation is to sit down, type out a short design document stating what the program is going to have to do. If there are any major elements, list them.

Then design as you go. When encountering a large and imposing block of code that you must write, think it through, type out an overview in comments, and code away.

Some things don't require designing (I've lost count of the number of times I've written the standard int main(int argc, char** argv) line in C++, but my design course dictates that I MUST WRITE EVERYTHING DOWN TROLOLOL, even the simple shift_xr function that I used for some lightweight file packing once (It does this: return i >> 4)). In other cases, and especially with game development, I can't determine the behavior of an object until halfway through the project, so I just give it a basic behavior and leave the rest until later.

Why did I write this? Simple. I want you CS graduates/students to start hammering my poor head with your infinite wisdom gained from years of intense study; correct my grievous mistakes, oh trained ones.

Meanwhile, Imma keep finishing my programs and getting somewhere with my projects on my own system. :3

But seriously, correct me if you see the opportunity. It's the only way I learn.

This week in games

I bought (and downloaded) Dark Void Zero this week. Overall a challenging game, but in the end it felt like the sort of game that any of us could have made (Or at least, I feel I could have) in a relatively short amount of time.

And then, after looking at the Indie category on Steam for a while, I experienced a lightbulb-appearing-over-the-head moment: I can do better than some of these, and match the rest. Or at least die a horrible internet-based death trying…

So now, armed with my newly acquired and pretty much fresh C# skills, a prior knowledge of the XNA framework, and a massive raft of ideas, I'm going to attempt to create a game that will be accepted by Valve this year. And if not this year, the year after. Worth a shot, in my opinion.

Otherwise, I've been playing a lot of Minecraft this week (The 1.2 Point releases, as well as 1.1 kitted out with some mods).

There are no words to describe jumping off your super-skyscraper tower that has a hole extending all the way to the bedrock. Currently though, the bedrock and Steve are having a disagreement as to whether his limbs should stay in place afterwards or not. Next thing I'm building down there is an End Portal (I'll need Silk Touch. I'm playing in Survival mode).

Also, ComputerCraft. If you haven't heard of it already…

It's a fully functional computer/disk-drive/modem/turtle-bot combo for Minecraft and is fully programmable. Oh, and it's SMP compatible. <3

And it's the primary reason I decided to learn LUA.

Oh, and it has an http API. Only one minor problem: It's currently an ASCII only terminal (With Coloring though, so it's not too bad).

But the idea of accessing 64digits and posting through a LYNX like browser is oddly amusing.

Currently in development

I'm in serious-programming mode, where I'm busy making 'serious' programs and not making games. By tomorrow I should be in Music mode again, and the the cycle will reset. That game I'm working on has a few new weapons coded in (Shuriken and Throwing Axe I think) and two extra enemies drawn, but I don't know how far I'm going to get at the moment.

Anyway, I'll be signing off. I see it's the 3rd of March… Hmm…

*stalks off to Youtube with hands behind back*

Comments

Josea 12 years, 8 months ago

Quote:
HTML 5 isn't a language, it's markup. You still have to use JavaScript to do anything with it.
It is a language, what you meant is that it is not powerful enough to write programs in the usual meaning of the word.

firestormx 12 years, 8 months ago

What you mean is it's not a programming language, it's a markup language.