True is true and false is false.

If you send me to code examples containing either of the following you are not going to be hired, ever.
test ? true : false
if ( test ) { return true; } return false;

5 comments:

Matt Caron said...

Of course. Ternary operators and multiple returns are both very much forbidden. :-)

Andrew Gilmartin said...

Having cut my programming teeth with Pascal I am very much in favor of only one return per function. Not that I do that as the practical effect of this is 1) too much conditional nesting or 2) lots flag variables. With that said, I think that the world would have been much better off if the Oberon programming language and the Lilith workstations were the models that were copied.

Matt Caron said...

Conditional nesting can be overcome with flag variables.

You only need one flag variable, which I typically call "success". It also doubles as your return variable.

You may need other status variables if, for example, you can't detect if something was open for cleanup, e.g.

if (filehandle != NULL) {
close(filehandle);
}


Anyway, if, at any point, success is false, you skip that section. Each section which might set success should be encapsulated in a success block.

Aside: This also highlights where you can break a long function out into sub-functions for enhanced readability.

Regarding Oberon - it looks like Pascal. Pascal has one redeeming quality - it is not Lisp.

Regarding Lilith - Ooh, it's a Pascal machine, just like there were Lisp machines and, for awhile, there were going to be Java machines. Take some generic hardware, throw a sufficiently complex ROM on top of it, claim it's all done "in hardware" and make a mint. No thanks. Give me a BeagleBone Black and a JVM/CLI runtime over those any day.. or, even better, none of the runtimes. Just use D - it's what C++ should have been.

Andrew Gilmartin said...

What I most like about Lilith, and its kin, is that since there is only one language for system and application development all of the complexity that comes from the mismatch between the system's linking and loading needs, for example, and that of the application language are gone. You can, in fact, write the whole OS in a few thousand lines of code. With that said, the last time I worked in this area was in the 1980s and OS issues might have changed. I doubt it, however, as it seems all the complexities continue they have just been pushed down to the CPU or up to the compiler.

A BeagleBone Black looks cool. I have been thinking about a purpose built machine for a standing desk I am designing (for household stuff not coding stuff) and the BeagleBone Black would be a good fit.

Matt Caron said...

What I dislike about Lilith and its kin is the monoculture. I like being able to pick the right language for the right thing, balancing developer time with application efficiency.

From an efficiency perspective, I will concede that there are a lot of benefits for designing hardware to complement languages - stuff like implementing commonly used operations in hardware, or status bits to identify the type of data stored in a region of memory (tagged memory).

However, you can't do all of it in hardware, because that's prohibitively expensive, so you end up doing a bunch of it in microcode (aka ROM) in which case what benefit have you gained over a more general purpose architecture with some type of runtime environment? Plus, upgrades require microcode flashes (at best) or new hardware (at worst) and it precludes easily switching back and forth between different language revs - I mean, just think about how many versions of the JVM there have been in the past 10 years.

No, I think High Level Language machines have died for a reason. It's cheaper to make faster, simpler CPUs and that's why you ended up with non-Lisp machines able to run Lisp faster than Lisp machines.

Regarding OS issues, I think that you could still write an OS in a couple thousand lines of code - it's all the drivers that require a metric ton of additional code, because you end up supporting a gazillion different video cards.

I mean, looking at modern Linux (I happen to have the 3.4 branch checked out), the `kernel` subdir is 191945 lines. You have to assume that a pile of it is comments and build rules, and I know for a fact that a lot of it is optional or configurable (you have a choice between several schedulers, and there's also a whole trace subdir which has the kernel tracing functionality). If you pull all that out (because, in the 80's you got one scheduler, and you loved it), you're down to perhaps half the size. Not the "couple of thousand lines of code" you were talking about, but 100k lines of code is actually quite small. However, the drivers subdir for that same kernel release is 8242104... so, 8 million vs. 200 thousand... Big difference.

Regarding: Beagle. If you need more horsepower, look at the BeagleBoard X15 (assuming you can wait for a bit). It uses the new AM57xx CPU. Details I can discuss are scant (I get to see TI's roadmap but am under NDA), but everything on that page is public knowledge. MSRP of $199, but you get a dual-core Cortex A15, 2GB RAM, HDMI and an eSATA port.