Software Engineering Class Projects

I’m still debating the best project for this semester’s class project. We’re probably going to have 10-12 people per team, with two competing teams.

Some of my current thoughts:

  • Cross-Platform Synchronizing Chore management system
  • Software Tool/Environment for teaching children to program

The chore management system is needed around our house, and we have a group of external customers (my family). We have used ChoreMonster in the past, but they started charging subscription fees, and I think that’s completely ridiculous for the functionality.

A tool for teaching programming would be more widely used, but is a much harder, less tractable problem. On the other hand, a campus renown for its teaching program might be just the place for such a project (not that the last semester’s class used those resources).

Spring 2014 Courses

This semester’s schedule is going to be interesting:

  • ITEC 325 – System Administration
  • COSC 412 – Software Engineering
  • COSC 485/670 – Reverse Engineering / Malware Analysis

The reverse engineering class is a new one, and I’ll be dusting off some old-school skills to pass along to a new generation. This is either going to be lots of fun, or really painful.

BasicTeX 2013

Well that didn’t take long. Only 1 month after the release of BasicTeX 2013, I find myself in need of a new package. The TeXLive repository has already deprecated all of the 2012 pacakges, so I’m off and running installing BasicTeX 2013.

This year the steps are mostly the same, with the addition of more packages as I’m continuing my use of LaTeX apace.

  1. tlmgr uninstall
  2. download and install the current BasicTeX package from tug.org
  3. update PATH environment variable to include the current install location: /usr/local/texlive/2013basic/bin/universal-darwin
  4. tlmgr update --self
  5. tlmgr update --all
  6. tlmgr install collection-fontsrecommended
  7. tlmgr install subfigure
  8. tlmgr install exam
  9. tlmgr install algorithms
  10. tlmgr install lastpage
  11. tlmgr install paralist
  12. tlmgr install enumitem

You can find the documentation for algorithms, lastpage, and paralist on CTAN.

BasicTeX 2012

I just upgraded to BasicTeX 2012, and here’s a quick synopsis of the steps:

  1. tlmgr uninstall
  2. download and install the current BasicTeX package from tug.org
  3. update PATH environment variable to include the current install location: /usr/local/texlive/2012basic/bin/universal-darwin
  4. tlmgr update --self
  5. tlmgr update --all
  6. tlmgr install collection-fontsrecommended
  7. tlmgr install subfigure
  8. tlmgr install exam

The Exam package is new (chalk it up to the new job), and the impetus for the updated install. The rest of the steps are really based on my previous TeX posts: here and here.

Node.js

Just started looking at node.js, and I have to admit I think it looks really useful. So far it seems lightweight and pretty powerful with less mental baggage than some other languages I’ve seen lately.

Anyone have a recommendation for a (canonical) project I should implement to get my feet wet?

My (long) note to the creator of Sierra

I’ve spent the evening trading e-mail with the creator of Sierra. Please forgive the lack of context, but I’m posting my last reply, since I think it sums up my thoughts on the language well.

Ok, I’ll shift my focus from Sierra as implemented to your stated higher level goals for the purposes of trying to illuminate my points.

As background I skimmed EWD340, not having read it in 20 years, and a couple of Milner’s papers contemporary to the IFIP paper since I don’t have a copy of that handy at the moment. You weren’t specific on Dr. Hoare’s work, but I’m relatively familiar with a large portion of it.

I think it’s somewhat disingenuous to talk of a real-time bug checker, since the vast majority of bugs that are hard to find belong to the second class of programming faults described by EWD, those that there is no proof of mechanical recognition. Indeed, even though his specific example ( loop completion, now a subset of fixed point determination) is a much better understood problem, it is not deterministically possible to predict the outcome (the halting problem). Nor are you correct in your assertion that one has to wait until compile-time for existing languages to find bugs. Static analysis can and has been integrated into IDEs (Kleidermacher; 10.1109/THS.2008.4534479).

I can’t address the specific 1986 paper from Milner, but as a general situation, it appears that he was interested in formal abstractions of what code does as opposed to natural language programming per se. Since the problem of natural language programming is itself a composition of natural language processing (an open problem) and automatic proof building (also an open problem), I going to assume that you intend to approach the problem of correct code from the perspective of formal abstraction. In that case, it’s pointless to talk about the Algol derivative languages since much more modern pure languages are at our disposal. Haskell (which implements Hindley-Milner type inference) would be a much better launching point, but I think many of the problems you seek to solve are non-issues in Haskell. The difficulty of programming in Haskell stems from the need to express human thought as a formalism.

This leads to your interest in cutting C in half. Haskell accomplishes this by removing much of the overhead of Algol derived languages, but the result isn’t human readable.

Fibbonacci in Haskell:
fib n = fibs (0,1) !! n
where fibs (a,b) = a : fibs (b,a+b)

This is neither easy to read, nor immediately intuitive (though admittedly it would be hard to have a significant logic bug in this code).

Sierra as it exists today isn’t a level above existing code since it doesn’t significantly vary from C. That example I sent earlier is neither terser or more readable than the equivalent C code. Nor does much in your existing specification show progress towards more intelligible code. While I understand that this represents a first step, it is essentially a step *backwards*. “var” was implemented and discarded by Wirth in Pascal. Operator overloading (+ as addition and concatenate) was tried and discarded in C++. “y@myPixel” is neither better nor worse than myPixel.y, but having both is confusing and neither implies that y is a property of MyPixel.

Many languages have obviated the need for C pointers and direct memory management (see Java, Haskell, etc). In fact, it is possible to have a reasonable garbage collector for C (Boehm, Spertus, WG21/N2310=07-0170). Nor is verboseness particularly a problem (EWD said as much in ’72), human communication is terribly verbose with low S/N and lots of redundancy to make up for it. Nor do I think there is a compelling case that interactivity can improve the situation.

You speak of “higher up” than “traditional languages”, but the truth is that you still seem to be generating a 3GL language without even addressing the existence of domain-specific and constraint based languages (4GL and 5GL respectively). Indeed most new language development seems to be integrating 3-5GL into comprehensive systems. Frameworks like Hadoop have us programming across large-scale distributed systems, They’ve abstracted away the idea of a single execution thread or even a single computer, and they hide the network/memory/latency issues in ways that I don’t think you’ve even considered.

I just saw a blurb about “Julia” (http://julialang.org/), which appears to be an attempt to be most things to most programmers. I don’t know anything beyond the press release, but frankly they at least are hitting all the right notes.

And I think this is the fundamental problem with your pitch for Sierra (here and during the last 3 years). Your approach and materials seem to have ignored the last 25 years of programming language research and development. Whether the end product is compelling or not is impossible to judge because what I can see of it today doesn’t seem well informed. I took the time to read some of the trials and tribulations you seem to have suffered in trying to bring Sierra to market, and while I feel for your struggle, I wonder if you ever had competent technical advice. Your existing demo tackles the problem from the wrong level. You’re taking a bottom-up approach to developing Sierra (which is appropriate), but there doesn’t seem to be a top-down roadmap for the language. I have asserted that you seem to have moved backward from C, and without seeing where you’re going I have no way of assessing otherwise. General assertions that there are higher-level, fuzzy logic components in the future have the ring of SHRDLU (Winograd, MIT AI Technical Report 235, February 1971). It’s 40 years later, and I don’t think we’ve made much progress with that project either.

So maybe that’s my advice to you. Get a roadmap together. Let’s see a architecture overview for Sierra. Let investors (Kickstarter and VC) know that you’re aware of what has been tried, and have concrete ways to do better. At this point, it’s not about the code, it’s about the path.