The value of a CS education

Fair enough. Of course that rather means that we might have to build our own wall warts, rather than buying the cheapest one from Won Hung Lo.

Needing any significant power means they aren't idle in the usual sense. There are systems that need to be on all the time, e.g. exit lights, but most standby power is just wasted AFAICT.

Cheers

Phil Hobbs

Standards are great -- everyone should have one!

But note that most of these languages were BASIC's contemporaries. Ada lives just because of DoD. Pascal has never really "caught on". BASIC has been massaged more times than I would care to count yet has fallen out of favor.

Yet, C *thrives*.

I've written tiny interpreters for BASIC (w/extensions) over the years that I have used in rapid prototyping situations. E.g., put the interpreter on a small MCU (SoC), attach a TTY to a serial port and prototype a proof-of-concept design in a week or so (really wins when you need to modify that "on the spot" to respond to a client's spontaneous ideas *during* a demo)

OTOH, Limbo seems to have been a significant *flop* (same pedigree; you would think *those* folks, if anyone, would know how to make a "better C"!)

I'm not entirely sure that you can reduce it to something as simple as that. I.e., why have none of the BASIC-on-steroids caught on in the decades since? E.g., forgetting about actual *code* written, nothing other than Visual BASIC appears anywhere in the Tiobe index.

(Granted, BASIC might be a hard term to uniquely identify contextually. But, the BASIC's should not suffer from that ambiguity!)

I think C's stamina is attributable to it's wide range applicability. It's "PL/M-on-steroids" (which was "ASM-on-steroids"). It doesn't prevent (nor discourage) the programmer from doing certain things so you can do damn near anything you want (at your own peril, of course!)

The same is not true of other languages. E.g., support for pointers makes many things trivial to implement while their prohibition makes the same actions tedious.

But, if you objectively look at the language (syntax, etc.), it's really not what you would look for in terms of an ideal language. Heck, even "Hello, World" barely fits on a sheet of paper :-/

I dislike C++ because it hides too much from me. I suspect I would need to *really* become adept at the subtleties and mechanisms of the language to be able to, e.g., realize when anonymous objects are being instantiated/destroyed, etc.

Since I can do OOP in C, I settle for it's "thinner" implementation.

OTOH, I *love* C++ because it lets me exploit its syntax to overload operators (e.g., implement different data representation schemes and use infix notation for intuitive operators instead of having to resort to function-like invocations).

I looked at REXX as the scripting language for a current project. Things like arbitrary precision decimal arithmetic are appealing (esp if you want "average Joes" to be able to write code and NOT be surprised by "3 * 1/3 != 1.0".)

I opted for a modified version of Limbo, instead (Java without all the messy syntax requirements)

Which is exactly what I was saying, above! You can write *almost* everything in C -- even ISR's -- and be comfortable with a paper implementation before you even try it on real iron!

You must be one of those whitespace fiends. I put the left brace on the same line as "int main(int argc, char ** argv)'.

One rarely has to worry about that stuff in practice. Scott Meyer's books are good on that sort of stuff, and Stroustrup's "The Design and Evolution of C++" is an excellent read too.

I don't use C++'s generic programming support--it's mostly "C with classes and a few templates". I'm writing simulators and stuff, rather than avionics or heart pacemaker code, so I don't usually use exceptions either--aborting the run with an informative error message is usually the right answer for my purposes.

REXX is a beautiful thing. I started using it in the mid '90s and never looked back.

I think we're mostly in agreement, apart from (a) matters of taste in languages and (b) how much we care about programming fashions.

Cheers

Phil Hobbs

Well, I'm over 40 years old, and do I have a bad reput...

Never mind. Rich

I once had a gal hire me to tutor her in COBOL; turned out she just wanted to get in my pants.

Cheers! Rich

I once had a job where they'd hired a contract programmer to do the books in COBOL. One time, while just glancing over her shoulder, I saw the COBOL code on the screen and commented kinda generally, "Why do I feel like I'm watching someone design a pneumonic memory device using stone axes and animal skins?"

Maybe you had to be there.

Cheers! Rich

I suspect the same. Much more focus on the current "hot" language and much less on fundamentals. How many current CS grads have programmed a Turing machine? I survived it, but it was an insane frustrating experience. I don't know if I learned anything from it, either.

I know that I was pretty fearless in doing strange stuff from the front panel switches of minicomputers after that, however. Stuff like reading in a directory block from the hard disk, patching it and writing it out.

I wrote my own debuggers and built a number of 8-bit micros in the past. I doubt too many CS guys now could do stuff like that.

Jon

No, I share your style of "eliminating useless newlines". E.g.,

if (foo) { baz; bar; }

(I won't risk putting the closing brace alongside bar. OTOH, if "it was *just* "bar" and bar was reasonably simple: if (foo) { bar; } works for me.

OTOH, my function definitions tend to spread over lots of lines:

int compare( const type_t *template; /* pattern sought */ type_t *candidate; /* object under scrutiny */ ) { ... }

Just a convention to help me document calling conventions and introduce a lexicon that will be used throughout the function (e.g., I will later refer to the "pattern" knowing that I've semantically bound that to "template")

I do real-time embedded systems almost entirely. So, I'm concerned with knowing what my code likely costs. With C, the compiler will only do *better* than I imagine! :>

Have read the above. Actually found a bug in Stroustrup's which chagrined him, a bit :> ("Hi Bjarne. The descriptions on page XXXX seem exactly backwards! What detail am I *missing*?" "Ooops! None. The description *is* backwards :< ")

One of the biggest problems with C++, IMO, is exceptions! It's a great *feature* but people seem not to use it effectively. So, instead of handling them gracefully (or even *crudely*), programs just crash (default exception handler).

IMO, you need the language to enforce some acknowledgement of the exception interface for each function. I.e., make sure the programmer *has* put something in place to handle each one that could be thrown (in much the same way that the compiler insists that the developer provide all of the arguments to a function!

But, I have absolutely no idea how you could do that -- esp flexibly (unless you include syntax that allows a caller to tell the compiler, "Yes, I recognize there are these N exceptions which could arise, here. And, I am intentionally propagating them up to the caller *above* me (which the compiler could then check, similarly).

OK, *why*? What do you consider its strongest characteristics (note that I am not restricting that Q to its "features")?

I suspect we are in agreement re: the fashion issue as well. I *watch* new languages but haven't found any that I am willing to adopt to replace the existing ones that I use.

(OTOH, I am not averse to using a particular language for a special purpose).

No! Just come up with a new generation of designs (for the power supplies *and* the systems that they power). Then, let the commodities market provide them.

The impediment is that folks haven't "standardized" on a way to shut an external power supply *down* (nor a spec for some amount of standby current that you can expect to have available to you)

But, if you rethink the designs, I think you can come up with solutions that "standby" on very low power levels. E.g., the wake on LAN feature shouldn't need *anything* to be powered besides the PHY.

A VoIP phone (PoE powered) should be able to standby with a few milliwatts -- enough to power an LCD display or indicator... and, a bit of circuitry that watches the hookswitch and "buttons". Detecting activity could simply trigger the PoE PD interface to "formally connect" and initiate the normal power application sequence from the PSE. No need for an MCU, etc. to be involved (and powered while in standby!)

Agreed.

REXX is designed on the principle of minimal surprise. Its great strengths are text parsing and general readability, which makes it really great for gluing other programs together, or (my usual use) as a front end for a more powerful but less flexible program.

My biggest REXX script to date is about 13k lines long. It's the front-end script to POEMS (short for Programmable Optimizing Electromagnetic Simulator), a clusterized 3-D EM code that I've mentioned before in these hallowed halls. It takes an input file that's pretty expressive and human readable, generates the much more structured input file that the simulator engine needs, runs the postprocessor to generate the useful output (pictures, movies, and visualization files), and, optionally, puts an optimizing loop around all of that. The optimizer is powerful enough to tweak absolutely anything you give it, from the device geometry to the source characteristics to material properties, parametrized any way you like. (The manual is at

Doing all that in C++ would have taken me forever, but it was very straightforward in REXX.

Cheers

Phil Hobbs

Even though it had no real I/O, I kinda liked Pascal. For bit banging it's hard to beat PL/M, though.

On a sunny day (Sat, 01 Oct 2011 12:58:30 -0700) it happened Don Y wrote in :

He just likes to spout that anti-C jive, he has been doing it here for years.

He does not know that BASIC comes from B-SICK (B like in B movie), and SICK, they just put it together and left the 'C' out because they could not handle C, sort of phonetic spelling.

In my view the beauty of C is the simplicity of the language and that you can write your own libs, and have them portable to almost any thing that can execute code (like a processor).

Exactly, but it is nice to learn programming, Ba-SICK teaches some basic concepts. It sucked in the old times because of the line numbers, always you ran out of space between numbers, I first used B-Sick on a Commodore PET, cassette loader it had. There was a PDP10 or 11 too. IIRC I played moon landing game on that Commodore pet, it did not crash, but my lander did.

But J Larkin is a very good programmer, we all know here that he writes perfect code. Bug free. Come to think of it, maybe the 'B' in BASIC stands for 'Bug'. Bug-Sick :-)

On a sunny day (Sat, 01 Oct 2011 14:35:42 -0700) it happened Don Y wrote in :

The variants of scanf, make parsing files very easy and pleasant in C. malloc, free, libc, libmath, many GUI libs for many OSes, many multimedia libs want to write a video editor for Unix in BASIC? John still thinks in small simple linear embedded code projects on MS bloat. Where is your libmpeg3 John?

And neither of them are close to the optimal solution since C handles multidimensional arrays badly as a pointer to a pointer. A handful of very sophisticated optimising compilers might be able to unwind this loop structure in final optimisation but you cannot rely on it.

Correct fast code would be along the lines of: tvalue = value; for (r=0; r In this case, the most important thing is to recognize if it really

Most times performance is an issue but correctness is more important (although increasingly faster CPUs can hide the problem for a while at least). In my day anyone who could make the grade in the hard sciences was not encouraged to switch to computer science until post-graduate level. Though they could not prevent some of us from going to courses on mainframe architecture and compiler design.

And the differences can be important in image processing.

Actually theoretical chemists that do quantum mechanical simulations tend to be quite well informed about these issues.

They don't but they can read Knuths books if they are interested - still one of the best groundings in Computer Science even today. The computing for scientists course was actually quite good (and more importantly you didn't have to sign a no hacking into the OS agreement in blood like you did on the university mainframe).

Depends on the chemist - I have known some very talented programmers in amongst the theoretical chemistry groups.

Hardly any - including some of those that claim to have done so.

Exploiting a multiprocessor environment efficiently for a seriously CPU bound problem is extremely non-trivial. Most times you can only learn this by hard experience - the task that schedules and allocates work has to have the maximum priority if the workers are to be kept busy.

One thing that CS degrees could be criticised for is that they tend to churn out people proficient in coding small to medium sized projects in the current language du jour. This is an inadequate preparation for large scale software development which is where Computer Science really comes to the fore. There is an unfortunate tendency in software engineering to reinvent the wheel with monotonous regularity.

OS/2 for all its really good points reinvented *from scratch* things that were widely known in the minicomputer business. Knowing where to look to find prior art is something a good degree course should teach.

Regards, Martin Brown

Mpegs? For watching Americal Idol? I design real electronics.

The more dogmatic and demanding and boring a computer language, the better the outcomes. That's why banks use COBOL and the people who build airplanes and jet engines use Ada. C is a toy, and most programmers would rather play with toys than bear down on the actual problems they are hired to implement.

Consider: how many times is the average non-trivial C application compiled before it can be released to customers? And how many bugs does the first release typically have? And how many field upgrades will it have before it's bug-free and stable?

How many times is the average non-trivial PC board spun before it can be shipped to a customer? How many bugs is it expected to have? How many passes will it take to get it to be bug-free and stable?

Explain the ratios.

John

Not any more, idiot.

Probably. E.g., I suspect "IT" is barely "science" and more like "go figure out who unplugged the network switch -- and, while you're at it, install this software on Marilyn's PC"

I recall lots of buzz-words (concepts) but would be hard pressed to define most of them. T-machines, S-machines, etc. A tribute to the fact that it was the concepts that were important, not the lexicon.

I would enjoy retaking my freshman AI course today -- to see where the state of the art has progressed. We were taught using photocopies of the *draft* of Winston's book. (I saw an interview with him recently, somewhere. Amusing to see how much older he is! ;-)

One of my first jobs was working with Nova II's. Bit-toggling diagnostics (in octal) via the front panel switches. And wondering if you had remembered the opcodes for all of the instructions correctly in that instant before you hit the "run" switch. Of course, if you *didn't*, there wasn't much physical damage to be done -- though you may have had to reload the core (*real* core planes).

On microprocessor based systems, writing a debugger is a great way to give someone first-hand experience with the hardware. The functions that you are implementing are trivial (examine/modify memory, examine/modify processor state, etc.). There is no more efficient way to expose the programming model to the writer and see how the instruction set interacts with the machine's state: "Gee, how do I allow a user of this debugger to *modify* the overflow flag? Or, the half-carry?" From there, it is a lot smaller step to sort out how to write an MTOS -- since you now know how to save and restore the *entire* processor state, selectively. And, from that (plus some education), an RTOS.

Then, backport the debugger *into* that MTOS/RTOS environment! I.e., to be able to have a *live* system RUNNING while you are debugging and interacting with *one* of it's active tasks (instead of having to interact with the *entire* processor)

I think folks who work with the hardware have an easier time relating to what their HLL code is doing. Those dreaded "pointers" are seen for what they are -- addresses. Nothing magical nor anything to be "feared". Just "values" -- like "27" and "0xDEAFBEEF". The fact that those "values" can be used to access parts of physical memory is immaterial.

Also, a good feel for the hardware exposes shortcomings in the HLLs running atop it. "Grrrr... this would be *so* easy to do if I could just shift the 'carry' into the next word..."

And, it gives you a good foundation when/if you ever have to

Finally, it gives you a better appreciation for different techniques used to *implement* processors as well as architectural features. E.g., the 99000's "workspaces" were a dynamite idea... but, way too early for the silicon to catch up in terms of performance. (Though I can't see how it can ever have been a competitive technology with more traditional architectures :< OTOH, it never was given the opportunity to *evolve* so no idea where that may have eventually led!)

Always interesting to see which features/aspects of technologies thrive and which wither. For the life of me, the survival of the x86 has got to be the *worst* thing that has happened to software (and hardware)! I wonder how many hundreds of thousands of man-years were wasted as a result of it? :-/

Image processing needs some degree of caution, in order to work efficiently. However, normal day to day applications do not need too much manual optimization, the default virtual memory system works surprisingly well.

In the 1970's I was able to boost the performance of badly designed PDP-11/RSX-11 systems by at least a decade, doing this on a VAX/VMS system by fiddling only the virtual memory Sysgen parameters only produced 2-3 times improvement in performance. Current operating systems like Windows and Linux do not even allow too much virtual memory control.

Regarding image processing software, I have seen too many bad examples. Some allocate the whole image file into virtual memory (and in the worst case zeroes the huge table before reading it from the image file, causing a huge number of page faults). This is due to the Microsoft example, of checking disk file size, allocating a virtual memory buffer as big as the image and then reading to whole mess as a single operation.

Have you ever even seen a high end, maxed out enterprise server blade?