The value of a CS education

Yes, but they come at a cost. E.g., scanf(3c) carries all the baggage necessary to parse floats -- even if you don't have any floats to parse! IMO, printf(3c) has got to be the single biggest *pig* in the standard libraries. Something that you *immediately* rewrite (if you have *any* performance/resource constraints). Or, do away with in favor of something like a homegrown itoa.

Interesting choice of application!

BASIC is great if you want a four function calculator. You don't have to *do* anything to crank out three lines of code in BASIC. No worrying about a linkage editor; including other files/dependencies, etc.

Of course, that comes at a price. What you get is *all* you get. Want to support arbitrary precision arithmetic? Sorry. Can't do that. Want to write an operating system for an arbitrary processor? Sorry, can't do that. Want to write a (BASIC!) compiler for another architecture? No, you REALLY don't *want* to do that!

It's the programming equivalent of building a PC -- by *assembling* COTS parts and just plugging the right wires into the right boards. Need a bigger power supply? Need a faster CPU? Need a second disk drive? etc.

Bending the (silly) analogy even further... the problem then lies when you *don't* want to build a PC but, rather, want to build a cell phone ("What's in the suitcase, Don?" "Oh, that's my new cell phone! Here, help me lift it onto the table and I'll show you..."). Or, when you want to run something *other* than 'Windows': "Hmmm... why can't I find any information on this chipset?" "You don't *need* to know anything about the insides of that chipset!" "How am I going to write a driver for it?" "Just go to the MS website and download the driver." "Yeah, but I'm not running windows!" Equivalently: "Why can't I find any information on IPC to this BASIC application?" "You don't need to know anything about how IPC is supported!" "How am I going to talk to it from this *other* application?" "Just write the other application in BASIC and use the FIGGLE keyword" "Yeah, but the other application is written in Prolog!"

I suspect he's never written/designed a *big* piece of software. E.g., 10 KLoC is a "class project" (i.e., something that you crank out *while* taking several other courses) -- not a real project. Add another zero and then tell me what you think about your choice of tools.

I've never designed a microwave cavity. I know few of the issues involved. But, more importantly, I've got a feel for how much I *don't* know to avoid telling the microwave engineer how he should do his job -- or which tools he should use to do it!

:>

If he's happy with the tools *he* uses, then that's GREAT for him! I'd be wary of him telling me what tools *I* should use -- given that apparent experience deficit.

On a sunny day (Sun, 02 Oct 2011 10:17:00 -0700) it happened John Larkin wrote in :

Well, maybe you do not know about it, and the fight between Intel and AMD for example, Intel not even being able to do a direct X 10 driver for Atom,

??

I really give up here trying to follow you. C serves me well, I have the libs I need, the tools I need, and it is portable. It is not demanding, but just like any job you need to pay attention. If you are smoking marihuana maybe it is not for you.

And the banks are not doing so well. I wanted to write an educational posting about writing financial software. Basically it is very simple: You should target to flip the one -but-highest bit. Not the highest bit, thats is the sign bit, that will set you negative, that is what that Swiss guy did who made 2 billion deficit recently. Greed, he went a -bit- too far.

Only very experienced financial expert can go for the highest bit, the NSB, it is called going short. Hope this helps. Oh, and I wrote all that stuff in C.

We will talk again after you actually wrote some code.

I dunno. But if it works, like the stuff you make, that does not mean it is the best way, like your manual stabilised HV generator. And plenty more examples I am sure.

Where are are all the flowers gone long time passing.

Cheer up, rock&roll, take a break.

What ratios? Golden ratio?

I meant: if you hire a programmer you should expect the person is capable of reading a specification (or system design) and produce a piece of software which works. Perhaps some analysis too.

I'd go the other way around. Perhaps hire someone who can create a good system design and let a programmer convert the design into a piece of software.

On a sunny day (Sun, 02 Oct 2011 12:13:18 -0700) it happened Don Y wrote in :

There is Bison, yacc, I sometimes write my own parser code, use read() to get some bytes. It all depends.

Of course John can write a Usenet newsreader too in minutes in his BASIC:

The list is very long, *I* could not write any of that stuff in BASIC for Linux (or MS windows) (I have some BASIC compiler on this machine).

It was intended to draw attention to the different pattern of accessing memory locations. I tried to remove any other "distractions" from the example (e.g., chosing a trivial -- though not constant! -- value for the assignment).

My first idea was just to replace "r*c" with "0" but I feared that would distract readers into looking for, e.g., memset() type solutions.

The cost of the page faults far outweighs the costs of indexing pointers.

Actually, I would eliminate the multiplication operator and replace inner loop with something like:

{ value = 0; for (c=0; c The problem is far more devastating when the task is to transpose a

Exactly. But, it requires a level of familiarity with the language and underlying iron that a non-CS person would have to *stumble* upon.

Agreed.

This, IMO, is the current bane of software development. The speed of the processor hides the inefficiencies in many designs. These inefficiencies only rear their heads *later* -- when those applications/tasks are co-operating with others... and suddenly seem very lethargic!

Its interesting to watch how the performance of many applications declines with increasing release numbers. Drag out an older version and run it on *today's* hardware and be blown away by how *fast* it seems! I.e., when the application can directly benefit from Moore's Law (instead of giving up all those gains to bloatware, sluggish OS's, etc.)

Or DBMS applications.

Or, any application that processes multiple instances of a same/similar object. E.g., walking through the objects repeatedly vs. processing one object (completely!) at a time.

Sure. I.e., get a CS education, even if informally. But, they have to stumble upon the issues before they can even begin to realize that the issues exist! *Then*, go looking for the information to fix it.

My favorite CS class (I was in the EE curriculum) was "Introduction to Algorithms". The name was misleading as most of the algorithms presented were pretty exotic (CORDIC, A*, etc.). It wasn't oriented to writing code but, rather, understanding other relationships that could be exploited in data and clever ways of using that knowledge to reduce the complexity of tasks ("chores"?).

We had at least thirty full fledged mainframe systems for coursework. It seemed like each professor had his own pet system to experiment on.

I recall one course where the lab was equipped with DECwriters (so you could have hard-copy of your work to review back in the dorm). The system had two physical disk volumes: 0 and 1. A favorite trick was to finish your homework -- at 3AM on the day it was due, of course -- and then list the contents of drive 2! Then, tear the "evidence" off the DECwriter and casually leave the room. It would be a good 15 seconds before the buffers in the DECwriters would empty and the room go silent. Followed shortly thereafter by "Oh, sh*t!" (since those still in the room knew they would be unable to turn in their homework that day... no one to call to fix the system at that hour!).

You can do a lot with a second processor even if you don't look for an optimal solution. E.g., I have lots of signal processing to do in one of my applications, nearly continuously. Devoting a single processor to that aspect of the product greatly simplifies the complexity of the overall task. I.e., the communications are inherently localized in that split -- whereas a general purpose approach (with two processors) would not be able to benefit from this application-specific knowledge (unless I intentionally put that bias into the design of the scheduler).

This is what I have been told to be the current state of the field. Short-term focus instead of a deeper/broader knowledge base. (e.g., witness how popular Java is... until something *else* comes along and displaces it. Not because of merit but, rather, "fashion" -- as Phil would say)

Yup. Anyone can throw together a piece of code in a day/week/month. Where the real issue lies is those tasks that are measured in manYEARS instead of manDAYs. Make a mistake early on (because you weren't disciplined or informed enough) and you risk doubling a *big* effort (instead of a trivial one).

Yes! Everyone (client and developer alike) thinks that their product/project is UNIQUE! Among the applications that I am developing currently, are two *extremely* unusual ones. Totally different fields. Totally different lexicons. etc.

After studying them for many months (no, you don't sit down on Day 1 and start writing code!), I laughed at the realization that they are, essentially, the *same* application, viewed from two different perspectives with two different lexicons.

The same holds true of the media service system I am developing for the (this) house. The solution maps directly onto an application that I have been asked to explore for another firm. No, they aren't interested in audio/video... but, the underlying hardware and software technologies have a perfect correlation!

When you look at Knuth's 3 volumes (someday he will write more?), it looks like a paltry bit of text. But, once you have digested it all and thought about *real* applications, it is humbling to see how much ground those texts cover! As if he had discovered Ohm's Law (for software). :-/

C'mon, if you want to talk about inefficiently reinventing the wheel, look at MS! Aside from the glitz, the PC is now *almost* to the point where we were 40 years ago!

(sigh) Dartmouth BASIC (the very same BASIC that you refer to, below). Version 4 (some years after the original release) description here:

(gotta love Al's archive! Well worth a visit :> )

In particular:

Page 46: "In addition to the standard functions, you can define any other function ... by use of a DEF statement. The name of the defined function must be three letters, the firts two of which are FN. Hence, you may define up to 26 functions, e.g., FNA, FNB, etc."

As to my comment about "an equally restrictive set of variable names":

Page 14: "A numerical variable in BASIC is denoted by any letter or by any letter followed by a single digit."

I refer you to the above document, again:

Page 76: "Only 100 constants may occur in the program."

Please note the names of the authors of the document:

John G Kem*E*ny Thomas E Kurtz

I wasn't talking about "any current implementation". I was talking about "Dartmouth BASIC". When you talk about "C", are you talking about GNU C? MS C? Borland C? Or *ANSI* C??

Please, reread the preceding paragraph.

AlwaysWrong is *ALWAYS* wrong. Banks certainly do use COBOL.

example,

some BASICK,

mean real problems.

Google digital camera bugs for some fun.

Obviously.

Never touch the stuff. I hate hallucinigens.

I've sold (or had other people sell!) maybe 5 billion dollars worth of stuff with my code running it, including three RTOSs. If you count the products shipped from systems that are controlled by my code, it's in the tens of billions. The biggest-dollar commercial app is in 68K assembly code, and it was shipped bug-free, and has been in production for 8 years, no changes, no bugs. My code directly fires the NIF laser, the biggest laser in the world. No bugs.

Do you have any commercial products with your code in them? How did they do in the field?

John

Hi Phil,

Huh? Did I miss something in my review? I was looking for something that would do exactly that (and with simple/intuitive syntax) but didn't note any IPC support in REXX.

How are you "gluing programs together"? Plumbing stdout to stdin? Or, passing information via the filesystem?

I know the lack of strict typing got me nervous. I could just imagine the problems I'd have to remotely debug where a user

I'll dig through the manual for more information. But, essentially, you're just "reformatting" text (?). I.e., you take a file, chew on it for a while, then spit out another file (that essentially represents the same information in a different form) and feed that to another process?

Having *said* that, I should verify that the "font" is, indeed,

I don't find *anything* "easy" to do in C++. :< I think C++'s appeal is for building complex objects that can be REUSED (often) in other applications. Implicit in that is some *need* for reusable objects.

Since objects between applications are rarely *identical* (aside from trivial objects like complex numbers, strings, etc.), I haven't found a good payback in terms of time invested in building classes vs. time *saved* (re)using them, later!

Are you using a PC? How old is yours?

As I recall, there were no PCs 40 years ago. Just because you think they are inefficient doesn't mean you are not enjoying the fruits.

Piss on you.

Exactly! Yet C has *thrived* while BASIC -- in ALL of it's varied flavors -- has never been more than a teaching toy. For two languages with roughly contemporary origins to have such disparate results says something about those two languages -- at least to *me*, you may think otherwise.

Why *not*? Should we also disallow Lisp/Scheme, Prolog, APL, Pascal, Algol, ML, PostScript, Java, Python, etc.? (hmm... I wonder how many languages I can come up with off the top of my head...)

What criteria are you using to decide languages worth consideration?

What application domain(s) are you planning on addressing?

His perogative. If he wants to learn something or can *teach* something, fine. OTOH, to just beat your chest and say "I like Blue" will earn you a giant .

I would argue that the beauty of *BASIC* is its simplicity! E.g., I can write a three line program to compute a set of resistor values for a particular network in less time than I can open an *editor* to start writing one in C (and then having to remember which headers to include, which libraries to link against, etc.).

BASIC is "Programming for Dummies" (no offense intended -- a reference to the series of yellow books with that thematic title).

The problem with BASIC is that it quickly reaches its limits for practical applications -- esp the sorts of applications that I am involved with.

E.g., I want a language to *seamlessly* allow multiple "programs" to intercommunicate. I don't want to have to bother with twiddling byte orders, setting up network connections, worrying about differences in data formats, etc. Even if those "programs" co-operate on the same processor.

I want a language that lets me twiddle bits to manipulate hardware registers (without clumsy syntax) and, in the next statement, export a value to a network client halfway around the world.

I want a language that makes *my* job easier. If it makes

Some BASICs had a RENUMBER command. You learned to invoke it every few minutes! :>

My first BASIC programs were written on a Nova I (?) using an ASR 33 talking to the processor over a 300 baud acoustical modem (~1970). And, punching tape to "archive" your work :-/

perfect code.

The Linux pthreads implementation is so brain-dead in this regard that it makes my head hurt. There's no way to express the requirement that thread N is the most important in the app, unless you run as root in the real-time class, and then when you try adjusting priorities, _all_ your threads are the most important on the machine, and everything else slows to a crawl. You can't have N normal and 1 real-time thread in one process. It's dumber than a bag full of hammers.

That makes writing clusterized or multicore code with good scaling performance very difficult on Linux. It's easier on Windows, and was easier still in OS/2. Note that the issue is relative priorties of threads in an app, not snitching resources from others--most of the time I'd be happy with all the compute threads running at niceness +20, and the scheduling and communications threads at +19.

But no, you can't do that, or couldn't as of 2008, the last time I tried.

Razza frazza &8%$!! communist know-it alls. Growl.

Cheers

Phil Hobbs

PowerBasic has serious business and scientific users. I've coded algorithms in PB just to prove to C programmers that their code was running slow by several times.

It means that C amuses programmers more than BASIC does.

Ada is even less amusing than Basic. Which is why really important stuff is usually coded in Ada.

Far too many. But allow? Disallow? Who could do that?

Safety. Readability. Long-term maintainability. Sometimes performance. Sometimes code size.

I use PowerBasic for engineering apps. My own embedded stuff is mostly bare metal assembly, but my guys are programming embedded ARMs in C. The C stuff is usually messy and buggy, and if Code Red ever gets out an IDE release that doesn't have a zillion new and old quirks and bugs, I'll be impressed.

I do insist that the final compile be done under 'make' and the GCC compiler, no IDE, with non-licensed non-dongled non-VCS files and tools that we can run again five years from now. And I insist that everything be commented and have lots of clear README files. We do formal releases to manufacturing like any other engineering documents: rev A, rev B...

John

Perl, FORTRAN, COBOL, PROLOG, any number of assembly languages, VHDL, Verilog ...

Cheers! Rich

Well, Javascript should definitely be banned, as well as FLASH! Why else could it be that with 20 MBPS bandwidth, web pages take longer to load than they did when all we had was 56K dialup?

Cheers! Rich

=20

I say that was a foolishly picked nit. Just when did the Altair 8800 hit the market, or the apple 2. What kinds of thing were they capable of and used for.

?-)

Lo.

Gee, i often seem to find the lowest price vendor is Sum Dung Thro. Terrible incoming AQL though.

?-)

that

=20

Wiki

System=20

complicated

for

Algol.

=20

instrument=20

LabView.

around

=20

=20

=20

didn't=20

like,=20

=20

is in

VHDL occurred before Ada in the timeline, a guv'ment project like FORTRAN and COBOL just the same.

?-)