Regarding learning assembly, I'm beginning to come to the view that it's in fact the best way to teach the first course in programming to kids. They don't come with any preconceived notions of what programming should look like and given an explicit, visual model of the computer, they quickly learn the small number of operations to write programs. More over, once they learn to do
LDA A
ADD TWO
STA A
DAT TWO 2 <-- initializing variable TWO
then, this line of code
A = A + 2
in C or a higher level language makes soooo much more sense. That awkward phase of internalizing that '=' is an assignment operator and is different from another operator meant to test equality gets a lot shorter for a beginner.
Btw, this is the best online CPU simulator I've found for that use http://peterhigginson.co.uk/LMC/ I'm shocked at how all the code academies and hour of code's haven't created a polished version of LMC (Little Man Computer... look it up).
I've talked about the x = x + 2 / x == 0 "problems" with a couple of people during university and it seems there's different levels of problems/irritations people have with the syntax. For me it was mostly a "shrug ok so that's that, don't see the problem" when it came to accidentally using "=" instead of "==". A couple of friends seemed to have mental blockades and often wrote code containing the typical bug of "=" instead of "==" (the hotfix of 1 == a instead of a == 1 helped some).
For me the irritating thing was x = x + 2 since it triggered my math brain which protested and simply said...well that can't be, error. So I guess I did have the exact reverse problem always seeing the assignment as an equality.
Thankfully this passes really quickly after you immerse yourself in it for a day.
Of course years later one of the first sentences from our Prolog 101 prof was "so you have been programming for a while now...let me write this down...i = i + 1...someone explain what this does...what would you suppose a (stereotyped) mathematician (that only knows math) would tell me"
Kind of made me smile.
/offtopic_anecdote
In my personal case I am not sure if it didnt end up 'bad' for me. The first language I've learned was 6502 ASM on C64 (and learned is a word of many degrees here, I can't say I've written anything serious in it, ever) and for some reason I've been struggling with many other languages for years to come after that - tried Perl, PHP, C, AmigaE, without being able to grasp any of those. Until I've met Python, that in few days took me from ground to the stratosphere (which today again looks like a ground, but that's a different subject). And even then, old habits of counting cycles and thinking about what the hell is the language doing made me to prematurely optimize my code (like doing 'while 1' instead of 'while True' because in 2.7 True is simply a variable, what means the interpreter will have to check its value first and that means lost CPU cycles, and lots of other things that made sense in 6502 ASM) instead of getting it to do shit ;) It took me a while to 'unlearn' those habits and to simply enjoy the language in its own form.
That looks like 6502 but it doesn't have ADD, only ADC. I prefer the Z80 though. :-)
I also think starting with Asm is a good idea, because it forces you to think about things like data representation (often glossed over in HLLs) and breaking down complex operations into a series of simple steps - something that you have to internalise effectively to become good at programming. If there is time for it, going one step lower to logic gates would be even better to dispel the "magic" and see that CPUs are actually very conceptually simple and logical machines.
Of course to become productive they should move to a HLL and learn the higher-level organisation (functions/procedures, objects, ...) but I agree that the basics are important to understand first.
This is a book I strongly recommend, it's definitely written at a level readable for kids and young adults:
> That awkward phase of internalizing that '=' is an assignment operator and is different from another operator meant to test equality gets a lot shorter for a beginner.
I'll probably have to thank one of my highschool math teachers for inadvertently helping me skip this phase altogether then :)
He always pestered us to use the "equivalence" operators ⇔ or ≡ (the latter mostly for geometry stuff), and only use the regular equal when you had unambiguous contexts like "Let f(x) = x + 2" or "if x = 5". At the same time I was learning programming (with C++ as my first language...), and I could easily see "=" as being for assignment, since in other contexts you either used something more fancy (like ⇔ or ≡ in math, and "==" in code) or you used explaining words like "let" or "if" to clarify meaning. Though I think it took me a while to get things like `while (x = getch()) { ... }` :)
I don't agree with your math teacher. ⇔ is not equivalence, it's a symbol for 'if and only if'. The left hand side implies the right hand side, and vice versa.
Writing a * a - b * b ⇔ (a + b)(a - b) doesn't make any sense, because neither the left hand side nor the right hand side are logic statements.
> That awkward phase of internalizing that '=' is an assignment operator and is different from another operator meant to test equality gets a lot shorter for a beginner.
Pity language designers don't take the more obvious solution of making their maths-derived operators behave like the language they're drawn from.
Surely something like Logo has similar advantages (small set of simple instructions) without requiring students to learn about CPUs before they can start? Plus it means they get to draw pictures instead of relatively boring calculations.
And switching to assembly seems like a pretty overkill solution to the = vs == problem.
the = vs == is just an example of how having a robust mental picture of how computers actually work makes high level programming more intuitive. And you don't really have to teach a real CPU for this to work. Check out that link I posted. It's a greatly simplified CPU simulator with visual feedback on every step the CPU is taking (e.g., PC increment, fetching the next instruction, storing something in memory etc.) It's great fun for kids to watch how a little program they wrote made the computer do all that work.
If you're still involved in teaching school kids some sort of assembly but still in a fun and visual way, I highly recommend checking out the link to LMC I posted above.
I'm very happy to see people are still doing this sort of thing!
I've always wanted to see something of a truly 'barebones' OS; but one that could at least get you 64-bit mode, OpenGL ES, audio output, USB polling and network connectivity with libc available. Yet not be as complex and large as Linux/BSD.
Being able to run a real-time application with no pre-emption, no virtual memory protections, no kernel transitions, etc could probably eke out an additional ~20-30% of performance on a CPU-bound application. Plus the near-instant boot would be great for media players, emulator arcade boxes, etc.
Probably just not possible, due to the driver situation. There was a bit of hope UEFI could lead to better drivers for hardware prior to boot, but efforts around things like GOP (graphics output protocol) haven't really gone anywhere that I've seen.
Sadly, there's a very small amount of modern things you can do with 32-bit mode, VESA and a keyboard. I've never even found a video card with a 1920x1080 VESA display mode; they're almost exclusively still 4:3 only.
Plus, no sound rules out gaming and media; no internet (let alone Wifi) rules out any connectivity; no strong filesystem rules out moving data around easily; no USB rules out loading things from external storage, gamepads, etc.
Only strong use case would be for embedded; but ARM platforms have this area beat substantially in cost, power, tooling, etc.
> Plus, no sound rules out gaming and media; no internet (let alone Wifi) rules out any connectivity; no strong filesystem rules out moving data around easily; no USB rules out loading things from external storage, gamepads, etc.
> Only strong use case would be for embedded; but ARM platforms have this area beat substantially in cost, power, tooling, etc.
This is anecdotal, but when I was his age and getting into the "real" tech world (and getting my work recognized), I really disliked my age being made a big deal. A big influence on my own view (and I think many others in this community) of being a "hacker" was Steven Levy's "Hacker Ethic", which specifically said:
"Hackers should be judged by their hacking, not criteria such as degrees, age, race, sex, or position"
While it is great that we recognize good work like this, bringing up his age in the title is focusing on a pretty irrelevant metric when we should focus on good work, no mater who makes it.
Maybe we should get rid of weight classes for boxing, women's leagues for sports, and anything that acknowledges accomplishments for anyone that is not 100% objectively the best on the planet.
> While it is great that we recognize good work like this, bringing up his age in the title is focusing on a pretty irrelevant
It's relevant because it's remarkable and it puts the author in a much smaller circle than he would be if he were older. Trying to pretend otherwise is silly.
Being able to read at age 18 is a lot less interesting than at age 4. Same goes for rare technical feats (and writing an OS is such a thing, most developers wouldn't be able to pull it off, so doing so at age 13 is certainly a lot more interesting than when you're older).
Sure, but it's impressive nonetheless. A 14 year old kid is building an operating system. What was I doing at 14? I was not building operating systems, thats for sure.
That's not the point... by bringing up age as an important factor, you are then discounting the work. Personally, I would rather have my work valued the same way if I was 14 or 64...
In the case of my current work, I would say I have put the same amount of time into learning and working as people twice my age (Though I guess that means I haven't had much of a life otherwsise, heh). Regardless of my age, I think my work should stand on its own against anything that currently exists. If you add an age qualifier, it does feel insulting (at least for me).
I should also mention that I have used my age to my advantage in some cases, but I strongly dislike people who use it as their main selling point, such as when people brag about being a "young startup founder" etc.
> That's not the point... by bringing up age as an important factor, you are then discounting the work.
I think this isnt valid in this case - the work is more impressive exactly because it is being done by someone that young, and this is so huge accomplishment because it is so much easier and more common thing to achieve at later age. I can't see his work being discounted here.
> Regardless of my age, I think my work should stand on its own against anything that currently exists.
I also can't agree with that - if you have 30 years of programming experience and what you're making are hello-world type of programs (that's what I was doing around 14) then you are obviously underperforming and simply doing bad. However, at 14 the very same work was already outstanding when compared to my friends at the same age, because most of what they were doing was running around on the yard. And none of them ended up as a professional runner (but still, they might be happier today than me, being professional hello-world engineer ;)
The feat becomes more impressive, yes, but not the work – i.e. the result.
If I want to be a peer among peers and contribute to society on an equal level, I can’t have people going “Ooh, that’s very good for a cripple/child/blind person. When they do that, I can never know if I am actually good enough or if people are only patronizing me.
If you're seeking approval from other people to determine if you're "good enough," you're heading down the wrong path.
Also, this is a ridiculous conversation. The actual work of these teenage wunderkinds is very rarely on par with the work of similarly talented, but more experienced professionals. It's almost always about the feat. And that's okay, because the feat is indicative of future potential.
It's not that you couldn't have, it's that you didn't.
Although when I was 14, the references to do this were not readily available. With all credit to "Omar", it's also credit to how available and intelligible our reference material is for techniques like this.
Honestly though, writing OSs? People make it magic. In reality, they're just programs. It's fun. There are even really smooth (albeit way outdated) tutorials like NachOS out there (https://www.ida.liu.se/~TDDI12/material/begguide/)
Regarding ExDOS (or your EyePC), would we be discussing it right now if it weren't for the creator's age? Not to discount this work, but if it had been the side project of a mid-career engineer, it would be a non-story. Not because the work is good or bad, but people simply wouldn't care.
The point being, you benefitted tremendously by your work being judged relative to your age, so it seems disingenuous for you to suggest Omar shouldn't get the same treatment.
I doubt ExDOS or EyePC will be remembered in the annals of history as engineering marvels, but that's irrelevant. They are indicators that the creator has the talent, intellect, and dedication to accomplish a lot in a very short amount of time, and they hint at great potential.
Totally agree in regards to EyePC, but at that point (when I was 13) I had those sort of feelings. I prefaced my comment with that it was my opinion based on anecdotal evidence. Omar made a couple of comments here (which he seemed to have deleted) in which he said he was disappointed that his age was the main focus.
The main reason I brought this up was because even today (I know 19 is still young, but I am a full adult with 6+ years of professional experience) I am still judged by my age by many people and not my actual work, and today I think my current work is actually something worthy of extreme interest regardless of who developed it or how old they are.
I just ran through the OSDev Bare Bones [1] tutorial this evening, even implementing newline support! I don't understand all of it yet and here's a kid half my age doing amazing things. Goes to show what you can acheive with time and perseverance. I really wish I learned Assembly at that age.
Good on him. Building an OS from the ground up is actually fun when you get into it. I found it to be a great learning experience (but did it years later than this dude).
I've lurked on the OSDev forums he credits on his website for a long time, and both Omar and Muazzam (mentioned as well on the website) are goddamn impressive for barely-teenagers. Someone hire those kids!
Thanks for mentioning me, by the way. Oh, and I don't need a job--it's against my ego to ever work for someone else for money (though, I'll definitely help you, if you need it).
I know how that feels, but it gets better, and you should definitely continue. Be proud of your work, and know that you are developing it to be the best piece of work you can develop... and not just what you can develop "for your age".
The only advice I would give for this sort of situation is while you should not emphasize your age (which you are not doing), definetely use it to your advantage when you can... Get sponsorships to conferences/events, meet cool/influential/important people, go audit university courses, and the many other things at your disposal. And just remember that there are very few real "hard" limits when it comes to age, and don't take "no" for an answer if someone tells you you can't do something because you are too young... the best way to prove them wrong is to do the best work you can, and to never stop trying to improve yourself.
If you would like any more advice, feel free to shoot me a message (my contact info is in my HN profile)
You can flesh out your profile by clicking on your name in the top right, suggest you add a link to your project there. Super neat to see your stuff, keep at it!
No joke: I strongly believe that "real programmers" do indeed write in assembler. Not x86 assembler, mind you. Rather, "real programmers" first compose an abstract machine semantics for the solution domain, create an instantiation of those semantics in the form of a virtual machine on some host architecture, and then express the solution in an assembler language targeting the abstract machine semantics. (See, for example, the Prolog abstract machine semantics to represent the solution domain of expert systems.)
They might, if their problem is really hairy and requires large amounts of exploratory programming, create a high-level programming language (usually a macro-language) that allows easy access to the same abstract machine semantics, and then code in that. For well-defined "closed" problems (e.g. in-kernel packet filtering), this added baggage is usually unnecessary, but for more "engineering-oriented" problems, you might end up with something more like an Erlang than a Prolog.
Note that C itself follows this rule; the "C abstract machine" is a pretty good fit (though perhaps not perfect) to the solution domain of low-level systems programming.
Mostly that it's the simplest and oldest (and, in my opinion, the least "sandwiched in between five layers of indirection") version of a very common idea, that I'm not quite sure the name of. It's the idea behind DSLs, and Lisp-like languages. Most of Chuck Moore's writings on the potential behind Forth-like languages are also about this idea. The most modern instantiation of the idea, I believe, is "Behavior-Driven Development" with Cucumber et al. But it's all the same thing, in the end.
Generally, the idea is: first, you should define a language to directly express statements about your problem domain. Then, in one place, you can define the solution in terms of the problem domain. Completely separately to that, you can implement the mechanism by which a machine interprets and acts upon statements about the problem domain. Putting the two together results in a program that solves your problem. But either may be maintained separately.
The term "separation of concerns" has effectively always been about making sure that demands for change that come from separate "departments" don't end up touching the same line of code. This model excels in that: maintaining the specification of the solution is solely the province of the business, while maintaining the interpreter of that specification is solely the province of some engineers somewhere. As long as the interface between the two is stable—a stable ABI—improvements can be made to one or the other without the other group ever having to be aware.
A great example of this is the Inform 7 language. One group of people writes text adventures in this language, or enhancements and plugins for text-adventure development. A separate group of people maintains interactive-fiction interpreters that parse a given ISA. Neither group has to think about the other. The ecosystems of the IDE and the runtime are, in fact, completely divorced.
However I would be willing to bet you are using a bootloader and a kernel written by people who are comfortable with assembly language. Call them real programmers or something else.
My name is Muazzam Ali Kazmi, a hobbyist programmer from Shahpur,
Layyah, Punjab, Pakistan. I am a student of grade-11 and I started
programming about 4 years ago. I am developing the OS since 7
September 2014. My interests include religion(s), philosophy,
operating systems, virtual machines, simulating a universe in the
computers, compilers, theoretical computer science, artificial
intelligence, mathematics, and science.
Edit: The comment was off-topic because it went on a flamebait tangent. The topic at hand is an operating system project. Given the context, it's natural to talk about age and precocity too. But "Now it even matters what your political and religious views are [...] Brendan Eich [...]" is wildly off-topic, and exactly the sort of generic ideological tangent that commenters here need to avoid, for two reasons: (1) it's generic, so leads to unsubstantive threads, and (2) it's flammable, so leads to uncivil ones.
That doesn't mean we think you were trolling or intentionally derailing or deserve to be banned or anything like that.
There's a difference between something you are (race, age, sexual orientation, gender) and something you choose to do (donate to a political organization, become a cop). It's very different to discriminate against someone for something they can't control vs. something they can.
Having a political view or religious belief is almost synonymous with acting on that - participating in the political process or your religious community. (Though you shouldn't be doing these at work).
To be uncharitable, you are taking an unreasonably narrow view because you disagree with Eich (I do too), but like with freedom of speech it's all about the case when you do disagree.
I'm not sure what you're getting at, but I'm talking about the difference between ascribed and achieved statuses. An ascribed status is something you can't control: your race, gender, sexual orientation, and so on. An achieved status is something you can: one's profession, for example.
In this context, someone was implying that discriminating against someone based on their age is the same as discriminating against them based on their political or religious views. It's a false equivalence, because you choose your political and religious beliefs, you don't choose your age.
I'm not arguing for or against discrimination; it's a complicated topic. I just felt like in this context, parent was using a false equivalence to discredit identity politics, and I took the opportunity to try and speak out about the difference between ascribed and achieved statuses. I do disagree with Eich, but I think that's immaterial.
Had he donated money in the middle of writing a while loop people would have said "ah well, but he's was working as a programmer"?
Such things happen regardless of the role, the role just make them more relevant.
There was a recent case (I'd rather not be specific, but about a month ago) in which people asked for a dev to leave open source project cause of his opinions.
Sadly, I'm not even sure people are all in the wrong for getting their pitchforks out, something that I might discount as "just being too sensitive" might hit too close for other people to accept.
Eich donated the money in 2008, but nobody made a big deal of it until his promotion in 2014 to CEO. The standards for a project leader are clearly different than the standards for just any hacker.
