Flutterby™! : A possibly distributed project? 2004-01-27 22:30:26.425066+00

A possibly distributed project?

2004-01-27 22:30:26.425066+00 by Dan Lyke 10 comments

I was browsing /. and ran across this question about "A Modern Day '101 Basic Computer Games'?", which had a link to an online version 101 BASIC Computer Games and a comment pointing to an online version of More BASIC Computer Games. The younger rat boy has been asking about programming recently, maybe it's time to do an updated version in Perl?

#Comment Re: A possibly distributed project? made: 2004-01-27 22:54:11.793234+00 by: aiworks

But isn't Java the modern day "learning" language? There is a *ton* of programming tutorials that are based around Java (far more than anything else it seems) including college curricula.

Plus, Java gives you some interesting possibilities for graphics that won't involve too much programming (provided you don't care too much about doing it right).

#Comment Re: A possibly distributed project? made: 2004-01-27 23:06:34.14744+00 by: markd

I dunno if I'd want to have Java as my first programming experience ever. There's a lot of intellectual overhead involved with Java. Things we take for granted, like importing stuff, subclassing, system.out.println, CLASSPATH, etc. The great thing with BASIC and this book (which I loved. It took some work getting things to operate in AppleSoft BASIC) way back then was that it was really easy and fast to Get Stuff Going. I'd bet perl+tk would be a faster learning curve for a youngster than Java+swing.

#Comment Re: A possibly distributed project? made: 2004-01-28 00:08:32.641367+00 by: dws

As a die-hard Perl hacker, I'd recommend Python as a learning language. There's not a large cliff to climb at the beginning of the learning curve (like there is with Java), the feedback loop is very short (unlike Java), and what you learn gives you a solid start if/when you transition to other languages (like Java, Perl, C++).

Or, if you're teaching someone who's visually oriented, consider Squeak Smalltalk. The tools, plus plenty of examples, are all there for doing graphics.

#Comment Re: A possibly distributed project? made: 2004-01-28 00:11:32.15188+00 by: Dan Lyke [edit history]

The local high school uses C++, but my reason for suggesting Perl

is that by its nature it's designed to be learned incrementally. Part of the joy of BASIC

was being able to type PRINT "HELLO!", mashing <enter>, and seeing results. And Perl

means I don't have to start out with explaining variable typing, and with effort I can even stop my fingers from typing in use warnings; use strict; and let 'em use variables without declarations.

But perhaps most importantly, it's that Perl

still has its roots back in the days of 80 column wide fixed width font terminals, thus a lot of the concepts from BASIC port right over.

There's also just the hassle of getting Java

installed and running, and that whole "this is a reference, that's a variable" issue that the Java

and C# style languages trip people up with.

Mark D.: I'd choose gtk2-perl over Perl/Tk

: Uses glade-2 for layout design, no canvas, but the drawing area widget lets you deal with the paint event explicitly, which makes a bit of the graphics stuff easier to comprehend.

Later: Hmmmm... Hadn't thought about Python, mainly because it's a language I haven't bothered to learn yet.

#Comment Re: A possibly distributed project? made: 2004-01-28 05:25:10.210538+00 by: Diane Reese [edit history]

Our kids' high school's first programming course starts with a flavor of Scheme, and moves to Java. The progression used to move to C++, but the AP Comp Sci exam now expects Java as the language skill, rather than C++ (starting this year), so they have to teach Java.

#Comment Re: A possibly distributed project? made: 2004-01-28 15:03:13.424935+00 by: meuon [edit history]

Dan, I think Perl is an EXCELLENT first language, you are right, it's incremental. Let him play in text mode.. add tcl.. and then he can go to other languages with some basic skills and hubris. It'll help the frustration he'll find with more complex languages. Java is daunting, and so 'wide' right off the bat it's easy to get lost in. I have not written any, but I've debugged a bunch of other people's dreck, especially jsp's. And.. for a beginner, using the command LONG naming scheme for variables and functions in Java is daunting. He'll spend lots of time debugging typo's instead of learning if/case/switch/while...

I'm re-doing a Java/jsp/MySQL project for a former competitor's customer in PHP/MySQL.. I've never seen a buggier web project, I'm sure the coder was taught these tools at a school, it's very structured, but the complexity of the system, for something that does very simple things, is insane. I think the problem is teachers have seldom done real world projects in these languages. And getting the Tomcat and Jakarta error pages on top of the errors in the jsp code and SQL is insane. It's taken under 1000 lines of code plus some included html pages in PHP, it'd be about the same in perl. The only errors I've seen have been from my mistakes, and have been easy to debug.

Python would be my other choice for him, from what little I have seen. But if he learns Perl with the right mindset, he'll become language agnostic. Good coding techniques and thought processes are far more important than the language you apply them to.

And a disclaimer: I'm a shitty lazy programmer, but my stuff works and I can make a living at it..

#Comment Re: A possibly distributed project? made: 2004-01-28 16:50:48.778621+00 by: flushy [edit history]

Mike, you're not a bad programmer. You're not a very structured programmer (at least from what I remember), but you're not bad. You get things done, but in the past the way you get things done didn't normally leave any avenues for future expansion. To expand you had to rewrite entire portions of code.

For projects where you write once and forget about, this technique delivers a product very quickly and with efficient code. However, in projects where you write once, return and write again, then return and write again, update, remove, and write again... the technique tends to create programs that become unwieldy and complex.

Most projects I start, I begin with your techinque in order to test certain theories I have about how things should work. As the project grows, I find that those test blocks turn into modules, which in turn integrate with an API, which in turn define a structure that makes is much easier to add and remove functionality. Sometimes the API isn't something that I have thought about before hand, but in the process of design, I learn what I need for the API and what I don't. At some point in your project you either plan for growth, or you end up "programming yourself into a box." I've been apart of many projects (some of my own design), where the programmer has done just that. The growth of the project is halted. It just cannot go any further, because of the way it has grown. Then you retro-fit it the way you should have 3 or 4 revisions ago, and feel like you're starting over.

With your PHP/MySQL project, I highly recommend using php::smarty (http://smarty.php.net). This will divide your project into two parts. One being the functionality/code/calculation/whatever-you-want-to-call-it. The other being design and display. You can change one without changing the other. In fact, you can at some point delegate control for one while ensuring stability of the other.

Also, you may also want to consider replacing your typical mysql_query/mysql_connect/mysql_fetch commands, with universal commands (much like the way perl's DBI module does). This will ensure portability at some point when you want to change SQL servers (or perhaps a completely different version which changes function calls). Instead of mysql_fetch*, you'd use sql_fetch*. Your require "mysql.php" file would contain the functions that translate sql_fetch* to mysql_fetch. An interesting side-note, you can also include a function for your queries that automatically adds slashes and quotes your variables, so your sql doesn't break based on user input.

Another thing I have enjoyed with this technique, is having two fuctions for queries - one for read queries and one for write queries. In this way, I can use MySQL replication to have one write server, and multiple read servers. Thus all my read queries perform really, really fast, while my write queries perform normally by connecting to the main SQL server.

By taking this to another lvl, you could conceivably, add code to this "mysql.php" module, that "knows" when certain SQL servers have gone offline, and redirects queries to other machines.


require "global.php";

require "sql.php";

require "smartyinclude.php";


sql_connect_ro();

$res=sql_query_ro("select * from mytable where id=?",$_GET['id']);

$data=sql_read_assoc($res);

if (count($data) == 0) errexit("Unable to read any records");

$smarty->assign('sqlinfo',$data[0]);

$smarty->display('index.html');

#Comment Re: A possibly distributed project? made: 2004-01-28 17:01:44.57567+00 by: other_todd

I learned computing from that book, Dan; your post brings back fond memories for me. In fact I've probably still got it around somewhere as an artifact; I doubt if I could bring myself to throw it out. I had a variety of computers running BASIC, notably a TI 99/4 where, after the struggle to adapt the programs to its peculiar flavor of BASIC, I would then use its sprite-based graphics to jazz up the programs. This turned out to be something fairly useful to do ... and, then as now, games really are the only kind of programming that fully interests me, so it's good I started with something I'd actually persevere at :)

I'm with you on the idea of Perl as an incremental language, although there will always be people who are bothered by Perl's "more than enough rope to hang yourself" flexibility, weak typing, autocasting, etc (the things I LIKE about it) and would therefore say it is unfit to be a learning language. Feh.

But the big problem with bringing those BASIC games into the modern era is that they are just not snazzy enough. Text printouts don't cut it anymore, not in a day when even the more retarded of our digital devices can show pretty pictures. A game has to be at least as visual as something on a monochrome Palm or it's no dice, I'm afraid.

#Comment Re: A possibly distributed project? made: 2004-01-28 17:58:38.547039+00 by: Mars Saxman

You might try Realbasic; it has a GUI builder, uses a Java-like object model, and includes 3D graphics and sprite animation classes. The IDE runs on Mac OS and Windows, and also builds apps for Linux. I'm definitely biased here, being one of its developers and all, but RB is the easiest way I know of for a beginner to write a video game.

#Comment Re: A possibly distributed project? made: 2004-01-28 18:50:08.063917+00 by: meuon

Flushy, Smarty looks good, thanks. And this time, my app uses it's philosopy. It's a single PHP program/script that outputs HTML, and uses some HTML template/presentation files that can be modified without my getting involved. More importantly, as they keep adding columns to a couple of the tables, the output generators just create nice looking output out of the database structure following some simple rules. The previous coder hard coded every field name and format.. yech.

Back on topic: I think that it's important to do 'text mode' stuff first, just to understand that layer is 'underneath' everything else. I had played with sprites on a C-64 and Apple II before, it works and is a 'step'.. and then the next step should be real graphics/gui (however you do that, not my world). Why? I constantly amaze 'experts' by diagnosing and/or fixing their gui (MS/Mac) system with command line prompts.. and a few lines of perl has cleaned up and fixed some amazing text, database and file systems woes, even when the ral application was elsewhere.. Should a newbie become 'Dan-Like' in his text mode stdin/stdout skills? Not necessary.. but to know that it is worth having some of those skills and to be able to use them is a good thing.