Microsoft has recently announced that they are moving .Net to open source and supporting Mac and Linux in addition to their Windows OS with Visual Studio Community 2013. Also, Visual Studio 2015 will support iOS and Android development.
Frankly, it's a little confusing because in some places MS mentions Mac and Linux, but very few, and they mention iOS and Android in lots of places, but not everywhere. So the support may be different than what I said.
Nevertheless, MS is opening up. Or at least seeming to.
Their timing couldn't be better, in my opinion.
Oracle is working hard to poison Java. I'm not entirely sure why, unless they think that ticking off any Java programmers and users outside those developing middleware for Oracle's products is a really great strategy. Their support for Java as a general programming language, as Sun did, has been piss-poor since day 1. Every so often they make a grand gesture to try to present themselves as interested, but the product they offer now is not something I could send someone out to install with a good conscience. What kind of an honest, large-scale company thinks that half-sneaking some crap software in under the cover of installing their own is a really great idea? Not one that really treasures the individual customers, I can tell you (and yes, Adobe is on this particular excrement list, too.)
Couple that with their poor responsiveness to security concerns, to the point where the Java language is treated as a sort of worm or virus by most software, and you've got a company that's decided to leave a hole in the cross-platform development market simply because their interests are elsewhere.
Cross Platform Alternatives
C# is Microsoft's outgrowth from their own attempt at embrace, extend, exterminate targeting Java. It's a very good language, including the good parts of Java while having a set of libraries (.Net) that don't have the Java API's less than useless historical cruft but do have everything good about the API, which made Microsoft look really cool to programmers when it came out as most were not familiar with the Java API itself.
Switching to C# from Java is an afternoon's exercise. But it and the .Net library started out wed to the Microsoft platform.
Enter Mono, a cross-platform implementation of .Net supporting the C# language based on Microsoft's ECMA standard for its products. It has been growing, at least in part on the back of the decline of Java, as well as bringing the good things about C# and .Net to Mac and Linux development. It doesn't hurt that it is the core that drives products like the Unity cross-platform game-development system, too.
Now Microsoft is combining their products with Mono, and extending their reach to Android and iOS.
There are a Couple of Ways This Could Go (and Possibly More)
In Future A, Microsoft does the excellent work they do in producing development tools, but now with a return to platform-agnosticism. This encourages programmers to develop for Windows and Windows Phone as well, since programmers who might otherwise have been targetting only iOS or Android will be selecting these tools for their intrinsic value as development tools to write programs for their favored OS, then decide to toss a Windows/WinPho version out there, too, since it's not costing them any significant extra effort and might end up fattening the coffers a bit.
Microsoft gains developers for its platforms, draws "thought leader" and technical leaders into their ecosystem, and the developers get the advantage of having good development tools for any major platform they choose.
In Future B, Microsoft uses this as a ploy to draw programmers in, but cross-platform support is sloppy, or delivered slowly, or lags behind the native capabilities of the non-MS platforms. Perhaps it doesn't play well with the various different versions of Android, or maybe the Mac and Linux native code suffers by comparison with code developed with native tools for those platforms.
It turns out to just be hype. Maybe there are forces within MS that fight the release of solid tools that are truly cross-platform, so they ensure that foreign platform support is sub-par, thinking that they're helping their own products by making it "harder" to develop for other platforms. The only point of cross-platform, to them, is to allow Windows patriots to proclaim themselves cross-platform developers without knowing anything about the competition.
In this future, Windows does not become the programmer's platform of choice, Windows has extra costs of development that make it less attractive as a development target when another platform is the one that's going to pay the bills (probably iOS), and life goes on as it does today with possibly the Microsoft touch putting some poison into Mono.
I can only hope that the upper management at MS is committed to Future A. because that's what it's going to take to keep Future B from stepping in any time it pleases.
Microsoft, Doing You Know What in Their Own Messkit for the Past Decade
Windows 7 was a boon for programmers when it came out. I and many other programmers I know had been feeling somewhat kicked about by Apple, didn't see tools with the same level of sophistication on Linux (and generally more system maintenance than the commercial OSes, and system maintenance doesn't pay bills), and Windows 7 was a viable place to go, or to at least have as a second OS on our desk for conducting development and testing.
Windows 8 added some nice stuff behind the scenes, but not without wrecking the usability of the platform, as well as making it a far less attractive target for development. In my case, I abandoned Windows as a target for native development about a decade ago, and was waiting on Windows 8 to see if I might add it to my repertoire again. The answer became "no". Windows 10 will determine whether I ever consider it a serious platform for anything at all in the future, as the professional applications that I currently use on Windows have all become multi-platform over the past several years, so I can move my licenses over to Mac OS or Linux for all of them.
If Microsoft gets it right with their development tools, and Windows 10 restores the power to the desktop that earlier versions provided--not just a false appearance of it as in Windows 8.1--then they stand to become the defacto professional desktop again.
Whither Mobile?
And given that the consumer desktop is the market that is dying in the face of mobile platforms, one would hope that they are bright enough to strategically commit to a powerful professional computer OS again. While the mass market computer is probably going away, there was a profitable professional/hobbyist market before the internet boom put a computer in practically every household. That professional market stands to be even larger than the historical one, as many professions that had nothing to do with computers now rely on them, and many new professions have arisen over the past 25 years that rely on the computer.
Also, there's a possibility that the mobile device as a computer replacement is just a flash in the pan. Most people bought their mobile devices in place of a routine upgrade to their home computer for one cycle. Now that they have tablets, the tablet market is going flat while computers are seeing a modest rise in sales. I think just about everyone has had a chance to discover that the touch interface is very limited in what it can do with current technology. It's severely error-prone and it's not well suited to complex activities. It's too soon to read now, but there's a chance the tablet may be relegated to specialty use status, with the keyboard-equipped computer regaining its status as the "real" computer behind the smartphone's limited purposes as a personal communication and light entertainment device. We'll see.
The phone isn't going to go away, though. It's going to be the most personal of personal computers, at least until it's replaced by a small tablet and a complete phone the size of an earpiece, or some other revolutionary turn that gets people to give up a screen for convenience. So supporting the mobile platforms is, for Microsoft, probably a must to their survival. At least until they can get real market share for Winpho.
Either way, if Microsoft plays their cards right, going to platform-agnosticism in their development tools could be a really good thing for everybody--including and especially Microsoft.
Showing posts with label IDE. Show all posts
Showing posts with label IDE. Show all posts
Monday, November 17, 2014
Monday, January 16, 2012
8085 Resurgent: Back to the MAG-85
I took a look at my own website the other day and realized it's been far too long since I have updated certain items there. Most noticeable to me was my MAG-85 project, an 8085-based micro trainer. There are a bunch of things I thought I'd posted over a year ago, but the information isn't there.
Obviously I never did it. Sorry about that.
The front page image for the 8085 project is was a really ugly thing I took at a very interim stage while I was doing regular updates on the project. If I wanted to scare someone off the project, I think that picture is what I'd use. What a rat's nest!
Shortly after that picture was taken I built a real front panel and enclosure. It's been happily living in that enclosure for well over a year, but I never posted the info on it. In fact, I've just started taking it apart in preparation for making some improvements. Since I like to take pictures of my work for documentation purposes (like getting the right connectors back in the right places), I took some photos of the partially-disassembled unit as it is before I make the updates. Here's one:
Here you can see that it's not so ugly as before. The LED to the left of the LCD display is controlled by the 8085's SOD output. The eight LEDs below the display are controlled by the 8085's OUT 01 command and held in their state by a register. The eight switches below that are on the 8085's IN 01 port.
The program that's running currently reads the position of the switches and outputs a byte to the LED bank to match what it sees on the input. It also reads the keyboard and sends the ASCII + 0x30 character to the screen that it reads from the keyboard (which is in IN 00). The LCD display is on the OUT 00 port.
The four push buttons above the keyboard are, from left (red) to right:
RESET
TRAP
RST7.5
RST5.5
In the crude OS/monitor I have running on the MAG-85 now, TRAP acts as an "Escape" key that returns control to the OS. This allows miscreant programs to be stopped and memory examined any time, since TRAP isn't maskable.
RST7.5 is used as the user vector to the start of the application program in memory. In essence, this is the "GO" or "Execute" button.
RST5.5 is also a user vector that should point to a subroutine that does something and returns. Either the application program should initialize it, or it has to be initialized by hand in the monitor.
The keyboard itself uses RST6.5 to read a key value into a buffer, where an OS routine can pick it up/translate it, etc. The keycap legends allow for several uses of the keys. The typical use of the yellow keys is hexadecimal number entry. But they can also be used as arrow keys and fire button (9) for games.
The top row has the IN or Enter key in red, the backspace (BK) in blue, the (M) mode and edit/view (e/v) keys in gray. The edit/view key toggles a flag in the OS that switches between a memory protecting mode (view) and editing mode in the various modes. The mode key modifies the mode variable in the system to switch between Memory, Register, and I/O port viewing or editing. It's possible to change from editing to viewing and back again while in any of the modes.
Current Rework
My current plans for reworking the MAG-85 have to do with replacing the buttons used for RESET, TRAP and the RSTs, plus improving the ergonomics of the unit a bit by replacing the top and bottom panels, which were hand-made on hardboard, with some nicer CNC'd panels that reposition some of the controls (I switched off the unit more than once when I meant to switch on or off the backlight for the LCD.)
The four pushbuttons above the keyboard are some really awful buttons. They ring like bells, causing all sorts of debounce problems. I have both hardware and software debouncing on them right now, and it *mostly* works. I think part of why I stopped posting before was that I wanted to kill this problem before I posted, so as to avoid causing anyone else the headaches I've had with these switches. And, as you can see, those switches are still in there.
A sideline on the current work is also preparing for a couple of improvements that have been planned since the beginning, but haven't happened yet. One is to put a nice little door in so that the NOVRAM/EEPROM/EPROM memory can be swapped out without opening the whole unit. Right now I unscrew the end pieces then pop out the face panel to get at the memory socket. Which is not clean, quick, or easy. I have to get the cables all to go back to their places each time I put it back together. A couple of times I've pulled out one of the input cables by accident, then wondered why the keyboard or switches aren't talking when I get it back together.
The other is preparing to mount a battery pack inside, so that I can go cordless with this thing. A lot of what I've been doing in design tweaks is reducing the power used by the system. Finding a good brightness for the backlight, putting a switch on the backlight so that I can turn it off when I'm in good light, reducing the brightness of the power LED and the I/O LEDs, that sort of thing. As well as looking at my nascent OS to see if there are things I can do there that will reduce power while staying out of the way of the user's programs.
I'm also planning on adding another memory socket for an EPROM. It won't have a ZIF socket in it like the one that's there now, but I'm getting to the point of wanting a more permanent memory for the OS, with the NOVRAM left for user space programs. This may involve some rejiggering of the memory map, since for mechanical reasons I'd like to have the removable memory in the center of the PCB side to side.
I'm also looking at adding an expansion port or two on the new end plates, which begs the question of whether to use a standard connector with a more or less standard wiring for the port (like a PC's bidirectional parallel port) or whether to roll my own for the sake of less constraint on how the lines are used. Basically just bringing the lines from the I/O buffer registers straight out of the box along with power and ground. This is my preference for a number of reasons, but there's an appeal to letting the MAG-85 drive standard I/O devices, too.
The addition of a serial port, either at TTL levels or a standard RS-232C port is another possibility I keep playing with. I've kept SID available for this possibility, though I was tempted to use it as either a user digital I/O or a memory bankswitch I/O or something of the sort. Being able to connect the MAG-85 straight to a terminal would be really nice, so I'm leaning toward an RS-232C port.
But if I do that, I'll need a separate set of I/O routines for that port that allow it to be the primary user I/O for the OS. So if I do that, it'll probably be deferred until some other things happen first.
Like finishing the OS well enough to post it.
Finishing the MAG-85 Operating System
I haven't posted the OS yet because it's still in a fairly yucky developmental state. That and my test hardware still has the crummy switches that do nasty things to me at times, and there's lots of code in the OS just to try to deal with them that can probably come out once I've got decent switches in.
So my present software objective is to clean up the OS and put a bow on it so that I can "ship" it to a download on my site. I may end up cutting some of the features, but there's also the possibility that I'll end up cleaning them up because I've already got too much other code running around that uses them. The core basics are the ability to view and edit the system's memory, and execute a program starting at some given address. I'll guarantee that much.
I think the ability to view and edit register values is pretty well sewn, too. It's possible to bork the OS by doing something stupid here, but I'm not trying to protect the user from being stupid. Press TRAP (probably to be labelled ESC) and the OS will restart and reset any values it needs to function (I hope!)
The ability to view inputs and edit outputs interactively shouldn't be a problem, either, but it's not an immediate priority. If it happens effortlessly, it'll be in the initial release. Otherwise, I won't hold up the release for it.
I've also got another mode that is enabled in some versions for viewing/setting user variables in the OS, such as the RST5.5 and RST7.5 vectors, selecting different display formats, setting the size of the LCD, and so on. I can pretty well guarantee that the full-up version of this will not be in the initial release, though a cut-rate version of it may be. That would mean that you would set these variables yourself when putting the code on your own MAG-85.
If I do go to a design that uses two memories, one rewritable in system and the other not, I'll have to put these variables in RAM, or expect that they be set once and for all in the firmware. I'd like to be able to provide an EPROM at some point for people who want to build a MAG-85 and get up and running without having to put the OS in themselves. But if I do, I either need to put some system information in the NOVRAM memory space (like the height/width of the LCD display) or require that only one size of LCD be used with a specific version of the OS. Since I'm looking forward to building another MAG-85 with a larger display (perhaps 32 characters wide by 4 lines high), I'd like to keep the OS flexible. The initial display routines will only use a portion of displays larger than 20x2, but the user programs can use the larger displays and the OS can be updated later to have multiple display formats that the user can select.
But right now, I just need to drive a stake through its heart and get a workable version out the door. :)
Tweet
Obviously I never did it. Sorry about that.
The front page image for the 8085 project
A Very Ugly Looking 8085 Computer
Shortly after that picture was taken I built a real front panel and enclosure. It's been happily living in that enclosure for well over a year, but I never posted the info on it. In fact, I've just started taking it apart in preparation for making some improvements. Since I like to take pictures of my work for documentation purposes (like getting the right connectors back in the right places), I took some photos of the partially-disassembled unit as it is before I make the updates. Here's one:
A bit ugly with the top and bottom panels off, connectors and wires trailing out, but not so bad at the first photo.
Here you can see that it's not so ugly as before. The LED to the left of the LCD display is controlled by the 8085's SOD output. The eight LEDs below the display are controlled by the 8085's OUT 01 command and held in their state by a register. The eight switches below that are on the 8085's IN 01 port.
The program that's running currently reads the position of the switches and outputs a byte to the LED bank to match what it sees on the input. It also reads the keyboard and sends the ASCII + 0x30 character to the screen that it reads from the keyboard (which is in IN 00). The LCD display is on the OUT 00 port.
The four push buttons above the keyboard are, from left (red) to right:
RESET
TRAP
RST7.5
RST5.5
In the crude OS/monitor I have running on the MAG-85 now, TRAP acts as an "Escape" key that returns control to the OS. This allows miscreant programs to be stopped and memory examined any time, since TRAP isn't maskable.
RST7.5 is used as the user vector to the start of the application program in memory. In essence, this is the "GO" or "Execute" button.
RST5.5 is also a user vector that should point to a subroutine that does something and returns. Either the application program should initialize it, or it has to be initialized by hand in the monitor.
The keyboard itself uses RST6.5 to read a key value into a buffer, where an OS routine can pick it up/translate it, etc. The keycap legends allow for several uses of the keys. The typical use of the yellow keys is hexadecimal number entry. But they can also be used as arrow keys and fire button (9) for games.
The top row has the IN or Enter key in red, the backspace (BK) in blue, the (M) mode and edit/view (e/v) keys in gray. The edit/view key toggles a flag in the OS that switches between a memory protecting mode (view) and editing mode in the various modes. The mode key modifies the mode variable in the system to switch between Memory, Register, and I/O port viewing or editing. It's possible to change from editing to viewing and back again while in any of the modes.
Current Rework
My current plans for reworking the MAG-85 have to do with replacing the buttons used for RESET, TRAP and the RSTs, plus improving the ergonomics of the unit a bit by replacing the top and bottom panels, which were hand-made on hardboard, with some nicer CNC'd panels that reposition some of the controls (I switched off the unit more than once when I meant to switch on or off the backlight for the LCD.)
The four pushbuttons above the keyboard are some really awful buttons. They ring like bells, causing all sorts of debounce problems. I have both hardware and software debouncing on them right now, and it *mostly* works. I think part of why I stopped posting before was that I wanted to kill this problem before I posted, so as to avoid causing anyone else the headaches I've had with these switches. And, as you can see, those switches are still in there.
A sideline on the current work is also preparing for a couple of improvements that have been planned since the beginning, but haven't happened yet. One is to put a nice little door in so that the NOVRAM/EEPROM/EPROM memory can be swapped out without opening the whole unit. Right now I unscrew the end pieces then pop out the face panel to get at the memory socket. Which is not clean, quick, or easy. I have to get the cables all to go back to their places each time I put it back together. A couple of times I've pulled out one of the input cables by accident, then wondered why the keyboard or switches aren't talking when I get it back together.
The other is preparing to mount a battery pack inside, so that I can go cordless with this thing. A lot of what I've been doing in design tweaks is reducing the power used by the system. Finding a good brightness for the backlight, putting a switch on the backlight so that I can turn it off when I'm in good light, reducing the brightness of the power LED and the I/O LEDs, that sort of thing. As well as looking at my nascent OS to see if there are things I can do there that will reduce power while staying out of the way of the user's programs.
I'm also planning on adding another memory socket for an EPROM. It won't have a ZIF socket in it like the one that's there now, but I'm getting to the point of wanting a more permanent memory for the OS, with the NOVRAM left for user space programs. This may involve some rejiggering of the memory map, since for mechanical reasons I'd like to have the removable memory in the center of the PCB side to side.
I'm also looking at adding an expansion port or two on the new end plates, which begs the question of whether to use a standard connector with a more or less standard wiring for the port (like a PC's bidirectional parallel port) or whether to roll my own for the sake of less constraint on how the lines are used. Basically just bringing the lines from the I/O buffer registers straight out of the box along with power and ground. This is my preference for a number of reasons, but there's an appeal to letting the MAG-85 drive standard I/O devices, too.
The addition of a serial port, either at TTL levels or a standard RS-232C port is another possibility I keep playing with. I've kept SID available for this possibility, though I was tempted to use it as either a user digital I/O or a memory bankswitch I/O or something of the sort. Being able to connect the MAG-85 straight to a terminal would be really nice, so I'm leaning toward an RS-232C port.
But if I do that, I'll need a separate set of I/O routines for that port that allow it to be the primary user I/O for the OS. So if I do that, it'll probably be deferred until some other things happen first.
Like finishing the OS well enough to post it.
Finishing the MAG-85 Operating System
I haven't posted the OS yet because it's still in a fairly yucky developmental state. That and my test hardware still has the crummy switches that do nasty things to me at times, and there's lots of code in the OS just to try to deal with them that can probably come out once I've got decent switches in.
So my present software objective is to clean up the OS and put a bow on it so that I can "ship" it to a download on my site. I may end up cutting some of the features, but there's also the possibility that I'll end up cleaning them up because I've already got too much other code running around that uses them. The core basics are the ability to view and edit the system's memory, and execute a program starting at some given address. I'll guarantee that much.
I think the ability to view and edit register values is pretty well sewn, too. It's possible to bork the OS by doing something stupid here, but I'm not trying to protect the user from being stupid. Press TRAP (probably to be labelled ESC) and the OS will restart and reset any values it needs to function (I hope!)
The ability to view inputs and edit outputs interactively shouldn't be a problem, either, but it's not an immediate priority. If it happens effortlessly, it'll be in the initial release. Otherwise, I won't hold up the release for it.
I've also got another mode that is enabled in some versions for viewing/setting user variables in the OS, such as the RST5.5 and RST7.5 vectors, selecting different display formats, setting the size of the LCD, and so on. I can pretty well guarantee that the full-up version of this will not be in the initial release, though a cut-rate version of it may be. That would mean that you would set these variables yourself when putting the code on your own MAG-85.
If I do go to a design that uses two memories, one rewritable in system and the other not, I'll have to put these variables in RAM, or expect that they be set once and for all in the firmware. I'd like to be able to provide an EPROM at some point for people who want to build a MAG-85 and get up and running without having to put the OS in themselves. But if I do, I either need to put some system information in the NOVRAM memory space (like the height/width of the LCD display) or require that only one size of LCD be used with a specific version of the OS. Since I'm looking forward to building another MAG-85 with a larger display (perhaps 32 characters wide by 4 lines high), I'd like to keep the OS flexible. The initial display routines will only use a portion of displays larger than 20x2, but the user programs can use the larger displays and the OS can be updated later to have multiple display formats that the user can select.
But right now, I just need to drive a stake through its heart and get a workable version out the door. :)
Friday, August 13, 2010
Greenfoot's Greenroom: What a Bonanza!
I finally got around to registering for The Greenroom, a support area for teachers using the Greenfoot framework for Java in their classes. All I have to say is, Wow!
If you're a teacher using Greenfoot, or thinking about it, take the time to sign up for access. Access is limited to those who can show some bona fides to show that they're teachers, not sneaky students trying to wreck the teacher's lesson plan. ;)
That's what kept me from signing up for some time, I just didn't take the time to dig up something with my name on it at my school's website to show my status. Well, I finally took the time to do it, and now I wish I'd bothered a long time ago!
The resources available include a wide selection of very well presented lessons, exercises, and information on using Greenfoot with Eclipse, etc., etc. Then there's the discussion boards. I follow the Greenfoot and BlueJ mailing lists, but the Greenroom discussions have an extra dimension to them, particularly from the teacher's perspective.
If that's not enough, that's also where to find the announcement of the forthcoming Greenfoot 2.0! My excitement about Greenfoot 2.0 is the new editor, with syntax highlighting and code completion. I can't wait to get my hands on it, I'll post about it when I do.
Tweet
If you're a teacher using Greenfoot, or thinking about it, take the time to sign up for access. Access is limited to those who can show some bona fides to show that they're teachers, not sneaky students trying to wreck the teacher's lesson plan. ;)
That's what kept me from signing up for some time, I just didn't take the time to dig up something with my name on it at my school's website to show my status. Well, I finally took the time to do it, and now I wish I'd bothered a long time ago!
The resources available include a wide selection of very well presented lessons, exercises, and information on using Greenfoot with Eclipse, etc., etc. Then there's the discussion boards. I follow the Greenfoot and BlueJ mailing lists, but the Greenroom discussions have an extra dimension to them, particularly from the teacher's perspective.
If that's not enough, that's also where to find the announcement of the forthcoming Greenfoot 2.0! My excitement about Greenfoot 2.0 is the new editor, with syntax highlighting and code completion. I can't wait to get my hands on it, I'll post about it when I do.
Monday, January 26, 2009
A First Look at DarkBASIC Professional
I have a student that wants to learn programming using DarkBASIC Professional. Fair enough, I've worked in a fair few BASIC dialects. BASIC is not typically what I start a student with any more, but this is a one-on-one situation. So I'm willing to give this particular commercial BASIC dialect a shot.
I went out to the website for DarkBASIC Pro and poked around. I found several versions of DarkBASIC (standard, pro, Lite, etc.), and as it happens when I went to download a trial version I got a page that simply tells me that the trial version isn't available. No forwarding links or anything.
OK, let's try again. I note that the page I ended up on is for DarkBASIC, not DarkBASIC Pro. Other pages I look at are all asking me for money that I'm not yet prepared to spend. A bit more poking around turns up a better page that allows for a download of DarkBASIC Pro's 30-day trial version.
So I download, scan for viruses (you never know, even some of the best outfits get hit, and as usual for Windows there's no MD5 or other checksum I can use to check file integrity after download) then I install the program from an administrative login. All goes smoothly up to that point.
Afterward, I go back to my usual account, a limited account where I normally do all my programming work. DarkBASIC starts, asks me to activate it, I do so with no fuss or muss and get into the editor. I type in a short program, and hit F5 to compile.
Whereupon I get an error message telling me that DarkBASIC Pro can't write to the directories under C:\Program Files\ where DarkBASIC Pro is installed. No problemo, I'll just let DBPro know that I want to save somewhere to my local user directories. Hmm, or I'll try to.
A perusal of the menus in DBPro didn't turn up any way to do that. Normally I expect to set the options for the user or the project to save to where I tell it to save. The Options pane in DBPro includes no such thing, or any other menu item that I could think to select on the basis of logic or any extension of it.
So DBPro expects me to install as an admin, and do all my programming as an admin, even though it installs a desktop icon for all users? Poor form!
I changed users to my admin account and started DBPro there. It needed to be activated again, so I did so. I entered a program and ran it. It compiled OK, the Trial Version splash screen came up, all OK. Then I get an error message telling me that I only have DirectX 9.0 installed, and that DBPro wants 9.0c. What a load of nonsense!
I had run DXDiag before donloading DBPro and verified that I met the system requirements. My system is running DX9.0c.
Fortunately, after reporting this "error" DBPro went ahead and ran my program anyway. Good thing it did, I was getting pretty annoyed by this point. My program ran fine. It was a simple PRINT program, nothing more. Since DBPro uses a run loop sort of runtime, such programs need a statement at the end to keep the program from "falling through" and ending before the results have been seen. In my case I added a "WAIT KEY" line:
That's not exactly the program, but it gets the idea across.
I entered, compiled and ran several other simple programs to try out some standard BASIC control structures. They all ran fine, aside from the erroneous error message which was repeated with every run of every program.
So, is DarkBASIC Pro bad? Not at all. But it falls short of its moniker of Professional. I expect to be able to use a professional tool with individual, limited, user accounts with data stored local to that user. To be honest, I also expect something labelled as "professional" to allow the use of a revision control system, and I see no evidence of that in DBPro so far, though it may be hidden in there somewhere.
Whether I'll use DBPro with my student remains to be seen. It'll be adequate for some introductory work at least, though I may see if we can change to Visual BASIC Express, Java, or some other free development package suited for beginners. These also have wider application than DBPro in the world at large. Further, lots of information is available on them for free.
There are some free DBPro resources, but the primary resources from the company that makes DBPro are extra purchases. The printed manual my student had for DBPro that came with his purchase of it was not at all a good reference for a new programmer. The company offers a book for more money, but they keep asking for money here and money there, and it gives a feeling that their legitimate profit motive may be stretched a bit beyond where it legitimately belongs.
Edit:
I have since tried to add some sound commands. DarkBASIC Pro now tells me that I do not have DirectX installed, and my programs don't function at all, even in debug mode. My student was able to compile and run the example applications provided with his purchased copy of DarkBASIC Pro, so I know that such things can work. But that doesn't do me much good. I think I'm going to see if we can shift over to something that I can expect to work the same on both our systems, either Java/Greenfoot or Visual Basic Express.
I went out to the website for DarkBASIC Pro and poked around. I found several versions of DarkBASIC (standard, pro, Lite, etc.), and as it happens when I went to download a trial version I got a page that simply tells me that the trial version isn't available. No forwarding links or anything.
OK, let's try again. I note that the page I ended up on is for DarkBASIC, not DarkBASIC Pro. Other pages I look at are all asking me for money that I'm not yet prepared to spend. A bit more poking around turns up a better page that allows for a download of DarkBASIC Pro's 30-day trial version.
So I download, scan for viruses (you never know, even some of the best outfits get hit, and as usual for Windows there's no MD5 or other checksum I can use to check file integrity after download) then I install the program from an administrative login. All goes smoothly up to that point.
Afterward, I go back to my usual account, a limited account where I normally do all my programming work. DarkBASIC starts, asks me to activate it, I do so with no fuss or muss and get into the editor. I type in a short program, and hit F5 to compile.
Whereupon I get an error message telling me that DarkBASIC Pro can't write to the directories under C:\Program Files\ where DarkBASIC Pro is installed. No problemo, I'll just let DBPro know that I want to save somewhere to my local user directories. Hmm, or I'll try to.
A perusal of the menus in DBPro didn't turn up any way to do that. Normally I expect to set the options for the user or the project to save to where I tell it to save. The Options pane in DBPro includes no such thing, or any other menu item that I could think to select on the basis of logic or any extension of it.
So DBPro expects me to install as an admin, and do all my programming as an admin, even though it installs a desktop icon for all users? Poor form!
I changed users to my admin account and started DBPro there. It needed to be activated again, so I did so. I entered a program and ran it. It compiled OK, the Trial Version splash screen came up, all OK. Then I get an error message telling me that I only have DirectX 9.0 installed, and that DBPro wants 9.0c. What a load of nonsense!
I had run DXDiag before donloading DBPro and verified that I met the system requirements. My system is running DX9.0c.
Fortunately, after reporting this "error" DBPro went ahead and ran my program anyway. Good thing it did, I was getting pretty annoyed by this point. My program ran fine. It was a simple PRINT program, nothing more. Since DBPro uses a run loop sort of runtime, such programs need a statement at the end to keep the program from "falling through" and ending before the results have been seen. In my case I added a "WAIT KEY" line:
PRINT "Howdy"
WAIT KEYThat's not exactly the program, but it gets the idea across.
I entered, compiled and ran several other simple programs to try out some standard BASIC control structures. They all ran fine, aside from the erroneous error message which was repeated with every run of every program.
So, is DarkBASIC Pro bad? Not at all. But it falls short of its moniker of Professional. I expect to be able to use a professional tool with individual, limited, user accounts with data stored local to that user. To be honest, I also expect something labelled as "professional" to allow the use of a revision control system, and I see no evidence of that in DBPro so far, though it may be hidden in there somewhere.
Whether I'll use DBPro with my student remains to be seen. It'll be adequate for some introductory work at least, though I may see if we can change to Visual BASIC Express, Java, or some other free development package suited for beginners. These also have wider application than DBPro in the world at large. Further, lots of information is available on them for free.
There are some free DBPro resources, but the primary resources from the company that makes DBPro are extra purchases. The printed manual my student had for DBPro that came with his purchase of it was not at all a good reference for a new programmer. The company offers a book for more money, but they keep asking for money here and money there, and it gives a feeling that their legitimate profit motive may be stretched a bit beyond where it legitimately belongs.
Edit:
I have since tried to add some sound commands. DarkBASIC Pro now tells me that I do not have DirectX installed, and my programs don't function at all, even in debug mode. My student was able to compile and run the example applications provided with his purchased copy of DarkBASIC Pro, so I know that such things can work. But that doesn't do me much good. I think I'm going to see if we can shift over to something that I can expect to work the same on both our systems, either Java/Greenfoot or Visual Basic Express.
Thursday, August 7, 2008
Learn Another Language
There are a lot of computer languages out there. Each one has vocal adherents. They often sound like the folks who used to battle over whether the Commodore 64 was better than the Atari 800. The fact is that computer languages are created for a reason, they're created to solve a problem. Each one has its own features, and its own approach to dealing with specific problems that the implementors saw with existing languages.
Learning a computer language is an involved process. Learning modern object-oriented languages well enough to be well rounded in all their features is a time-consuming process. I'd say it takes two years to become competent, longer to become really good at solving any arbitrary problem with the language. With this kind of a time investment, why dilute your efforts by learning more than one language?
I took English classes all the way through elementary school. I got good at spelling, and developed a pretty good vocabulary. But most of the grammar went right over my head. In 7th grade I started taking a class in German. Suddenly all this stuff about subjects, objects, and indirect objects started to make sense. It was enough to make me wonder why I'd never gotten it before, it seemed so simple.
The same sort of revelation can occur when learning a new computer language. Concepts that were muddy before can suddenly be illuminated by the new language. This is especially true when learning a language that's been designed for an entirely different class of programs than your first language.
The "big" languages today are far more flexible and more generally applicable to a wide range of problems and programming approaches than the simpler languages of 30 years ago. This is part of why it takes longer to learn them thoroughly. They've adopted the good parts of many earlier languages, usually building on a base of a strong prior language. The result is that it can make each language look like it's the be-all and end-all of languages. They fill a lot of checkboxes, and even where they don't have a specific feature, they have some other fairly direct way to get the same results.
This doesn't mean they're all the same, however.
Why Spend the Time?
Still, there's only so much time and energy. With learning a language being such a substantial undertaking, why divert effort into a new language rather than delving deeper into the one you already know?
First, diversification is not only educational, it's a survival skill. Overcommitment to one language means that when the need to shift finally comes, it'll be that much harder to change one's thinking to adopt a new language effectively. Languages will change, new languages will appear that will overshadow current languages. Current languages aren't likely to go away--code tends to hang around--but new languages will dominate. Even if you still work with an older language, understanding newer languages and what they do will be valuable to you. Chances are your language will change and adapt, too. A prior understanding of the new concepts will make it that much easier to take advantage of these changes. Either way, you'll be a more valuable programmer.
And it will be easier to learn the new languages if you are already familiar with several. Those new languages are going to come from somewhere, and if you've already got a regular approach for picking up new languages, you'll just be applying it to yet another.
Educationally, there's more to learn by picking up new languages than the new syntax and programming constructs. Learning a new language often means learning to work in a new development environment, and possibly with a very different workflow. You'll have a chance to see what other programmers use, and see the advantages. Perhaps the same features are already there in the IDE you use with your own language, you've just never been motivated to try it out since you didn't perceive the advantage. Each different language tends to have a preferred set of tools for version control and project management, too. Even if you only ever program professionally in one language knowing more than one toolset for everything from editing to distribution is of tremendous value.
There's nothing worse than knowing the language that everyone is advertising for then get passed over for job after job because you don't have experience with the employer's environment.
If you're a lone wolf developer, or part of a small team, knowing more than one thing is even more important. It's essential to get as much productivity as possible out of the few work hours available. You can't afford to spend your time carrying water from the well in buckets, you've got to put in plumbing to be productive. If you don't get out of your groove and look around at what other languages and other toolsets have to offer, chances are you're carrying buckets and complaining about how there's no time to put down the buckets to learn plumbing.
Picking a Second Language
Choosing the language to learn is important, too. It shouldn't be over-thought, however. It's not like it's the last language you'll ever learn. You can also break off and change choices at any time, though it's best to stick with one long enough to get well enough in to understand why it does things the way it does.
For your new language, you may want to pick a second language close to the one you already know. This can be both good and bad. It can introduce you to some new things without requiring as much of a change of pace as a totally unrelated language. The problem is that you're not getting as far out of your groove as you would with something else, and the syntaxes of two similar languages might just get jumbled in your head making it even harder to use your primary language.
Picking a language that's out of left field for you will require more effort to learn and understand, but it avoids the problems of picking a closely related language.
One way to diversify is to select a language that's of a different scope than your current language. If you're programming in one of the more "full-up" languages OO like C++ or Java, you may want to pick up one of the "scripting" languages like python or ruby. Or you can take a step even lower to the actual scripting languages like one of the Unix shell languages (ksh, bash, csh, etc.) If you already know one of the simpler languages (whether simpler in features or in syntax--I don't mean any of these comparisons as value judgements) you should probably give a try to something more involved.
There's also diversification in terms of language type. This relates to the approach the language takes to solving problems, and the mindset used with the language. If you know a procedural language, try a functional programming language, perhaps. If you're not doing object oriented programming, try one of the OO languages--particularly one of the OO scripting languages.
If you want to limit your efforts, there are a lot of languages that you can learn without too much effort--at least well enough to get a feel for the language's approach. Clearly the syntax-light "scripting" languages fulfill this requirement. But other languages, such as LISP and LOGO are also very easy to learn, and they're often well off track for most programmers relative to their usual language, making them a great learning experience. I know that LISP and its related languages are going through a bit of a vogue right now, my recommendation has nothing to do with that. I've been recommending LISP since I first learned it in a single quarter's class in 1981. And though LOGO is often considered a "kid's language," I personally consider it more of a LISP with a lot of the historical cruft taken out. Either way, the current vogue of LISP-y languages is a good thing. It means there are many good, modern implementations and tool sets for them.
Forth is also easy to learn, and playing with its guts is both fun and educational. You don't necessarily have to join the religion. ;)
Assembly programming is not as straightforward as it once was, interactions with modern OSes make it more involved. However, learning assembly using a virtual machine of some sort, solves this problem. There are free, downloadable development and simulation environments for many microcontrollers. This can be a good way to get started with assembly.
If you only know one language, get out and learn another. It'll be fun, it will stretch your brain a bit, and it'll make you a better programmer, even in your first language.
Learning a computer language is an involved process. Learning modern object-oriented languages well enough to be well rounded in all their features is a time-consuming process. I'd say it takes two years to become competent, longer to become really good at solving any arbitrary problem with the language. With this kind of a time investment, why dilute your efforts by learning more than one language?
I took English classes all the way through elementary school. I got good at spelling, and developed a pretty good vocabulary. But most of the grammar went right over my head. In 7th grade I started taking a class in German. Suddenly all this stuff about subjects, objects, and indirect objects started to make sense. It was enough to make me wonder why I'd never gotten it before, it seemed so simple.
The same sort of revelation can occur when learning a new computer language. Concepts that were muddy before can suddenly be illuminated by the new language. This is especially true when learning a language that's been designed for an entirely different class of programs than your first language.
The "big" languages today are far more flexible and more generally applicable to a wide range of problems and programming approaches than the simpler languages of 30 years ago. This is part of why it takes longer to learn them thoroughly. They've adopted the good parts of many earlier languages, usually building on a base of a strong prior language. The result is that it can make each language look like it's the be-all and end-all of languages. They fill a lot of checkboxes, and even where they don't have a specific feature, they have some other fairly direct way to get the same results.
This doesn't mean they're all the same, however.
Why Spend the Time?
Still, there's only so much time and energy. With learning a language being such a substantial undertaking, why divert effort into a new language rather than delving deeper into the one you already know?
First, diversification is not only educational, it's a survival skill. Overcommitment to one language means that when the need to shift finally comes, it'll be that much harder to change one's thinking to adopt a new language effectively. Languages will change, new languages will appear that will overshadow current languages. Current languages aren't likely to go away--code tends to hang around--but new languages will dominate. Even if you still work with an older language, understanding newer languages and what they do will be valuable to you. Chances are your language will change and adapt, too. A prior understanding of the new concepts will make it that much easier to take advantage of these changes. Either way, you'll be a more valuable programmer.
And it will be easier to learn the new languages if you are already familiar with several. Those new languages are going to come from somewhere, and if you've already got a regular approach for picking up new languages, you'll just be applying it to yet another.
Educationally, there's more to learn by picking up new languages than the new syntax and programming constructs. Learning a new language often means learning to work in a new development environment, and possibly with a very different workflow. You'll have a chance to see what other programmers use, and see the advantages. Perhaps the same features are already there in the IDE you use with your own language, you've just never been motivated to try it out since you didn't perceive the advantage. Each different language tends to have a preferred set of tools for version control and project management, too. Even if you only ever program professionally in one language knowing more than one toolset for everything from editing to distribution is of tremendous value.
There's nothing worse than knowing the language that everyone is advertising for then get passed over for job after job because you don't have experience with the employer's environment.
If you're a lone wolf developer, or part of a small team, knowing more than one thing is even more important. It's essential to get as much productivity as possible out of the few work hours available. You can't afford to spend your time carrying water from the well in buckets, you've got to put in plumbing to be productive. If you don't get out of your groove and look around at what other languages and other toolsets have to offer, chances are you're carrying buckets and complaining about how there's no time to put down the buckets to learn plumbing.
Picking a Second Language
Choosing the language to learn is important, too. It shouldn't be over-thought, however. It's not like it's the last language you'll ever learn. You can also break off and change choices at any time, though it's best to stick with one long enough to get well enough in to understand why it does things the way it does.
For your new language, you may want to pick a second language close to the one you already know. This can be both good and bad. It can introduce you to some new things without requiring as much of a change of pace as a totally unrelated language. The problem is that you're not getting as far out of your groove as you would with something else, and the syntaxes of two similar languages might just get jumbled in your head making it even harder to use your primary language.
Picking a language that's out of left field for you will require more effort to learn and understand, but it avoids the problems of picking a closely related language.
One way to diversify is to select a language that's of a different scope than your current language. If you're programming in one of the more "full-up" languages OO like C++ or Java, you may want to pick up one of the "scripting" languages like python or ruby. Or you can take a step even lower to the actual scripting languages like one of the Unix shell languages (ksh, bash, csh, etc.) If you already know one of the simpler languages (whether simpler in features or in syntax--I don't mean any of these comparisons as value judgements) you should probably give a try to something more involved.
There's also diversification in terms of language type. This relates to the approach the language takes to solving problems, and the mindset used with the language. If you know a procedural language, try a functional programming language, perhaps. If you're not doing object oriented programming, try one of the OO languages--particularly one of the OO scripting languages.
If you want to limit your efforts, there are a lot of languages that you can learn without too much effort--at least well enough to get a feel for the language's approach. Clearly the syntax-light "scripting" languages fulfill this requirement. But other languages, such as LISP and LOGO are also very easy to learn, and they're often well off track for most programmers relative to their usual language, making them a great learning experience. I know that LISP and its related languages are going through a bit of a vogue right now, my recommendation has nothing to do with that. I've been recommending LISP since I first learned it in a single quarter's class in 1981. And though LOGO is often considered a "kid's language," I personally consider it more of a LISP with a lot of the historical cruft taken out. Either way, the current vogue of LISP-y languages is a good thing. It means there are many good, modern implementations and tool sets for them.
Forth is also easy to learn, and playing with its guts is both fun and educational. You don't necessarily have to join the religion. ;)
Assembly programming is not as straightforward as it once was, interactions with modern OSes make it more involved. However, learning assembly using a virtual machine of some sort, solves this problem. There are free, downloadable development and simulation environments for many microcontrollers. This can be a good way to get started with assembly.
If you only know one language, get out and learn another. It'll be fun, it will stretch your brain a bit, and it'll make you a better programmer, even in your first language.
Monday, July 28, 2008
Greenfoot: Killer Intro to OO or Just a Toy?
I'm checking out Greenfoot, a Java framework + IDE for high school students. The IDE extends BlueJ. The framework provides right-now graphics to students, a favorite object of mine.
Greenfoot lets students jump right in and start playing with objects and classes. The concepts of object and class are very hard to teach. They're my biggest hurdle in teaching programming. Greenfoot looks like it may be the perfect tool for clearing that hurdle.
It simplifies the relationships between classes, objects, and methods without concealing the useful information. It ties actions like instantiation and method calls to visible manual activities with visual results. You can say, "I'm going to instantiate a wombat," then do it. The Wombat class has a menu item creates a new wombat object. Similarly, subclassing and inheritance can be demonstrated from simple menu actions.
Greenfoot isn't just for the teacher's projector. On the student's computer it runs framework programs called scenarios that are basically tile and sprite programs. They are fun and easy to tweak and run. The system invites exploration.
The underlying code is real Java, not a canned version of an OO language. Theoretically this means the programs produced with Greenfoot can be as extensive as Java itself. It generates stand-alone applications and applets. The question is whether students will willingly grow out of using Greenfoot as a simple sprite game generator to develop ideas that Greenfoot doesn't implement as easily.
I'm trying out Greenfoot with a couple of live students now, aged 13 and 16. Both have been exposed to Java, neither really got classes or objects. We spent about 40 minutes watching a demo of Greenfoot by Michael Kölling. The demo wasn't targeted to students, but by the time we reached the Q&A session they were both aching to get their hands on Greenfoot. I set them loose, with no further instruction, just making myself available for questions (while I played with it myself.)
Both definitely had fun. Neither wanted to quit when time was up. There wasn't any time for a debrief to see what was learned aside from the fact that Greenfoot can do a pleasant job of filling an afternoon. That by itself has value if it shows you can control a machine without being an otaku egghead.
For myself, I found it to have some rough edges that would make it tough for non-programmer teachers to use in class. This isn't a problem for me, but I had hoped this might be something I could present to others whose skills largely restrict their classes to typing, MS Office, simple painting apps, and the occasional session of Minefield or Solitaire. I don't think it's ready for them to use on their own. But I'll see about sitting a non-programming instructor down with it and see what they make of it.
It might work for an instructor with the right mindset:
There are questions I have about Greenfoot that I'll be looking for answers to before I recommend it. Does its use really translate into programming? Or will students resist going beyond menu-driven image replacements and simple changes of constants? Will they go into shock at the sight of code in the editor window? How much of my time will it take to set up scenarios to introduce and illustrate new concepts and constructs? Will attempts to shift gears from unstructured play to directed learning cause a revolt?
Where does it fit with other instruction? After a few command line exercises or as a light intro? Is there a point when a more conventional IDE should replace it? Will it be necessary to repeat concepts both in and out of Greenfoot so that they still make sense without Greenfoot's presentation?
More on my Greenfoot experiment soon. At this point, I'd say a teacher with programming skills could make excellent use of it to illustrate many basic OO concepts that are serious problems to non-programmer students.
And it's a heck of a lot of fun.
Greenfoot lets students jump right in and start playing with objects and classes. The concepts of object and class are very hard to teach. They're my biggest hurdle in teaching programming. Greenfoot looks like it may be the perfect tool for clearing that hurdle.
It simplifies the relationships between classes, objects, and methods without concealing the useful information. It ties actions like instantiation and method calls to visible manual activities with visual results. You can say, "I'm going to instantiate a wombat," then do it. The Wombat class has a menu item creates a new wombat object. Similarly, subclassing and inheritance can be demonstrated from simple menu actions.
Greenfoot isn't just for the teacher's projector. On the student's computer it runs framework programs called scenarios that are basically tile and sprite programs. They are fun and easy to tweak and run. The system invites exploration.
The underlying code is real Java, not a canned version of an OO language. Theoretically this means the programs produced with Greenfoot can be as extensive as Java itself. It generates stand-alone applications and applets. The question is whether students will willingly grow out of using Greenfoot as a simple sprite game generator to develop ideas that Greenfoot doesn't implement as easily.
I'm trying out Greenfoot with a couple of live students now, aged 13 and 16. Both have been exposed to Java, neither really got classes or objects. We spent about 40 minutes watching a demo of Greenfoot by Michael Kölling. The demo wasn't targeted to students, but by the time we reached the Q&A session they were both aching to get their hands on Greenfoot. I set them loose, with no further instruction, just making myself available for questions (while I played with it myself.)
Both definitely had fun. Neither wanted to quit when time was up. There wasn't any time for a debrief to see what was learned aside from the fact that Greenfoot can do a pleasant job of filling an afternoon. That by itself has value if it shows you can control a machine without being an otaku egghead.
For myself, I found it to have some rough edges that would make it tough for non-programmer teachers to use in class. This isn't a problem for me, but I had hoped this might be something I could present to others whose skills largely restrict their classes to typing, MS Office, simple painting apps, and the occasional session of Minefield or Solitaire. I don't think it's ready for them to use on their own. But I'll see about sitting a non-programming instructor down with it and see what they make of it.
It might work for an instructor with the right mindset:
- don't sweat what you don't get,
- if something doesn't work then don't do that--do something else,
- let the students research their own solutions online,
- and share among themselves,
- then grade results and progress, not code.
There are questions I have about Greenfoot that I'll be looking for answers to before I recommend it. Does its use really translate into programming? Or will students resist going beyond menu-driven image replacements and simple changes of constants? Will they go into shock at the sight of code in the editor window? How much of my time will it take to set up scenarios to introduce and illustrate new concepts and constructs? Will attempts to shift gears from unstructured play to directed learning cause a revolt?
Where does it fit with other instruction? After a few command line exercises or as a light intro? Is there a point when a more conventional IDE should replace it? Will it be necessary to repeat concepts both in and out of Greenfoot so that they still make sense without Greenfoot's presentation?
More on my Greenfoot experiment soon. At this point, I'd say a teacher with programming skills could make excellent use of it to illustrate many basic OO concepts that are serious problems to non-programmer students.
And it's a heck of a lot of fun.
Friday, July 25, 2008
IDEs for Class: Arachnophilia
Arachnophilia is a simple IDE that works with a variety of programming languages. It's got a simple, but highly configurable, interface.
Arachnophilia is the primary IDE that I use in my classes. After starting my students at the command line, and after introducing them to other IDEs, about 80% of my students use Arachnophilia by choice, and are very productive with it. The other 20% usually choose to use the command line as their primary development environment, though they will usually use Arachnophilia as an adjunct, for example as a code beautifier.
I teach in a multi-platform computer lab. While this is a challenge, I mostly consider it an excellent opportunity for making a point to the students. The real world is a multi-platform environment. Since Arachnophilia is written in Java, it runs on all the lab's systems and behaves the same way on all of them. Arachnophilia includes a special install for Windows that makes getting it going on that OS easy. It even includes a nice icon. (To get an icon on OS X and other Unix systems, I get the favicon.ico file from Arachnophilia's web site and make that the program's icon.)
Arachnophilia is syntax-aware for many programming languages, including HTML/CSS (its original purpose), C, C++, python, PHP, JavaScript, and Java. In a class where multiple programming languages are introduced (like mine) it's nice to have one IDE that works with all of them. I usually introduce Arachnophilia about halfway through our HTML/CSS unit, and continue using it in the Java programming portion of the class.
While I don't teach that Arachnophilia's interface is configurable, about one third of the class usually discovers this on their own and figures it out. They rapidly share this with the rest of the class, configuring their own build settings, customizing toolbars, and so on.
Arachnophilia behaves exactly the same on all platforms. This is a plus when you're calling out keystrokes in class, but it can be a problem for Mac users who are used to keyboard shortcuts that employ the Apple/Command key rather than the Control key. Moving back and forth between Arachnophilia and other apps on the Mac in the same session can be a bit disorienting as a result.
The interface the program provides is clean and easily accessible. I usually spend only about 10-15 minutes of class time getting students started with it, and another 10 minutes or so going into more advanced features later. Arachnophilia doesn't require any configuration to use before class (other than installation), unlike more advanced IDEs like Eclipse or Netbeans. Unlike Amaya, which is a nice IDE focused on HTML/CSS, we can keep using it when we move on to Java programming.
While I also like BlueJ a lot for class use, it is Java-specific, so I don't have an opportunity to introduce it during the HTML/CSS unit that I use as an introduction to programming concepts.
For my class, the ease of use and flexibility of Arachnophilia has made it the winner among a strong contingent of IDEs available.
Arachnophilia is the primary IDE that I use in my classes. After starting my students at the command line, and after introducing them to other IDEs, about 80% of my students use Arachnophilia by choice, and are very productive with it. The other 20% usually choose to use the command line as their primary development environment, though they will usually use Arachnophilia as an adjunct, for example as a code beautifier.
I teach in a multi-platform computer lab. While this is a challenge, I mostly consider it an excellent opportunity for making a point to the students. The real world is a multi-platform environment. Since Arachnophilia is written in Java, it runs on all the lab's systems and behaves the same way on all of them. Arachnophilia includes a special install for Windows that makes getting it going on that OS easy. It even includes a nice icon. (To get an icon on OS X and other Unix systems, I get the favicon.ico file from Arachnophilia's web site and make that the program's icon.)
Arachnophilia is syntax-aware for many programming languages, including HTML/CSS (its original purpose), C, C++, python, PHP, JavaScript, and Java. In a class where multiple programming languages are introduced (like mine) it's nice to have one IDE that works with all of them. I usually introduce Arachnophilia about halfway through our HTML/CSS unit, and continue using it in the Java programming portion of the class.
While I don't teach that Arachnophilia's interface is configurable, about one third of the class usually discovers this on their own and figures it out. They rapidly share this with the rest of the class, configuring their own build settings, customizing toolbars, and so on.
Arachnophilia behaves exactly the same on all platforms. This is a plus when you're calling out keystrokes in class, but it can be a problem for Mac users who are used to keyboard shortcuts that employ the Apple/Command key rather than the Control key. Moving back and forth between Arachnophilia and other apps on the Mac in the same session can be a bit disorienting as a result.
The interface the program provides is clean and easily accessible. I usually spend only about 10-15 minutes of class time getting students started with it, and another 10 minutes or so going into more advanced features later. Arachnophilia doesn't require any configuration to use before class (other than installation), unlike more advanced IDEs like Eclipse or Netbeans. Unlike Amaya, which is a nice IDE focused on HTML/CSS, we can keep using it when we move on to Java programming.
While I also like BlueJ a lot for class use, it is Java-specific, so I don't have an opportunity to introduce it during the HTML/CSS unit that I use as an introduction to programming concepts.
For my class, the ease of use and flexibility of Arachnophilia has made it the winner among a strong contingent of IDEs available.
Thursday, July 24, 2008
IDEs for Class: BlueJ
BlueJ does the same for Java. It gives a graphical representation of classes and objects in the student's program. It also allows editing and interaction with the program constructs through both graphics and text.
The IDE is clean and straightforward. It's possible to get right to work without spending a lot of class time on the IDE itself, or spending time outside of class configuring the IDE (which is my experience in trying to use Eclipse and NetBeans. They're great for more experienced programmers, but not so great for beginners, especially in the classroom, unless heavily configured first.)
BlueJ's graphical mapping features are fantastic. They make it very easy to visualize subjects of discussion in class, and they make the whole object paradigm make more sense to beginners. I was concerned that they would form a crutch that would keep the students from being able to work with objects and classes without the graphics. This hasn't been a problem for me in actual use, however.
My only complaint about BlueJ is that it's tied to Java. I would like to be able to use it on the parts of my class that don't use Java, particularly with HTML/CSS. However, it's easy to change from another simple IDE that does handle HTML/CSS (like Arachnophilia) to BlueJ.
Among the things I particularly like about BlueJ is how nicely it ties documentation into the development process. Getting new students to take advantage of Java's documentation is frequently a hurdle. BlueJ ties in documentation, both the standard documentation and the use of documentation within program comments, from the very start. Having students write their own documentation as they go, and seeing how it ties upward into the standard documentation makes this all very easy.
I haven't used the Objects First book for BlueJ in my class, I have only used BlueJ with other texts, including Beginning Programming in Java for the Absolute Beginner. This hasn't been a problem at all, though. I also haven't made much use of the resources available through the BlueJ site, but since I am considering teaching without a text, using only my own material and material available online in this upcoming year, that will probably change.
BlueJ is simple, clean, and magnificently tuned. It's a joy to use in class, particularly in a mixed platform lab. If you teach introductory programming courses, I highly recommend it.
Subscribe to:
Posts (Atom)
Posts
Webomator.com: Backward into the