The software development process.

Amen! Quote for the week!

My other advice is not to disparage error-detecting tools (of any kind) or error-preventing disciplines as "training wheels." Too many programmers want to ride without training wheels or without a helmet. But surely the one thing every programmer knows is his own fallibility.

Reply to
mc
Loading thread data ...

It can also used to detect word ordering (big vs little endian).

--Gene

Reply to
Gene S. Berkowitz

You can not write good s/w for some one else . You end up trying to figure how to make a career out of that one customer .

Leverage is a bad word , it finishes the job to early , makes s/w look too easy ......bad for paycheck . It means everything thing you write helps you to write the next higher stuff . Macros in assembly might look like leverage , not very good L' .

A well written modern Forth has ability to create very high leverage in the low levels that speed up your app and nix bugs . Im doin a Forth for ARM 9 .......free .

larwe wrote:

Reply to
werty

In the automotive industry, you have this little thing called "competition". People can easily chose to go to a different manufacturer next time. When you have a monopoly in a product field and related fields, and a free license to abuse it, you can use any dirty tricks you like to coerce people into buying upgrades and new versions. Somehow I don't think car customers would be too happy to hear that their car is only licensed for use in the one garage, and when you want to park somewhere else, you need to buy a new car.

Reply to
David Brown

Ask

them

guess.

It takes a lot of "miffing" to get people to move their 0wneD intellectual property from under one proprietary format to yet another - and even more to move to an open format.

not

will

meetings

later

electronics).

part

Well, what we usually get stung by is like this real-life example out of a tome of 48 pages of similar clarity and purpose:

""" R.xx.xx.x Power Management:

The OS shall not use any power management functions that effects performance. """

This is *also* set in stone - it even carries the impression of being fashioned by a mad prophet listening to a burning bush. Then we have to work out what the fschk it was that "God" *wanted* when this was spouted forth - this is where agile processes and unrestricted access to the actual end users (not the product managers that came up with this condensed wisdom) becomes pretty important. Because this will be going back & forth a lot of times!

Most formal processes do the opposite: They insert new layers of orcales and preachers to interpret the fleting words of the prophet(s) and systems of punishments for transgressors and rewards for syccophants. After a while all output from the official process is meetings and paperwork. (At the same time two-five guys will do the entire project while hiding in some abandoned test lab using some untraceable project number, just like before when the business started in the garage of one of the guys and they did not have any ISO 9000 certification).

Reply to
Frithiof Andreas Jensen

right.

Nah: The fastest way is to work at clarifying the specification until the job is trivial and can possible be solved with standard applications, some glue and a GUI slapped over the voids for the infidel ;-)

Reply to
Frithiof Andreas Jensen

almost

software

Give Python a look-see:

formatting link
- there is already a large body of Python applications and libraries available that support numeric applications. Mathplotlib f.ex.

Python applications will, with wery little care, run on Windows and Unix/Linux if one use the WxWidgets tools for the GUI. This may be important when you run out of CPU.

Reply to
Frithiof Andreas Jensen

message

right.

kind) or

programmers

surely the

I tend to write the unit tests first so when the errors go away, it is done. But this is easy in Python.

Reply to
Frithiof Andreas Jensen

In article , John Woodgate wrote: [....]

I'd bet you could pick up the Borland version of the Pascal language in a day. Once you know how to program, learning how to code in another reasonable language is quite easy.

If your really want to code in C, you can make a header file full of #defines that make the code much easier to read.

Example:

**** header file **** #define PLEASE #define THANKYOU ; #define IS #define THE #define SAME == #define AS #define IF if( #define THEN ){ #define ENDIF } #define LET *********

**** C file **** ..... IF x IS THE SAME AS y THEN LET Z = X + 1 THANKYOU ENDIF

****************

Somewhere I have a header file that IIRC has a few hundred lines that lets you write what look like paragraphs and compile them.

--
--
kensmith@rahul.net   forging knowledge
Reply to
Ken Smith

microsoft != standard

Chances are they won't work on the new OS from MS because of security concerns. You will only be allowed to run MS aproved applications to buy things from the MS web sites and write emails to the permitted recievers.

--
--
kensmith@rahul.net   forging knowledge
Reply to
Ken Smith

Well, the simulation part is easy, but adding GUIs will multiply the task severalfold, no matter what language you use. For quickie engineering apps, I use graphics displays but stick to simple character-oriented human interfaces... type "B" to set filter bandwidth sort of stuff.

PowerBasic Forms lets you design a real Microcrap type window and generates the os interface code for you, but it's always going to be the stupid async event-driven Windows junk to deal with.

John

Reply to
John Larkin

What's wrong with GOTO, other than that some academic panned it some decades ago, and gave us the ultimate goto-free language, Pascal or something. Conditional GOTO is the ideal control structure for fast, flat, absolutely reliable state machines.

John

Reply to
John Larkin

Do you mean that you've never used GOTO Zero? I used that a lot on the old Commodore 64 computers if I had to return to the start of a program from more than one place. That way all you had to do was put GOTO on the line and you saved a couple bytes. I also used small line numbers to save space.

The Commodore 128 was even better. It had a renumber command that let you specify the range, start point, and increment so you could spread out the program, then shrink a section to add more code.

--
Service to my country? Been there, Done that, and I've got my DD214 to
prove it.
Member of DAV #85.

Michael A. Terrell
Central Florida
Reply to
Michael A. Terrell

I remember some of the early Commodore 64 "renumbers" that only renumbered the

*lines themselves* and not the *gotos*. Sheesh! How useless is that?

I eventually ended up with a "Final Cartridge 3", which, I'd have to say, kicked ass (even if it did take them 3 tries to make it really, truly "final" :-) ). Besides the fastloader and the assembly language assembler/disassembler and program freezer and the many new BASIC commands, it renumbered programs correctly (both the lines and the gotos).

The first renumber program I ever used was the one on the Apple II that took over the wacky "&" (ampsersand) command that Steve & Steve had stuck in for just such utility programs to use.

Reply to
Joel Kolstad

Point at a random line of C++ code... how did you get there? First, untangle the compile-time nest of { and } things; then untangle the runtime calling sequence. Fun OO things and function overloading just add to the joy. Shouldn't involve more than 30 or 40 different files, if you're lucky.

Yup, he's the guy to blame.

"Dijkstra was known for his essays on programming; he was the first to make the claim that programming is so inherently difficult and complex that programmers need to harness every trick and abstraction possible in hopes of managing the complexity of it successfully."

and

"Dijkstra is also noted for never owning a computer and rarely using one."

from his bio on Wikipedia.

John

Reply to
John Larkin

For some reason, the Windows versions of PowerBasic require that all subroutines be placed before PBMAIN, and PBMAIN is itself a formal subroutine. So a program doesn't start "at the beginning."

John

Reply to
John Larkin

In message , dated Mon, 11 Sep 2006, Joel Kolstad writes

The BBC Micro handled calculated GOTO numbers and for GOSUB (IIRC) as well.

--
OOO - Own Opinions Only. Try www.jmwa.demon.co.uk and www.isce.org.uk
There are benefits from being irrational - just ask the square root of 2.
John Woodgate, J M Woodgate and Associates, Rayleigh, Essex UK
Reply to
John Woodgate

I'd forgotten that Basic had line numbers:-)

martin

Reply to
martin griffith

He's one to talk !

Graham

Reply to
Eeyore

Ah, well, I won't try to defend C++. It's broken. There are some good idea in OO, but C++ is a broken implementation. I agree with most, possibly all, of your comments.

We've talked about this before, so I'll simply repeat my position: good design is language (and language feature)-independent. A somewhat restricted toolkit (aka "discipline") actually helps comprehension. And comprehensibility is, or should be, the aim.

Heh. I happen to admire the chap hugely.

FWIW: my particular game is small-to-large volume embedded products which

*must* be bugfree, *must* be maintainable, and *must* be on time. I've studied all sorts of methodologies, and all sorts of languages, in my quest for robust and timely software. I've developed a set of tools and methodologies which work for me, and which - rarely - I see echoed in the more clueful companies I've worked with, which is nice. This quest - to formalise the process that results in high-quality code - is a bit of a passion of mine (as you may have noticed from previous postings ;)).

Some of my key mantras include:

- break a complex system down into a hierarchy of trivially simple things - define the interfaces between them carefully - avoid all interactions (use those interfaces, and don't work around them) - no globals (see above re interfaces) - try to keep things synchronous, or deal with asynchronous events synchronously - factorise: i.e. state things as simply as possible, and avoid duplicate code - debug for typos, not for failure to plan

There's more, but that's the essence of it. As I've said, the use of a GOTO per se is no big deal - it's the bigger picture that matters. I haven't used a GOTO to break a closed structure in 25 years or so now. There are *always* cleaner solutions, which render the problem more malleable and more maintainable. If you saw my C code, you'd be able to read it. It's kinda close to structured English. And yes, you *would* know how you arrived at any point in the program.

With apologies to the c.a.e. folks who've heard me pound this soapbox before... (which is why I've been avoiding this thread ;)).

Steve

formatting link

Reply to
Steve at fivetrees

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.