| By Blair Wyman | Article Rating: |
|
| March 1, 2003 12:00 AM EST | Reads: |
16,118 |
Okay, I'll risk my career and admit it: I not only know how to draw a flowchart, I still find myself using them from time to time.
I have one of those little green plastic flowcharting templates to help draw the symbols and arrowheads, but I don't use it much anymore. (I don't like to take it out of its climate-controlled vault; the chill might warp my precious slipstick.)
I'll bet a few of you are smiling wistfully right now, secretly yearning for The Days of Boxes and Green Plastic: the expansive surfaces of glistening unblemished flowcharting paper, each patterned page awaiting its chance to represent pure logical art. What mere "problem" could possibly withstand our iterative onslaught of ink and thought? Get thee behind me, General Ledger!
Yes, they were simpler days, or perhaps it was just me who was simpler. Ah, but those first tastes of process abstraction (imposing order upon thought, what a concept!) were just too alluring.
My first exposure to flowcharts wasn't until college. I know for a fact that I was much simpler then, but fortunately so were the programming problems I faced. There always seemed to be a way to get that virtual boxcar attached to the virtual train without having to lift it off the virtual tracks. No list went unlinked, no record went unwritten, and no parameter went unpassed, by value or by reference. Simpler days, indeed...
When I look back at my proudest individual programming achievements, I can't help but start with that first college-level Pascal programming course. The instructor was meticulous and unwavering: no global variables without solid justification (which meant no global variables), all local variables descriptively named and declared alphabetically, and every procedure well begun with a standard commentary prologue.
That's how they lure you in. "Come on! Here! Impose order on an unruly universe... You can do it!" Yes, that was my first foray into flowcharting, and something in me changed.
I remember rushing to my then-future wife one bright summer day, waving my multipage fanfold printout, and proudly exclaiming, "Look! This Pascal assignment took over a HUNDRED LINES of CODE! Isn't that AMAZING!?" She smiled, and I fell in love (which is the only hard proof in existence that I do, in fact, have moments of brilliance).
Next it was a thousand lines of this and a thousand lines of that logistic equations, with variable zooming, grid lines, and decimal input fields; fractal monster functions, continuous yet nowhere differentiable; images of reality that no one in the history of man could ever have seen in the days before transistors on silicon. I came to know the Turbo Pascal graphics library by heart. Programming these ugly beige boxes to display such unfathomable beauty was reaching deep into the viscera of the silicon beastie and twisting. I liked it. I was hooked on programming.
Then I got a job, and it was my guts' turn to be twisted... "Oh, Mandelbrot sets are fascinating and beautiful and all, but we really need that big honkin' component test plan you promised us. Okay?" The joy of individual, top-to-bottom programming just for the fun of it was still there, but there was also a different, even better, kind of joy: the joy of contributing to something much, much larger.
My first big chance to prove myself part of the team was during the development of a new optimizing compiler back end for our box. The theory of compiler front and back ends was new to me then, though its simple elegance was instantly compelling.
The idea is simple: separate the compilation process into two phases a "front end" and a "back end." The front end converts source code to an "intermediate representation" (IR) a form that completely and unambiguously represents the form and function of the compilation unit, but which does not presuppose any particular hardware configuration. Then, a compiler back end gets involved, and converts the IR into optimized, hardware-specific instruction streams and data structures.
The sweet part is this: any software that can be compiled into a given IR will run on any hardware that has a matching back end. Now, if this sounds familiar, it should. It's arguably the very heart of the write-once run-anywhere promise of Java.
At the front end, we have javac, Jikes, or anything that generates proper bytecode. (There is at least one RPG-to-bytecode compiler, for instance.) The IR, of course, is the classfile format. The back ends are the various JITs, AOTs, and true interpreters that make our JVMs work so well.
Imposing order upon thought... What a concept! Maybe those boxes and arrows and diamantine decisions led somewhere after all.
Published March 1, 2003 Reads 16,118
Copyright © 2003 SYS-CON Media, Inc. — All Rights Reserved.
Syndicated stories and blog feeds, all rights reserved by the author.
More Stories By Blair Wyman
Blair Wyman is a software engineer working for IBM in Rochester, Minnesota, home of the IBM iSeries.
![]() |
Russell Kneebone 03/06/03 12:51:00 PM EST | |||
How about using a compiler to shift boxes? I notice that the tables have turned with respect to the availability of IBM's VisualAge compilers on Intel and PowerPC. It used to be that to compile a C++ program for OS/400 you used a "co-operative" compiler that presumably created the intermediate representation via the Intel compiler then ran a PowerPC backend compiler to target OS/400. Nowadays the version 6.0 of VACPP is only available for PowerPC (AIX and Linux), with the Intel versions ceasing at 4.0 (Windows and OS/2). Surely IBM has it within their power to allow the Linux verion of the compiler to run on an iSeries LPAR, use the integrated X-Series server card to communicate to an Intel backend and co-operatively create Windows and OS/2 executables. Just think of the box shifting power! A VisualAge diehard would have to replace the $600 program that used to run on any brand of PC with a largish iSeries, an expensive add-in card, an expensive compiler plus the co-operative feature. This is the way to shift boxes! Russell |
||||
![]() |
Mark Pardue 03/04/03 07:36:00 PM EST | |||
Many objects that are programmed in Java (or any other OOP) will have complex methods beyond set's and get's. Anytime these methods get beyond a few lines of code, I (and other programmers I've worked with) do some type of flow charting to establish the logic to be used, and at times to explain what's going on to our peers, managers, and/or customers. These flow charts tend to complement the state diagrams and sequence diagrams of UML and serves a critical need in many cases. The real difference in top-down programming between OOP and the old procedural languages seems to be that with OOP you start with objects (class diagrams et. al.) and their properties/interactions. With procedural languages, you start with the flow chart of what you want to accomplish with the program. |
||||
- Cloud CEOs, CTOs & SVPs to Speak at 4th International Cloud Computing Expo
- Kindle 2 vs Nook
- Why IBM’s Server Chief Got Busted
- The Difference Between Web Hosting and Cloud Computing
- Cloud Computing Journal Opens "Readers' Choice Awards" Nominations
- Cloud Computing Expo: Exclusive Q&A with Yahoo! SVP Cloud Computing
- Industry Experts Discuss the State of Cloud Computing
- Ajax in RichFaces 3.3, JSF 2 and RichFaces 4
- It's the Java vs. C++ Shootout Revisited!
- The End of IT 1.0 As We Know It Has Begun
- An Introduction to Abbot
- Java Kicks Ruby on Rails in the Butt
- Interviewing Java Developers With Tears in My Eyes
- Cloud CEOs, CTOs & SVPs to Speak at 4th International Cloud Computing Expo
- 1st Annual Government IT Expo: Call for Papers Deadline July 15
- How to Diagnose Java Resource Starvation
- REA Is Where RIA Becomes the Norm
- Kindle 2 vs Nook
- Anatomy of a Java Finalizer
- Why IBM’s Server Chief Got Busted
- A Cup of AJAX? Nay, Just Regular Java Please
- Java Developer's Journal Exclusive: 2006 "JDJ Editors' Choice" Awards
- The i-Technology Right Stuff
- JavaServer Faces (JSF) vs Struts
- Rich Internet Applications with Adobe Flex 2 and Java
- Java vs C++ "Shootout" Revisited
- Bean-Managed Persistence Using a Proxy List
- Reporting Made Easy with JasperReports and Hibernate
- Creating a Pet Store Application with JavaServer Faces, Spring, and Hibernate
- What's New in Eclipse?




























