I made travel arrangements for Barcamp in Harrisburg. (Barcamp in Baltimore seems to be... dormant.) The Harrisburg Barcamp should be fun! At least the travel will be fun, as I can go by train.
I also registered for Balticon, the science fiction convention. (It runs just north of Baltimore every Memorial Day weekend.) Balticon has sessions for science fiction, hard science, and writers, which leads to an interesting mix of attendees. I always find clever people and interesting conversations.
This weekend I posted my first project to github. (github is a "clearinghouse" for git-based projects, allowing others to access them.) It was easier than I expected, which was a pleasant surprise. I don't know that "powerful" is the right word to describe github, but they are well-positioned for the sharing of software. I'm not sure about the word "leveraged" either. Perhaps "well-positioned" is the right phrase.
Sunday, February 26, 2012
Wednesday, February 22, 2012
Better than FORTRAN
Sniffles and sneezes kept me home. I spent most of the day resting. Yet I had a little time to build an interpreter for the original BASIC language, and I learned a lot.
Writing an interpreter (or a compiler) forces one to learn the language. All of the language, not just the convenient bits. My exercise forced me to learn about BASIC and think like the original designers of the language.
I looked at the original BASIC, also called "Dartmouth BASIC". It is a simpler version of the Visual Basic we know today. There is a limited command set and variable names are much shorter.
I implemented a fraction of Dartmouth BASIC. I'm calling my implementation "BASIC-1965", in reference to the year in which I think it would have been initially implemented. It is Dartmouth BASIC without the matrix operations and constraints on the use of expressions. In Dartmouth BASIC, expressions may appear in LET, PRINT, FOR, and IF statements; in my version, expressions are restricted to the LET command. (That may change in the near future.)
Another change is the position of DATA statements. In the original BASIC, DATA statements may appear anywhere. In my "BASIC-1965", DATA statements are truly interpreted and must appear prior to the corresponding READ statements. (The fact that DATA statements could appear at the bottom of the program always bothered me.)
My implementation is in Ruby, which performs a lot of the "heavy lifting". Ruby has data containers and regular expressions, both of which made the task easy.
I can see how BASIC was better than FORTRAN: no FORMAT statements, no worries about integer or floating point variables, and interaction with the computer. It *was* a significant increase in usability.
Writing an interpreter (or a compiler) forces one to learn the language. All of the language, not just the convenient bits. My exercise forced me to learn about BASIC and think like the original designers of the language.
I looked at the original BASIC, also called "Dartmouth BASIC". It is a simpler version of the Visual Basic we know today. There is a limited command set and variable names are much shorter.
I implemented a fraction of Dartmouth BASIC. I'm calling my implementation "BASIC-1965", in reference to the year in which I think it would have been initially implemented. It is Dartmouth BASIC without the matrix operations and constraints on the use of expressions. In Dartmouth BASIC, expressions may appear in LET, PRINT, FOR, and IF statements; in my version, expressions are restricted to the LET command. (That may change in the near future.)
Another change is the position of DATA statements. In the original BASIC, DATA statements may appear anywhere. In my "BASIC-1965", DATA statements are truly interpreted and must appear prior to the corresponding READ statements. (The fact that DATA statements could appear at the bottom of the program always bothered me.)
My implementation is in Ruby, which performs a lot of the "heavy lifting". Ruby has data containers and regular expressions, both of which made the task easy.
I can see how BASIC was better than FORTRAN: no FORMAT statements, no worries about integer or floating point variables, and interaction with the computer. It *was* a significant increase in usability.
Saturday, February 11, 2012
Various tech of the week
This was a fun week with varied tech. I worked on several projects, bouncing from one to the other as time allowed (and as questions were answered).
C++: I found and fixed one problem, which lead to a number of changes to the output. Some were obvious and expected, others were not. I traced the execution to identify the path from our change to the modified output. Visual Studio is quite good at debugging and examining values, yet I had to supplement it with custom-written logging routines. (The amount of data was larger than I could hold in my head, and some values are hidden from the debugger.)
C#: This was refactoring code to break classes into separate but corresponding 'mutable' and 'immutable' classes. The mutable classes become builder classes (such as ClassNameBuilder) and the immutable classes retained the original name. The division into two classes helps organize the code, and also reduces class size. A win all around, I think.
PDF: Format PDF files and add bookmarks. Perhaps not programming -- I'm not parsing or generating the raw PostScript or PDF files -- yet it was a fun diversion.
Perl and HTML: This was a fun, short task. We had to extract text from an HTML file, adjust the text, and then format the text back into HTML (albeit a different set of HTML). Perl's HTML::Parser class did the heavy lifting of extracting the text, and then it was simple to adjust and re-HTML-ize the text.
Ruby and GraphViz: I was back at the "web site links vizualizer" this week, enhancing the program and fixing some problems. It now grabs the web site files, extracts the links, and builds a GraphViz script for rendering into an image. (GraphViz supports multiple image formats, and we can pick whichever we desire.) Ruby's 'openuri' and 'hpricot' packages helped here, handling the parsing of HTML. (There are lots of HTML parsers available; perhaps I will never have to parse HTML again!)
C++: I found and fixed one problem, which lead to a number of changes to the output. Some were obvious and expected, others were not. I traced the execution to identify the path from our change to the modified output. Visual Studio is quite good at debugging and examining values, yet I had to supplement it with custom-written logging routines. (The amount of data was larger than I could hold in my head, and some values are hidden from the debugger.)
C#: This was refactoring code to break classes into separate but corresponding 'mutable' and 'immutable' classes. The mutable classes become builder classes (such as ClassNameBuilder) and the immutable classes retained the original name. The division into two classes helps organize the code, and also reduces class size. A win all around, I think.
PDF: Format PDF files and add bookmarks. Perhaps not programming -- I'm not parsing or generating the raw PostScript or PDF files -- yet it was a fun diversion.
Perl and HTML: This was a fun, short task. We had to extract text from an HTML file, adjust the text, and then format the text back into HTML (albeit a different set of HTML). Perl's HTML::Parser class did the heavy lifting of extracting the text, and then it was simple to adjust and re-HTML-ize the text.
Ruby and GraphViz: I was back at the "web site links vizualizer" this week, enhancing the program and fixing some problems. It now grabs the web site files, extracts the links, and builds a GraphViz script for rendering into an image. (GraphViz supports multiple image formats, and we can pick whichever we desire.) Ruby's 'openuri' and 'hpricot' packages helped here, handling the parsing of HTML. (There are lots of HTML parsers available; perhaps I will never have to parse HTML again!)
Subscribe to:
Posts (Atom)