Focus on completing SICP or development?
I am about halfway though chapter 2 of SICP and doing the majority of the problems, and have been distracted by small things more related to development. Should I focus on wrapping up SICP or should I focus on designing a rough product, putting it on the web, and selling it?
Long version: I am currently working as a mechanical engineer and am sometimes doing coding projects for work, and often doing small coding projects part-time. The coding projects I have worked on are mainly things I worked on while on company time for specific projects, and thus I do not believe I own the rights to them.
I would love to launch a project with the potential to sell it online.
My coding background:
I coded for the first time when I was less than 10 years old, and this mainly consisted of BASIC code. In my teens, I made a website with html that I hand-coded (frames and all) for a game that I was playing at the time. The only programming course that I took while in college was c++. I have been using Matlab/Octave on a continual basis since entering college about 8 years ago.
More specifically, I have created the following: In Java - I was in a PhD program and I worked on some Finite Element Analysis code that my professor created in Java. Before I dropped the program, I had added a module for a specific, relatively complicated composite element.
In C++ - I created a mechanical linkage simulator that would compute mechanical advantages, stresses, and deflections given design parameters (mainly geometry). More recently, I created a program to determine a system response to a power spectral density. (Basically, I have a mechanical structure and I shake it with a simulated rocket launch to determine the accelerations that the system responds at)
In Python - I ported the mechanical linkage simulator to Python because it was much easier to make a simple GUI in Python. I then modified the program enough to animate the opening/closing motion and to change geometry. (it was a simple outline and line drawing of the linkage)
In Octave - Most recently, I created a program that simulates combustion, gas flow, and heat transfer in a tightly coupled system that could really help my current employer.
In Scheme - No projects other than those problems in SICP.
Most of my projects have been text-based because I have been one of the only users of the program, except for that ported program in Python. I'm somewhat worried about making the most recent simulation program into an outside-of-work project of mine (generalizing it, giving it a real GUI and some graphics) due to intellectual property issues. I have come up with a few ideas not related to my work aside from this, but I'm concerned about the small potential market of specialised engineering programs.
As for what has distracted me from SICP, I decided to set up an old desktop I had laying around as an Ubuntu server, putting LAMP on it, and starting to work through another book on the basics of web design. I have also figured out a way to not only SSH into my server from my cellphone, but also access Emacs and I've written a few hello world programs in Scheme/C++ using my phone and ran or compiled them remotely in the same manner.
I've started to re-evaluate my focus and desires due to reading "Creating" by Robert Fritz, and I suppose that I don't have a specific path to go down. I wouldn't mind working on a project that has potential (either an idea I conjure up or someone else's) part time, but my current job is in a relatively remote/non-tech region. It's been somewhat difficult for me to get over the clean slate in front of me to create something on my own unrelated to work, even though I know that I have the capability to create just about any tool I would use at work, given enough time.
Any advice would be appreciated.
4 comments
[ 0.35 ms ] story [ 18.7 ms ] threadPretty obviously you should work your way through chapter 3, and you owe it to yourself to discover the coolness in 4.1 at some point. And then if you want to do Clojure, Haskell or other languages with laziness that sets you up for SICP's introduction in 4.2.
4.3-4 get into research areas Sussman did in times past (don't know about Ableson), chapter 5 is one of many useful introductions for how things work all the way down to the metal. Someday, you can be pretty sure you'll be damned glad you learned that level of material, although studying it from a C centric perspective is also useful since it's so ubiquitous.
Anyway, have fun and I wish you luck on your projects.
Is it C itself that is important, or just the concepts? Most of the concepts seem to be contained in what I learned when I took C++ (and have used on some projects). For example, function pointers made one of the projects I was working on very simple.
I have a copy of K&R laying around that I haven't worked through, and thumbing through it seems pretty similar to what I saw in C++.
I tested myself earlier today while on a layover by SSHing into my server and trying to make some simple C++ code to play with pointers, but since I didn't have the reference I couldn't debug a situation where I was dereferencing a pointer... Maybe I'll look into that a bit if I end up needing a similar feature.
I'm torn a bit on exactly what language to hit the ground running with, as far as building actual products. Clojure looks interesting, but I also haven't decided if I want to make something platform-independent and running on the JVM or not, or go all the way with SBCL (and the help of PG's and Peter Seibel's books).
I think I'm letting myself get paralysed by too many options (although certain ideas of mine are MUCH easier to do in a Lisp).
I'm talking about the sorts of things taught in this CMU class and its associated book: http://www.cs.cmu.edu/~213/ which includes stuff below the level of C which you should learn, e.g. two's complement arithmetic (fixed point integers), IEEE floating point bit layouts, etc.
You don't need to get as hard core as the CMU course/book, but if you know some of these basics, have some idea of how GC works down to the level of pointers etc., you'll be in the long run happier for it.
And, yeah, it's easy to get overwhelmed by options.
Common Lisp is old, more than a bit crufty (it's mainline LISP going back to the first versions), but there's lots of good stuff out there if you're willing to tinker a bit (and perhaps the latest effort at providing a common library is going to work). It's biggest problem it that it was frozen in amber in the '80s, well before anyone thought to standardize networking or rather critically concurrency plus other stuff (does it have a Unicode story???).
Scheme is pure and has been extremely slow to standardize; the most recent attempt to fix that (R6RS) met with massive rejection and who know's what's going to happen next (well, actually I haven't been following it due to the next and last option). It's great for eduction and language research and development (e.g. Javascript is largely Scheme semantics with a C face and a prototype based object system).
Clojure is exciting, watching it right now it like watching the middle phase of the Lisp Machine's development except that I think it's just past the stage of serious breaking changes. Things are rough around the edges but a whole lot of people believe it's the future of Lisp. It also is by far the most functional of these three.
Common Lisp is so old it had to be multiparadigm (e.g. PROGN and the LOOP macro), Scheme can be programmed functionally but Clojure enforces it a lot more strongly and makes it fast due to a recently developed data structure that largely solves the functional programming trivial update problem.
And that allows it to tackle what I find to be the most interesting language problem, multicore single address space concurrency. It's sufficiently functional to allow STM to work (which is generally impractical to bolt onto an imperative language), plus it has several other mechanisms, all of which can take advantage of the immutability of its basic data structures.
And the biggest advantage in getting real world things done today is its Java interoperability which is efficient and allows you to use all these Java libraries people have been developing for a decade and a half. Being able to take advantage of what is perhaps the healthiest ecosystem (although, granted, not for the number crunching of science and engineering) is a big win.
On the other hand, it does drive up the complexity of what you have to learn and deal with, and has twisted the language a bit here and there.
Depending on what you want to do going with either Common Lisp e.g. SBCL or Clojure should do you well.
And, yeah, a whole bunch of things are easier to do in a Lisp. There's a reason it's the second oldest surviving computer language, after FORTRAN.