Ok, so I want to learn to write programs that run on the empeg. I'm looking for some advice and some info but I'm actually not really where to start with these questions, so I'll just babble a bit.

First of all, I'm a freshman in college on my way to becoming a CS/EE double major. The comp sci course I'm in the middle of right now is described as "An overview of advanced data structures and analysis of algorithms, data abstraction and abstract data types, object-oriented programming, proofs of correctness, complexity, and computability." Basically we're learning about stuff like inheritance and binary trees and the like. Basic C++.

The main hurdle I have is that although I can write some pretty good C++ code I have no idea how to interface with the empeg. Besides the fact that we code and compile remotely on UNIX machines (for comp sci courses), I have zero experience with Linux and no experience with large projects. Is there any FAQ/instructions that would help me compile a short hello world type program for the empeg? If I am going to get serious about this I'm going to need a Linux partition on my hard drive, huh? (I should probably do this just to learn about Linux.)

What about instructions to interface with the hijack menus (This can wait 'till later) Where is the source to hijack? All I see is the patch file which has all the crazy diff-generated character stuff in it.

(By the way why does it seem like there is c stuff lurking around (printfs, printks, malloc, memcpy, etc? Isn't most of the stuff written in C++? Am I going to need to learn C?)

At this point everything is a little over my head. But what should I do now to better prepare myself to do cool stuff in the future? My course next fall is described as "Techniques for design and construction of reliable, maintainable and useful software systems. Programming paradigms and tools for medium to large projects: revision control, UNIX tools, performance analysis, GUI, software engineering, testing, documentation." That should give me a little more experience with this stuff.

I don't really have too much time with school and all (I'm a Warcraft III beta tester, different topic), but I find this stuff fascinating and want to get involved at some point, even if its later. Thanks for ya'lls help,

John

Isn't most of the stuff written in C++?

The player is written in C++, the kernel (to which you've got the source) is written in C.

The source for Hijack is the Linux kernel source, with those patches applied. Mark distributes just the patches, because they're smaller, and getting hold of the kernel source is easy.

As far as developing for the empeg, check out the resources at riocar.org

It seems strange to me that you are studying C++ rather than C in a CompSci/EE double major. You will find that most embedded programming is still done in C for various reasons.

Firstly, C is more standardized than C++, which increases the odds that the compiler for your chosen target archhitecture works correctly.
Secondly, C generally produces more predictably sized code which is better for embedded systems.
Thirdly, C generally produces code with more predictable latencies.
There are other reasons too, but these are the 3 biggies.

The linux kernel is still written in C, so if you want to get into linux kernel hacking you will need to learn C.

At the introductory levels, EE and CS don't overlap as much and the compsci major (at Duke) is based in C++ (although you can start it in java, kind of). So thats why I'm taking C++.

I think I'm going to partition my hard disk and install linux. It will be a good learning expirience and I can program locally instead of on the university's servers. I'm thinking I'll go with Red Hat (since I'm a beginner) unless it would be better to go w/ debian because that's what the empeg uses.

At this point I'll leave the the kernal hacking to Mark and others and I'll write in what I know, C++. I'll probably learn C in my oh-so-extensive spare time later. Any other insight is appreciated.

I have absolutely no idea, why comp-sci courses have switched to java as the introductory language.. Other than making it easier to teach non-computer people how to program, it glosses over some important things about computer programming, namely the computer. The problem that most universities have, is that they want to teach all of the design, and none of the implementation.. So 4 years of java gives you all of the design (basic loops, data structures, algorithms, etc) but ignores teaching how programs actually work. I was fortunate and took courses at all levels, as well as different types of languages, so I feel I atleast know why some languages work better than others..

What I find funny, is that when I took a 1 credit java course, I found it easy.. now some friends of mine still in school are taking the 1 hour C course for java programmers, and are having a tough time..

Moral of the story, stick with C++.. learning C from C++ is easy.. learning Java is easy.. going the other way is sometimes tough..

Yang, totally agree with that. Luckily I'm a self-taught C/C++ guy. Right now at Cal Poly SLO, they are also using Java for the introductory programming classes. One major thing I'd like to add that Java handles for you, memory allocation. Memory allocation was one of the, if not the hardest thing for me to grasp when I was learning C. All allocation is just skipped over in Java because you don't need it...

Others have answered many of your questions, so I just want to answer the general "what should I do to prepare for cool stuff in the future?" question. For everyone: knowing what you know now, what advice would you give yourself as a beginner?

Here are my thoughts, as someone who was a TA in CS courses for several years while in grad school.

1. As a beginner in a new area, we often think that if we could just get some help getting started, we could then continue on our own. But the problem is that that's just not true because that feeling _never_ goes away. There's always so much more to learn! Once you get good at the beginning stuff, you're only then able to appreciate how much is out there to learn. The more you advance, the more you can do. At any level, you're a beginner in the new world your skills enable.

So a better approach is to forget about trying to get over that "clueless beginner" feeling. Instead, realize that you already have a lot of usable knowledge--you just have to figure out how to apply it. And more importantly, how to find challenges to push against and grow.

2. So where is the knowledge of empeg? Three places: the heads of the people you can ask, the newsgroups and FAQs, and the code itself. Beginners tend to go in that order: ask first, study code later. But that's the frustrating and slow path that puts others in charge of your progress. Experts go in the reverse order. First study the code, then search newsgroups and faqs. Only if you're still stuck do you make yourself dependent on others.

Experts can easily tell when someone is asking a good question and when the asker is too lazy to look in the faqs, or worse, the asker is just trying to get someone to do their homework for them. Experts are good people to make friends with; having been through the beginner stages, they're usually generous with help. You make friends with them by not wasting their time with questions that you would know if you made a little effort before asking.

It takes great effort to write documentation. I am, and I know others are, quite grateful to Tony and Loren for making the effort to write faqs for empeg and Hijack. So much of what you need to get started is already there in the faqs.

Even with their great efforts, though, it's hard to keep up with a whole community of people contributing new code and projects. So the ultimate source of what you need is in the source code itself. By studying it, you'll learn not only how empeg and Hijack work, but you'll see great examples of how professional code is written. It may be intimidating at first, but that's part of learning--don't fight it. (Remember, you're always a beginner; there's always something you don't understand that feels intimidating.) So dive into the source code. Wander, skip, puzzle, play, imitate, change, fool around. I promise it will gradually yield to your efforts.

3. Finally, be careful to be too focused on looking for specific answers in class. Your coursework will try to teach you many things that seem irrelevant to you. But I think many us wish we had paid closer attention the first time around so we wouldn't have to relearn things later. The value of learning everything you can is that when you are confronted by a challenge, you'll have a great toolbox to apply.

This is a pretty friendly community--lot's of people will enjoy helping you and appreciate your contributions.

Let us know how we can help.

Gary

Heh.. The comment about always feeling like a beginner is definately true.. It only goes away when you stop thinking that you ought to be able to do everything, and instead focus on things that are achievable with the skills you have now.. I've had several projects in mind that I know I can't do right now, but I've decided to simply work on projects closer to reality and when the time comes when I have the necessary skills, I'll work on those projects I've been thinking about..

How is Java an "easy" language? The depth and breadth of detail depends entirely on the course material. I think Java is an excellent language to explore the practice of OO, loops, data structures, algorithms are secondary to that.

When I was going to Umich, a Comp engineering courseload might have included Java, but in other classes they had me coding compilers, tcp ip stacks, hand coding assembler, designing a CPU and hand coding it, adapting common solutions into parallel processing algorithms, writing games, etc. You can't shoot down the whole curriculum on the basis of one course. If the purpose of the course is only to teach introductory loops and structures in a safe environment, so be it. There will be other courses to deconstruct and understand the underlying nature of the machine. If the course is impressing OO design and practice early, then even better.

I remember back in the day when the professor adamantly insisted that it was not possible to code a fibbinaci's sequence algorithm in less than 11 assembler instructions. Most people submitted solutions of 15 to 40 instructions. I was happy enough to get it down to the "optimum" 11 instructions, when a lateral thinking fellow next to me "discovered" it was possible to for the program to overwrite its own instructions, and ended up submitting a solution in 7 instructions. It was pretty amazing then, but what pressing application would that have these days? I think going from a lower level to higher level languages can potentially carry over bad habits more so than going back the other way.

Calvin

I didn't say Java was an easy language.. I said it was easier to teach to non-programmers.. when I took my java course, I found it easy, but we never went any deeper than UI widgets and some list stuff.. Java is easier than C because you don't have to do %90 of the hard code which you are required to write when taking C courses. Teaching OO concepts is one thing, but when your education of b-trees is 'create btree foo' 'foo.addobject(bar)', what's the point unless you are going to be a professional Java programmer the rest of your life?

Having a intro to programming course for a comp-sci degree use Java is one thing, having all computer programming courses use Java is annother.. I'm not against Java, I'm just against using Java for things it has no business doing (like graphical applications.. )

My assembler prof had the same sort of experience.. we had to write a program to solve some magic number problem..
he said the limit was like 27 instructions.. someone did it in like 11.. (they kinda cheated, figured out the pattern and created a hash of the different solutions)

Going through my GoF Design Patterns a while back had me arrive at the relevation that all the underlying complexity is not necessary. Not everyone needs to have atomic comprehension of the underlying details in order to architect and construct. The design patterned future will strike a proper dichotomy between the design-patterned architect and the computer scientist and engineer.

I think someday, design patterns will formulize into architectural languages of the sort where you call forth your observers and factories and flywheels and assemble them into place at a high level. Does an architect need to know the metalurgical analysis proving the steel beams or the rational behind the heights of door frames to architect well? Not really.

I think in the earlier days of Microsoft even, the definition of a good computer programmer was a person who can write a quicksort in the smallest, tightest, cleverest and most succinct piece of C code. When people applied for a job at Microsoft, the person who wrote multi-line commented sorts was penalized, and the person who leveraged the system qsort() function was looked down upon, and the guy who wrote something clever in 3 lines was hired. Interestingly, the emphasis to reinvent the wheel, but more clever each time led to products universally accepted as bug ridden and terrible. I think in the recent years with the adoption of high level patterns we're starting to see fruits of that in a lot of their software.

I think the discipline of software engineering, in order to make the design/architectural leap forward has to stop penalizing the lack of algorithmic knowledge of every little thing that spins beneath the surface, and reward the big-picture thinkers. Which is not to say that fundamental knowledge is not necessary or important -- just not a critical requirement.

The guy who wrote up the solution for 7 instructions versus the "optimum" 11, the code does not resemble the proper solution in any way. It used some kind of oscillating counter that doubled as a way to calculate the sequence and as a way to modify the running code itself. He explained it to me with an analogy of climbing a ladder. Something like that.

Calvin

Who's going to write this high-level language, and in what language would it be written in?

Bootstrap: the first compiler will be written in the new language and self-compile . That is sort of how the first Pascal compiler was done.

As to the design of the new language any fool can design a programming language and most have

Don't get me wrong, there's a need for such people, just as there is a need for special operations soldiers in the military. But not everyone needs to be special ops to have a military.

If you saddle the requirements on *everyone* then the discipline as a whole will not advance. If you partition by specialty, then you have a chance! An architect, perhaps even a superb architect (i'm thinking buildings, not software) does not have to have mastery over every little thing, like the size of a doorknob, the location of handles, the types of fire extinguishers, or whatever to make a great building. Clearly somebody designed a door with the handle in a certain place, and that door will be instantiated all over the building. Clearly the design of that door is pretty standard, and could stand to be improved time and money willing, but the *architect* wouldn't benefit from this knowledge, much.

Calvin

Anyone who thinks that the a university undergraduate program give you mastery of the skills learned there is sorely mistaken. It's to give you the skills needed to learn from, and without a broad base to learn from, you get pigeon holed into an area of programming that might not be best suited for your skills. Personally I'm not a low-level programmer, in fact, I prefer Perl over any other language.. That doesn't make the skills I learned from programming assembler useless.. I didn't say that everyone should be a master of every language did I? I just said that as an undergraduate, multiple levels of knowledge are needed.. To better understand the weaknesses of languages, you need to know what differences there are..

I fear the people who say Java is the best programming language out there, because they are showing that they know jack about programming languages.. No one language is the best, they are only the best for specific purposes.. If your architect person claims that everything should be made out of concrete, would you believe them? They might claim that if that's the only material they were taught about.. Lets hope that architects are taught about wood and metal too.. perhaps how laminated wood beams are constructed, so they know they can use them to make large open areas where solid wood beams aren't strong enough..

I the last two days I've made a little progress. I read tons of Linux documentation and then installed Red Hat in a dual boot configuartation with XP (debian can wait for my next impulsive urge to do something crazy). I spent a few hours getting use to it, configuring the trivial little things, installing things I needed, etc. Have used Unix and Solaris before, I now feel reasonable comfortable with it. I set up some makefiles and compiled some of my old code to see how everything works-- no big surprises. The next major goals are: figure out how to compile my own kernel, then install the arm toolchain and see if I can get my own empeg kernel working. I'll let ya'll know how it goes...

John

Hey Gary,

Thanks for all the advice, it's appreciated. In the vein of what you said I introduced myself to a whole new unknown in the form of Linux yesterday. Hopefully it's all part of some greater knowledge that will allow me to do some cool stuff later. I'm not exactly looking for specific answers in my CPS classes-- its all critically important stuff anyway. This specific interest grew out of me wanting to do some cool stuff that I can benefit from now, rather than waiting for my knowledge to mature over the next several years. I think it will be a worthwile pursuit.

- John

Good point! Not everyone can be multilingual, but basic knowledge of language constructs from language to language is helpful. We've all run into the Java monotheists or the C monothesists who though technically talented just can't comprehend a world beyond that.

Calvin

And, to expand on that point slightly, there are (probably more) people who know nothing other than procedural languages, and never consider functional or object-oriented languages (or some permutation thereof). And these differences are likely to be bigger stumbling blocks, because the differences between those sets of languages tend to be more of the ``syntactic sugar'' sort than any real functional difference.

all you guys who do your indtroductory CS in C, C++, or Java, consider yourself lucky: I had to do mine in SCHEME (a dialect of LISP). When was the last time that one was useful? (except for writing a EMACS macro).

Scheme will teach you more about computer science than all of the rest of those languages put together. It's a beautiful language. (I taught some beginning programming labs in both Pascal, C, and C++. Pascal was wonderful. C was okay, execpt for the points you had to gloss over: Q:``Why do I have to put an ampersand in front of a string argument?'' A:``You'll find out next semester.'' C++ was awful. It's such a hodgepodge of language that it's hard to find any computer science in it. Perl would be even worse.)

As to its real-world application, there's scsh, if you're inclined towards sysadmin stuff. There's really no reason you couldn't write any application in it. It'd just be more difficult than usual to attach to external libraries, though far from impossible.

I learned some SCHEME when I took my Programming Theory class.. We used it to interpret and perform programs written in SCHEME.. Kinda pointless, but we learned how Tail Recursion and other concepts worked.. (man.. I can still remember car and cdr)

My first official "introductary" programming courses were in Fortran! I remember when you had to hit return around the 78th spacing!!!!!! :-D

Calvin

(man.. I can still remember car and cdr)

Me too... I burn my MP3's to cdr, and I also put them on my Empeg so I can listen to them in my car.

I never understood Lisp when they taught it in my classes. I mean I had already learned all of the basic Comp Sci concepts in other more practical languages so it seemed really academic to me. Although I have no problem messing with the Lisp stuff that Emacs uses. It's just not a very interesting or practical language.

It's only interesting to people who teach with it aparently.. Though I think they're working on a plugin for Visual Studio.NET, so someday you will be able to use it in other programs..

Teeheheehe.. A marriage of a language loved by computer scientists, and a company that has lost touch with all good programming practices... Gotta love it!

..and when I was a just a young lad..

But seriously, anyone who looks at my code just nods their head when I tell them my first computer language was APL. Scarred for life.

-ml

Don't you mean that you had to change cards?

> [lisp/scheme is] only interesting to people who teach with it aparently..

No, it's a pretty important language for Artificial Intelligence research. I had to implement my AI project in lisp. Quite funny, actually -- I didn't do any implementation, but still got about a B on the project based on my documentation of the non-existant code.

I remember my first C++ class. I already knew C, but I didn't understand what OO was. It wasn't until I learned to program in MOO when it finally clicked as to what OO was. It made a huge difference to be able to create virtual objects to play with.