With a full-time job, I have little time to work on the career. What to do? I try and complete one big thing each day.
Yesterday I signed up with dropbox.com and installed the synchronization software on all (except two) computers. The sign-up was easier than I expected. Using the software is easier than I expected. All in all, a win!
Today I changed the scripts for BASIC-1965. I now have a 'master' script that runs all tests, and tests scripts for specific cases. I have one test case. It is a small accomplishment, but getting the 'master' script in place is an accomplishment: I can easily extend it with more test cases.
Tuesday, March 20, 2012
Thursday, March 15, 2012
App Engine and goals for BASIC-1965
I attended the Capital Cloud user group meeting tonight. The talk was on Google's App Engine, and it was a decent talk. But as usual, the best part of the meeting was talking with other folks. I chatted with a few and had the opportunity to explain cloud computing (at least my "take" on it) to some non-developers.
In other news, I have a specific goal for the BASIC-1965 interpreter. I've been working on this interpreter for several weeks now, on and off. (Mostly off.) My general goal is to implement an interpreter that will conform to the description in Kemeny and Kurtz's book "BASIC PROGRAMMING" from 1967. But better than a general goal, I thought of a specific goal. A specific goal is a good thing for me; it gives me a definite target.
My specific goal: write a program (in BASIC) that will print a Fahrenheit-to-Celcius conversion chart.
The goal may sound trivial, yet I find it appropriate. Such an exercise was common in the early BASIC texts, and it is within the capabilities of the (quite limited) language of BASIC-1965.
So now all I need is some time!
In other news, I have a specific goal for the BASIC-1965 interpreter. I've been working on this interpreter for several weeks now, on and off. (Mostly off.) My general goal is to implement an interpreter that will conform to the description in Kemeny and Kurtz's book "BASIC PROGRAMMING" from 1967. But better than a general goal, I thought of a specific goal. A specific goal is a good thing for me; it gives me a definite target.
My specific goal: write a program (in BASIC) that will print a Fahrenheit-to-Celcius conversion chart.
The goal may sound trivial, yet I find it appropriate. Such an exercise was common in the early BASIC texts, and it is within the capabilities of the (quite limited) language of BASIC-1965.
So now all I need is some time!
Labels:
app engine,
BASIC,
celcius,
cloud computing,
conversion,
fahrenheit,
projects,
user groups
Monday, March 12, 2012
Ruby vs. C#
I've been working with C# on the day job and Ruby on a side project. Shifting between the two has been enlightening.
C# is a statically typed language; Ruby is dynamically typed. I have come to rely on statically typed definitions, so I am a decent coder in C#.
I find that the coding experience in Ruby is quite different. I cannot rely on the IDE to tell me when I have assigned an improper value - in Ruby one can assign anything to any variable. It is easy to forget the type of variable and assign the wrong thing; I find out only at runtime, usually with an error of "undefined method (methodname) for (classname)".
To get things right in Ruby, I must be more disciplined in my thoughts and in my programming. I'm not sure that this is a bad thing... I'm also not sure that this is a good thing. At the moment, I know only that it is a different way to program.
C# is a statically typed language; Ruby is dynamically typed. I have come to rely on statically typed definitions, so I am a decent coder in C#.
I find that the coding experience in Ruby is quite different. I cannot rely on the IDE to tell me when I have assigned an improper value - in Ruby one can assign anything to any variable. It is easy to forget the type of variable and assign the wrong thing; I find out only at runtime, usually with an error of "undefined method (methodname) for (classname)".
To get things right in Ruby, I must be more disciplined in my thoughts and in my programming. I'm not sure that this is a bad thing... I'm also not sure that this is a good thing. At the moment, I know only that it is a different way to program.
Friday, March 9, 2012
.NET and Ruby
This week I attended the local CMAP meeting, with its presentation on SQL in Azure. I learned a lot; SQL in Azure is different from SQL in the server room due to the "can move at any time" aspect of cloud computing. The differences are not particularly large, but can be significant (especially if you have built your system around one of the server room idiosyncrasies).
The CMAP meetings are consistently good for networking. They draw a sizable collection of people, and the attendees have varied projects and talent. I always have interesting conversations at them, and this month's meeting was no exception.
Later in the week I worked on my side project of BASIC-1965, an interpreter for BASIC written in Ruby. It's a fun project and a learning experience. Ruby has a different approach to programming, and my Java- and C#-trained brain is making mistakes as a learn "the Ruby way".
The CMAP meetings are consistently good for networking. They draw a sizable collection of people, and the attendees have varied projects and talent. I always have interesting conversations at them, and this month's meeting was no exception.
Later in the week I worked on my side project of BASIC-1965, an interpreter for BASIC written in Ruby. It's a fun project and a learning experience. Ruby has a different approach to programming, and my Java- and C#-trained brain is making mistakes as a learn "the Ruby way".
Labels:
Azure,
BASIC,
cloud computing,
networking,
Ruby,
SQL
Sunday, February 26, 2012
Barcamp, Balticon, and github
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.
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.
Labels:
balticon,
Barcamp,
github,
Harrisburg,
science fiction conventions
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)