Signal Engineer

Biography has not been added


's contributions
    • I've never found any difficulty writing anything I can write in C in Pascal instead - but Pascal forces me to make my intention explicit from the start, and express it unambiguously, and then the compiler has a much simpler task and can produce *better, simpler* code. The language compiler will pick up most violations of good practice at compile-time, rather than producing code which blows up at run-time. If it compiles, it *will* run (maybe it won't do what you wanted, but that's *your* fault). The most powerful word in pascal is "type" - and you can have any type you can imagine and nest any types. The variant type construct is so expressive you can express constructs that require the use of the pre-processor in C (they work without generating any extra code, since they just express another view of the same data in memory) - and the C pre-processor is where most of the horrors lie. Any direct translation from C code to pascal gives smaller faster executable code. Mere prejudice ('not invented here') prevented pascal from becoming the default choice. N. Wirth did an absolutely brilliant job.

    • this is common to all OOP languages - a class KNOWS which class it is, what kind of object an instance of the class is. So it's an underpinning of OOP in general, not just C++

    • that's too convenient and sometimes too cowardly, mate - what if someone might die or be injured if you don't speak up?

    • a friend is a senior programmer - he got his first real programming job as a C programmer, though he'd only used assemblers, fortran and algol 'til then. He told me that the only reason he got the job was he lied in his C.V. and he lied in the interview - the latter was convincing because he had a great short-term memory and had 'scanned' (not read) Kernighan and Ritchie in the plane on the way there - a 1- hous flight - so at least sounded convincing. They didn't test.

    • here in UK, that would cost me the equivalent of 2300 dollars a year - and people complain if they are billed half that for all the other energy they use, never mind the A/C. A school here redesigned their A/C system with the help of an architect to get a system that was mostly driven by (free) air flow over the building - saving tens of thousands of pounds over the year. You might like to think about that. That's truly green, and very meaningful.

    • Jack, I know what a kW is, it's a measure of power equal to 1000 joules per second. I know what a kWh is, it's a measure of energy indicating a power of 1kW consumed for 1 hour, hence 3.6 Megajoules. The article says "on the order of 1.5 billion KW/hr per year of waste, two orders of magnitudes lower than the Energystar figures. But a billion+ KW/hr is a lot of waste." What's a kW/hr ??

    • wilc2010 and jb232 - you guys could have liked the original Borland definition of classes in object-oriented Pascal - the one from Borland Pascal5.5 to BP7, about 1986 to 1989 - before the new version called 'ObjectPascal' or 'Delphi' (originally BP8). Nothing happened automatically or hidden from view - it's all explicit, clear and simple, and under your control. Like C++ but with all the hidden behaviour removed. You decide where, when, and in what order, constructors are called, if at all. Unfortunately -- Borland then thought for their next iteration (ObjectPascal, or Delphi) that programmers shouldn't be allowed the chance to easily manipulate pointers, as was the fashionable paradigm, so they made all 'objects' only accessible through references allocated with new() - but at least, even there, the particular constructor which is used (if not the default do-nothing-except-allocate-space) is called-by-name explicitly. But this also meant you couldn't create a temporary (local) object on the stack. Sadly, the original simple, tiny, powerful, strongly-typed, and very flexible language that was object-oriented pascal is long dead. It would have suited embedded code very well.

    • Most seem to miss the essence - the difference between Engineering and Art. In pure art, you can do whatever you like, whatever you can conceive, there are no CONSTRAINTS. Engineering IS art, BUT always Art with Constraints - as someone once said, it's the art of the Possible. So the thing you're engineering has to 'work', and 'work fast enough', and it has to be of such a size, no more, and it must use no more than a certain amount of resource (memory for example) and... etc etc. That means that even today when memory is often available in huge amounts cheaply, power and size constraints mean that embedded software engineering is 'real engineering' - you can't just do whatever you like, only what you can within externally-imposed limits, whereas writing application software increasingly ISN'T engineering, there's so much memory, more than adequate processing speed, so much available resource in general, that you really can in effect do whatever you like within the strictly defined limits of the definition of 'software'. I often in the distant past had to program a board with 1kB of ram, and 2kB of rom or less, fit everything in and make the thing do the job quickly enough at a <1M clock rate. Cobol, algol and Fortran programmers in the early sixties had to work with tiny amounts of 'core'. In either case, it was engineering, and embedded mostly still is.