thats about right. I almost failed a 1st year computer science paper by never attending a tutorial. I hassled the HOD, and pointed out my average mark for tests & assignments was 100%. His reply "why are you doing this paper". My reply "prescribed course degree"
The first "real" job I had was at a company whose R&D department had a policy of not hiring (or even interviewing) CS grads; engineers only. s/w for stuff like elevators and cranes is too important to tolerate sloppy programming.
Do it. After some few hours of frustration and confusion, it will start to be easy, then fun. I whip out a PB program whenever I'd have to do something on a calculator more than a few times.
For little engineering thingies, I still prefer the 16-bit DOS version, where you can write a useful 5-line program in a minute or so. It works fine under XP, graphics and all. The equivalent 32-bit version is the Console Compiler, which retains the bog-simple Input/Locate/Print approach to the user interface.
Go for the 32-bit Console Compiler if you'll be thrashing really big arrays. 640K doesn't go far with some problems.
Yes and no. I use such state machines a great deal. (I posted earlier in response to the example, describing it as a "spaghetti sequence". If, however, there were some task-oriented logic to each state, I would see your point.
I'm explaining this badly. It's 5:18am and I need to fall over in a big heap. I'll disentangle my response later ;).
A computer without a jump instruction ? That would be usable only if the program restarted after executing the whole code address space to the end and the program counter (a simple hardware up-counter) wraps to zero. Of course, every instruction must be conditional, taking the same time regardless it did some actual work or just operated as a NOP instruction on this iteration. Perhaps handy in some DSP or PLC applications, since fSample = fClock / 2^n where n is the number of bits in the program counter.
There is plenty of competition in software, as you say. But it the corporate sector at least the OS and office software market has been dominated by a monopolistic vendor, and people put up with all sorts of abuse because of it. Personally, I haven't uses MS Word since a brief encounter with version 2 (on Win 3.11), but we non-MS Office users are in a minority (albeit growing a lot recently). People *still* buy MS Office, despite Open Office being freely available (or Star Office, for those wanting support and a few extra features), far safer to install, use and upgrade, and directly comparable in normal use. That's the result of monopoly power.
For certain other sectors, such as the EDA market, you have the strange system of having a number of vendors with their own mini-monopolies. The use of proprietary and undocumented file formats means that, say, Protel has a virtual monopoly on the market of Protel users. Newcomers can choose freely according to price, features, support, and so on, but existing users have great difficulty changing vendors because of compatibility problems with existing design files. So these vendors too can get away with selling buggy software and claiming it will be fixed with the next upgrade.
I think the #defines made a big difference to readability - PIC assembly falls into the category of being particularly weird.
C is known as a language that gives you enough rope to shoot yourself in the foot. When used properly, it is legible enough that there is no need to add much extra. Personally, I use a set of macros for bit manipulation - it allows me a consistent efficient interface that works on the wide variety of compilers and assemblers I use. But too much "personalisation" makes the code unreadable to others - and readability is key.
Yes, such things are foolish - trying to make C look like Pascal is like fitting a square peg in a round hole. And trying to use macros for the job is like using a screwdriver for the job, instead of a ready-made sledgehammer like p2c.
To be fair on Bjarne Stroustrup, I think a lot of people have completely misinterpreted what he was trying to do with C++, and how he expected it to be used. I remember reading his book "The C++ Programming Language" fifteen years ago, and thinking how totally different it was from all the other "teach yourself C++" books I'd looked at. As Steve says, good (or bad) design is language independent, but modern C++ gives so much greater scope for writing truly horrendous code than most other languages.
In article , Steve at fivetrees wrote: [..code without GOTO..]
Yes, it is much worse than code with GOTOs.
The whole point is to prove that it isn't the GOTO that is the problem. The fact that I can turn code with GOTOs into code without GOTOs by a method that does not address the spaghettiness I think is proof of this.
If the original was a state machine I'd agree (I use state machines a fair amount myself). However, the original was referring to a serving of spaghetti code. However you dress it up it's still spaghetti.
My original comment which originally started this thread referred to legions of gotos. I don't think I've seen code written in a higher level language with a lot of gotos which was not accompanied by a low level of discipline in the control flow. Gotos may not be inheritly evil, it's just that evil is their near-constant companion.
Yes it was a very cool OS, written in an Algol-like language, but I suspect MUCH closer to Algol-60.
Algol-68 was what happened when they got together too many language designers and handed out free LSD. I don't think anybody actually ever was able to write a real compiler for the 68 version.
How to you write up a standard that delineates between "bad" #defines and "good" #defines? :-) Or was the prohibition more reasonable in that it stated you shouldn't try to turn one programming language into another?
You realize that C is often considered just a really high level assembler, right? :-)
Not with me anymore. I switched to Cadsoft Eagle. Does have bugs but the company is very responsive and the bugs aren't too serious for me. Plus it's very reasonably priced, something that I can't say for many of the other CAD tools.
For individuals, I generally accept this argument.
For corporations, it's a naively simplstic attitude. In companies with hundreds, thousands, or tens of thousands of employees, re-training everyone from Office to OpenOffice, changing the format of all the forms & templates used, and re-writing all the macros used can be *very* expensive. (What many people don't realize is that Word, Excel, etc. all have Visual Basic script built-in for creating macros, and the programs themselves are COM compatible. As soon as anyone starts automating Office using VB or COM, switching over to OpenOffice becames a *much* larger undertaking.)
Realistically, any company that's been using Office for a number of years will have to have a slow migration to OpenOffice. I'm an utter Office rube, and even I create documents that OpenOffice will "mess us" when opening.
When it comes to RF design software, I've been impressed that AWR's claim (with Microwave Office) of being the "most open high frequency design platform" really is legitimate and not just a marketing claim. Many of their file formats are XML, and their scripting (good old VB script and COM again!) gives you full access to the internal design database. You really can "build a schematic" or layout from VB if you feel like it.
In general I agree with you, though. Even some of the more, umm... responsive... EDA vendors out there such as Pulsonix don't document their file formats.
Unfortunately EDA tools aren't popular enough, I suspect, that something like the Open Design Alliance (which contiuously reverse engineers the AutoCAD DXF file format -- even stuff like the encryption in the most recent versions -- and then sells open-source code to read & write it to support themselves) will spring up.
My impression has always been that he never intended it to be used as someone's "first" programming language -- it's definitely more targeted towards well-seasoned programmers who aren't going to shoot their foot off the first time you hand them a shotgun --, yet that's what it's become for many people.
Absolutely. The majority of people I've interviewed who put down "C++" experience on their resumes weren't even decent C programmers. (This is hardware designers, though, so we usually aren't emphasizing programming skills that much, but still...)
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.