Slashdot Mirror

Einstein's theory of relativity explained in words of four letters or fewer:
http://www.muppetlabs.com/~bre...

An oldy but a goody!

Your child may not get everything right away, but that's probably less important than the examples of thought experiments, and the honest effort to provide some explanation in simple terms. Often when things make an impression that way, children remember and wind up understanding years later.

This guy managed to get it into 145 bytes (142 on his website, but he printed "Hi World" instead of "Hello world") with no external dependencies.

The smallest ELF executable I've seen is this 45 byte example. It doesn't print anything and it violates the ELF standard, but Linux (or at least his version) is still willing to execute it.

That said, there isn't much point in optimizing away libc except as an academic exercise. Yes, it's a few megabytes in size, but it's shared across every running userspace program (likely including init). Sluggish and bloated programs, in my experience, are almost always the result of poorly thought out algorithms, data structures, and use cases. (That said, the analysis on how to achieve the 45 byte ELF program is very interesting and educational.)

First, I'd suggest deciding what you want to focus on -- firmware (embedded programming) or HDL. If you're coming from a CS background, you might want to start with digital systems and computer architecture before plunging into HDL. Designing a CPU at the gate level will teach you more about how the hardware works than writing a page or two of behavioral HDL. These basics are also good for embedded programming. Without knowing more about your background, it's hard to know what to suggest. If you're coming from PC application programming (or, god forbid, web scripting) with no electronics or low-level background, get ready for a shock -- you're not in Kansas anymore. Personally, I'd suggest starting with some basic 8-bit AVR or PIC projects, since there's a lot of material on the net to help you. I've mostly learned on the job, so rather than giving you books, I'll suggest some topics to study:

Software
1. C programming in general and pointers in particular. Use this as a bridge to assembly.
2. Enough assembly to understand what sort of operations there are and how they're used. Don't bother writing huge programs in assembly; just make you sure you can read your debugger's output. This is a good chance to figure out whether your CPU has a hardware multiplier (probably) and divider (probably not). This tells you which operations are fast and which are dog-slow.
3. Where all the pieces of your program go in memory (code and constants in flash, data in RAM). Learn about standard assembly sections like .text so you can parse the error messages when your program gets too big for the chip it's in. Read this article for some hints in a PC app context.
4. Bit twiddling. AND, OR, XOR, inversion, shifting. Basically, any C operator listed under the "bitwise" section.

Hardware (theory)
1. Registers. CPU registers. Memory-mapped IO registers. Read-only vs. writable registers. Reset states of registers. You're going to be dealing with a lot of registers.
2. General-purpose IO pins and all their features. Look at a schematic in a microcontroller datasheet and understand input/high-impedance vs. output vs. input with an internal pull-up/down. Maybe driver current strength if you want to make *big* blinking lights.
3. Clocking. Where the clock comes from (crystal? internal oscillator?), how precise it is, how it's divided down, and how to turn off the division so the chip will run at full speed.
4. How to read a datasheet. Figure out what voltage(s) you need to power the chip and what (if anything) should be connected to each pin on power-up. Datasheets are very long. Learn to skim.
5. How to limit the current on LEDs with resistors so they don't blow up.
6. How to use a linear voltage regulator to get a clean 5V out of whatever DC power source you can Frankenstein together.
7. At least a cursory knowledge of voltage, current, and Ohm's law. Know how to determine power dissipation in a resistor (compute it) or an LED (read it out of the datasheet).

Hardware (bench-top)
1. How to use a multimeter. Spring for a nice auto-ranging one on eBay.
2. How to wire up a breadboard. Don't bother soldering yet; this is much easier. Hint: keep your wires short and neatly-arranged. Get a wire stripper and learn how to use it.
3. (Optional) If you have some money to throw around, pick up a bench-top power supply off of eBay. A triple-output supply is the most you'll ever need, but single-output is fine for simple MCU projects. This is more convenient and reliable than cutting up a wall wart.
4. (Even more optional) If you have a lot of money and are pretty serious, get a digital storage oscilloscope (NOT an analog-only scope, unless it's really cheap). This will do wonders for your debugging. Buy used unless you're rich or hard-core. Bench-top electronic tools are not cheap.
5. Find a local electronics store. Fry's is a decent choice (for tools, too!), and many cities have smaller but cheaper

Here is the reference (I'm the same AC/mod as parent): http://www.muppetlabs.com/~breadbox/software/tiny/teensy.html

News flash: turing-complete programming languages can be used to created anything. Why is it news when another random project is done in Javascript?

Ah, the old Turing-complete chestnut. Just because something is possible, does not mean it is feasible, practical, or easy. It's probably possible to code it in brainfuck, chef, lolcode or a bunch of rocks but no-one in their right mind would want to.

What's really interesting about this is that it now brings PGP to almost device with a browser - that is: those with browsers which have javascript support. This gives us such joys as iPhones with PGP that Apple can't suddenly decide they don't want people to have.

... to goodbye.

Screw that, I can do it with 8.

If shortness of documentation was the sole metric for language popularity, shouldn't we all be programming in Brainfuck - http://www.muppetlabs.com/~breadbox/bf/

1) get a good test like this one on biscuit topology

2) and learn a major turing complete programing language preferred by mathematicians use

Nope, she gets a hello world down to 1329 bytes, the bloke who did the 45 byte one was Brian Raiter.

Sure, but this one from muppetlabs is much more complete, better-written, predates it by more than a decade (July 1999), etc. You can combine that with the overview and the other examples for a much better understanding.

Sure, but this one from muppetlabs is much more complete, better-written, predates it by more than a decade (July 1999), etc. You can combine that with the overview and the other examples for a much better understanding.

At the time of writing this comment, I'm disgusted by the amount of flames rated +5. "Haters gotta hate", sure, but haters gotta be modded-up? What ever happened to constructive criticism? Of building some better explanation from a weak article?
I come to Slashdot for the interesting and insightful discussions. Criticizing without anything constructive serves only in inflating your own ego.

I believe this article is interesting. Though it does cover part of the same subject as the Whirlwind Tutorial, it doesn't duplicate it. It provides insight in the backstage of C programs which many programmers aren't aware of. I certainly wasn't aware of it before reading the whirlwind tutorial a few years ago, and there's always a new generation that can learn from it

After reading the linked article, I thought underwhelmed. Then I read the second article referenced in the summary:
        http://www.muppetlabs.com/~breadbox/software/tiny/teensy.html

Now, that was interesting!

The strange thing is that the summary seems to imply that both articles are related, which they are most definitely not. The first one seems to be written by a naive noob, who just discovered a nifty trick in gcc. The second one is written by a real Wizard, who shows you how to conjure up some arcane magic to make ELF your bitch.

      -dZ.

The article was last updated in 2009 http://www.muppetlabs.com/~breadbox/software/tiny/teensyps.html. Check out the link at the bottom.

A Whirlwind Tutorial on Creating Really Teensy ELF Executables for Linux

The smallest Linux ELF binary to print ’Hello world!’

So, this was written in 1999... But it's a nice read; clear and well explained.

But has anyone tested to see whether Linux still doesn't check ELF executables for nutty stuff like this? It's come a long way in the last decade...

(Since I don't have any x86 boxes handy, I'm just going to have to trust someone else to try it...)

Well, you're really wasting space there. With a default compile and link, you've included crt0.o which sets up the default C environment, and sections to command the dynamic linker to link in references to printf().

If you read this tutorial on the ELF format, you'll find the smallest valid Linux x86 ELF file that sucessfully does nothing is 368 bytes (although this demo is for Windows, so will be using the Portable Executable format instead). So you have far more code space to play with.

There are other tricks; usually the thing is packed with a code compressor, as even tightly-written code is likely to have some redundancy. I haven't looked at this one, but it's likely that 4kb executable is the result of an exe-packer packing a 5kb-10kb executable.

The famous production people usually refer to when it comes to small files with procedurally generated graphics is .the .product by farbrausch. If you read that site, you'll find out many of the tips and tricks that can be used to really pack down the size of executables and still make amazing 3d scenes.

I'm a big Basic fan, and love how FreeBasic is like one of the top languages in terseness and execution speed at http://gmarceau.qc.ca/blog/2009/05/speed-size-and-dependability-of-v1.html. (The updated version doesn't even mention the word "basic.") Unfortunately there seems to be a massive campaign against assembler and basic these days in favor of bytecode compiler languages, simply because the heavy extra layers that are placed between the user and the cpu, layers that can be claimed as intellectual property and the whole computing world sort of blackmailed into paying for a rental fee for living on top of it. Assembler is difficult to work with, but cheap. Basic is so simple anyone can do it. The drive towards dotnet/java or other so called "professional" languages is like having to use Latin in the middle ages for both religious ceremony and scientific writing. This kept the bulk of the population who didn't speak latin clueless. These days very little official discourse is in latin, and knowledge is more freely accessible to the general public. You could argue that the general public doesn't know how to write proper programs just like hillbillies don't know how to properly spell and create written text that monks properly trained in Latin would cringe at. So what? That's not a good enough reason to deny them the right to write anyway.

It's been a few years since 2005 when I was looking at a replacement for VB6 to bangup a quick and dirty db interface for SQL Server to manage some lab samples. I simply can't stand dotnet and java bloat and slowness, and even interface reaction time - I can't zip through the menus with the speed of light in the newer Visual Studios, and the test programs were similarly sluggish. I almost settled on programming in C++ and wxWidgets, which had decent speed, it it weren't for the codesize - DevCpp static linking minimal programs were well over 1 MB, for a previous VB exe app that used VBRUN600.dll was less than 64 KB. Win32 C apps were just too verbose to write and debug compared to VB. I ended up sticking with VB6 even to this day, which pretty much has both feet in the grave by now and a few nails driven into the coffin, but I still couldn't find anything better than VB6/Excel VBA that would be officially supported by MS, so my ass is covered when I give it to a large corporation. I'm quite tempted to go for unofficially supported things like sqlite in the future with a simple file access protocol, because even ADO/SQL Server is becoming ridiculous compared to old ADO classic/MS SQL Server 2000 version that was quick and dirty and flying like a breeze. I set up this VB6 frontend/ADO/SQL Server 2000 backend db app in 2002 to replace an old file-access based Foxpro app that was very slow, but the daily security patches sometimes break the whole show, with ADO getting messed up with an MDAC update, and good luck trying to fix that. Going back to a slow file access based db where all the data is pulled across a network to be locally sorted seems retarded, but in view of the heavy layer of moving targets in an officially supported server-client setup, something simple that relies on Win32 API with sqlite and simple file access is starting to seem like a breath of fresh air.

By the way I never really knew what i386 registers were, and these days I'm learning assembler programming, starting with http://www.muppetlabs.com/~breadbox/software/tiny/teensy.html and http://asm.sourceforge.net/intro/hello.html . Jeebus, assembler is hard, but it's so sexy, supersmall, superfast, with all middle man libraries out of the way. Libraries are like having someone else do a repair job on your car that you don't know how to do. Knowing assembler is like knowing how to repair it yourself, and when you take your car in for repair, you don't get shafted, because if t

True genius is making the complicated seem trivial. This means writing as clearly as possible rather than trying for the highest scrabble word score.

There's a time and a place for "waxing loquacious": Academic papers of predefined arbitrary lengths.

Not normal conversation.

Then you would probably enjoy The Theory of Relativity In Words of Four Letters or Less:

http://www.muppetlabs.com/~breadbox/txt/al.html

FORTRAN: The RealUltimatePower?

Seriously, though, if you're really, really intent on obfuscating the code, why not C-Intercal through CGI? Link!

Sure, there are some minor performance hits, but it's hard to get more obfuscated.

How about this one or this one?

Exactly. Go straight to the source of your language of choice.

You could just build yourself a tiny ELF binary with it and take a look..

How dumb do you have to be to write voting machine software? This is probably one of the few applications that could be written in Brainfuck and still not contain bugs.

Having been around for some years on this technocratic Earth, and having experience programming in pretty much all the standard (and some exotic) languages, I can say this: no matter which programming language a person might use, that programming language ultimately executes in machine code. Having said that, the most efficient way of writing code is in assembly.

What drives the wedge between pragmatists and idealists is development time. I could probably optimize my projects at work by dumping PHP and writing CGI programs in assembly - but - at what cost? Rather than spend $10k on development time, it's a better utilization of resources to lease a dual Xeon server for an entire year to meet performance requirements of the system. Not efficient on code level, but absolutely makes sense on a business level. Similarly, I could have employed C for previous data acquisition projects but LabView and G code allowed the project to be completed in two weeks instead of two months. During that time difference, numerous graduate students managed to put the system to good work. Time does matter.

Even assembly is not straight forward. You must be aware of all opcodes for your code to be efficient, and that means knowing which hardware you're developing a program for. Who has that amount of time to learn engineering specs of processors? Even C and C++ compilers aren't entirely efficient when it comes to generating programs. For amusement, see this classic piece:

http://www.muppetlabs.com/~breadbox/software/tiny/teensy.html

This guy spends hours optimizing a program so to reduce its executable size from 3998 bytes to 45 bytes. In this process, it's not just the storage size of the program but also the number of instructions the program goes through. A great achievement in its own right, but, not worth the trouble for larger programs. After all, isn't point of programs to basically do a job? In other words, it's more efficient to write the program once (even if it's inefficient) and leave it be -- rather than rewrite it continuously until it's absurdly efficient.

There is a reason why R.A.D. has been given an acronym and everything. I'm afraid that in this hodge-podge of processors, operating systems, hardware, etc, the wisest course of action is to shoot for completing a task if the outcome is correct. It's ridiculous to expect today's programmers to stick to a single language and learn it intimately: that's just not how things work in the real world.

Now, I'm not endorsing Vista's inefficiencies or anything - just talking about day-to-day programming.

INTERCAL is a bit like learning FORTRAN - it's a bit long of tooth - maybe try bf, unlambda, whitespace or my personal favorite, java2k. Any base 11 probabilistic programming language is tops in my book.

Brainf*ck?

Newtonian gravitational equations. In that you are correct. But reality is Non-Newtonian. All Jupiter knows is what the Sun was doing 43 minutes ago. All we know is what the Sun was like 8 minutes ago. Relativity puts a speed limit not just on light but on any type of information transfer. Unless you want to throw out causality. Go read your Einstein again. Or even any introductory physics text on relativity. They explain it quite well. Or here, for anyone who likes small words, try this.

You might be interested in this

I came across my favorite piece of bloat-free software while learning about Linux's ELF file format. It's only 45 bytes, and quite educational. :-)

DDL

The Answer to Life, the Universe, and Everything... in 45 bytes.

Here, at last, we have honestly gone as far as we can go. There is no getting around the fact that the 45th byte in the file, which specifies the number of entries in the program header table, needs to be non-zero, needs to be present, and needs to be in the 45th position from the start of the ELF header. We are forced to conclude that there is nothing more that can be done.

INTERCAL, actually: http://www.muppetlabs.com/~breadbox/intercal-man/t onsila.html

I think your understanding is a little naive... There *are* magic genes that do X. There are also pseudo-random sequences that we have found a use for, and there are, further, sequences we carry around that are malicious, or do exactly nothing. But we carry all these genes around anyway, because the cost of doing so is negligible, and the chance for quick modification is beneficial in a population crisis. To get an idea of the tasks geneticists face, familiarize yourself with the Brainfuck programming language (which is hilarious) and an uncommented sample program.

Now, imagine that -- over the course of MANY, MANY years -- we have evolved a usable Office Suite, circulating it on media with little or no error correction. There are no versions -- If yours doesn't do what you need, you toss it out and get a copy from somewhere else, or you try to randomly merge a friend's copy with your own using a little utility inside the software. The source code is over 8GB, and nobody knows what everything does. No individual programmer or team, at this point, can change much of anything because the chances of screwing up badly outweigh the benefits of any expected improvement -- but we are trying to gain the understanding to work with it. Exacerbating the problem, random copy errors exist, and have become functional and necessary, in every remaining copy of the program. People do research to try and find out how feature "X" works, but at some point, the code accepts a memory address from user input and jumps to it. Now, we have to find out where the input came from, and track down the code that created it.

Certainly, there will be parts of the program that do only one very specific thing, and there will be parts of the code that behave differently depending on state. There will be parts of the program that do nothing, and there will be parts that are seemingly random but just happen to contain instructions that do something useful under certain circumstances, or can serve as / generate useful input in others. There will be sequences with stable output, and those that vary wildly on input. Just because someone is looking for feature "X" doesn't mean that they will find it, or that it won't be an emergent property of the system -- some code written into memory by random-looking source scattered throughout the program. But it also doesn't mean there are no encapsulated features to be found.

At the stage we're in, we look for highly correlated output from the system, or at least easily-measured output, and try to track down any parts of the code that seem to affect it. Sometimes, there will be a clearly delineated subroutine, or portions of the output will occur literally in the code. Sometimes, the feature we seek will be a side effect of otherwise unrelated code, or the result of an error in code that originally did something else (and otherwise still would, except for the error). But you can't assert "There is no magic gene." any more than a geneticist can blindly assert that there is.

You have to use the "big words" [re: ideas, terms, vocabulary beyond a 6th grade level] to be practical.

Oh yeah? how about "Albert Einstein's Theory of Relativity In Words of Four Letters or Less"

http://www.muppetlabs.com/~breadbox/txt/al.html

"Big words" like "plasma" scare folk. Look! Six! As you all know, we can only read words of five or less. More and we just get scared.

I hope that last word didn't blow your stack, but when you need a "big word", you need a "big word".

(Wow, this is hard. How did he manage this? It would take me a year, I swear, and I used five, not just four.)

Pretty much the only thing that will help you with BrainFuck is an aneurysm.

Not at all - you cannot have an enjoyable game until you can learn to recognize the end of the game. Yes, the computer will not declare "I win" right away; they will pass. But it is nearly impossible for a beginner to understand why he or she has not won. The chess analogy doesn't compare at all - you know when your piece is taken, and you know when you have lost. You can begin playing unambiguously from the beginning. Go is a lot more subtle, and it takes a lot of time before you can even understand why you have lost. I began learning go on a small board versus a computer, and when the game finished, certainly they showed the colored areas, but it was very frustrating because the beginner thinks "Why the hell does he control that area? I have him totally surrounded!!"

I guess maybe a better way of putting it is this: Go is easy to learn, but not at all fun until your skills have progressed to a certain level. You say that learning to count the endgame is part of learning the rules - that directly contradicts the "easy to learn" mantra because endgame counting is not easy. You can't have it both ways.

Perhaps specific instruction sets are difficult to understand, but an assembler pseudocode would hold the properties I desired. Ok, let's set that analogy aside. You know what else is easy to learn but difficult to master? Brainfuck.

It looked both worse and better than assembler (for any architecture), but I was told it was wickedly fast for an interpreted language. I suppose that would be because you coded using the tokens directly, instead of the interpreter parsing the tokens out. I had never seen anything like it (CoreWars "assembler" was easier to read), but it left an impression on me. It wasn't until I first found out about Brainfuck that I saw an even more difficult to code in language (with, of course, Whitespace beating them both)...

Like most geeks of a certain age, I cut my coding teeth on BASIC, which in its traditional implementations (TRS-80, Apple ][, C64) was nicely interactive, but probably too boringly textual for Kids These Days.® Don't know how the "modern" versions of it compare.

Logo became available to me after I was "too advanced" for it, but certainly deserves a look as the "other" classical language for introductory programming.

I've heard some good things about Toon Talk.

Or there's always BrainFuck.

Unless they're vaccinated, don't give them MUMPS; if you do find a nice Doctor (Like Dr. Pascal), 'cuz Pascal was fun for me in College.

If they like noises, Squeak is good, but the cogently verbiaged might prefer SmallTalk in a group. For those speech impaired, knowing there's other people who Lisp would be good.

The mean ones will abuse Snobol in Winter

The A.D.D. kids will probably like the feeling of Euphoria they get from their first

Of course, you could teach them a very nice language with a horrible name, Brainfuck.

Or, you could just look Here for a comparison of popular programming languages.

I thought this was already publicized, Perl & PHP in one script? Isn't that just a brain fuck :)

Theoretically, there is no language that is more or less prone to bugs than any other language as understood in Turing Completeness

technically, there is nothing Python can do that Whitespace can't. That doesn't mean you have to use Whitespace..

trueineverusewhitespaceanditneverdidmeanyharm

(yes, I know about the programming language Whitespace. And, for good measure, let's throw in Brainfuck and its Pratchettesque dialect Oook)

Here's the closest thing to a compiler for the Lawyer++ langauge that I could find... You should be able to port with very little trouble. http://www.muppetlabs.com/~breadbox/bf/

Instead learn brainfuck!

Who said a language had to be fair?