This is only slightly relevant, as these aren't laser diodes, but but I noticed this AM standard long-wave UV LEDs have hit the electronics surplus market in big numbers lately for cheep (All Electronics has these at $1.75). All you experimenters out there can stock up now!
The seemed to me a recipe for bloat/cache thrashing/ugliness.
Not when used properly. It should be mentioned, however, that early implementations in a number of compilers tended to create object code for identical template instances in multiple places (basically treating templates like your "super #define"). This really did_ lead to a great deal of bloat.
Modern compilers (at least the ones I use) instantiate templates more intelligently. The only real problem I've seen is that templates, like a lot of useful tools, can hide enough underlying complexity that a naive programmer can underestimate the actual amount of code generated for a given template instantiated over many types. This is a programmer issue, though, not a template issue.
While I was really speaking in the mathematical sense, note that minimum wage for workers in the US who receive more than $30/month in tips is actually $2.13/hr. The current US minimum wage for other non-exempt workers stands at $5.15.
Of course under some circumstances, salaried workers can also end up making less than minimum wage, depending on salary versus actual hours worked.
Well, I'm just guessing, but I've always assumed most (or at least many)/.'rs are either students or unemployed. They may not be pulling down 5 or 6-digit salaries at all.
By the way, it _is_ possible to get $4.00/hr and pull down 5 digits... Although I don't think at that point it would be termed "pulling down". More like "scraping by".
Cheers -- m
... because in no other era could my penis have had this much correspondence dedicated to its well-being. We're living in a Golden Age, people, but none of you appreciate it...
Re:Sweet check out the screenshots
on
Myth II Updated
·
· Score: 1, Offtopic
Avoid the tubgirl link unless you want to be emotionally scarred for life...
The grammar in the second AC posting is flawless. Plus -- and this is only a guess -- the author is probably possessed of extraordinary intelligence and rugged good looks. I could be wrong, but I doubt it.
Patterns are always used when just about anyone writes code, unless the writer is doing something completely novel. The movement behind the whole pattern thing is simply to publish these, so we don't have to constantly re-invent the wheel. As such, patterns aren't something that's simply "interesting to think about".
Framing user requirements is another animal altogether and has nothing to do with design patterns at all, except to the extent that the patterns chosen will depend on the design of the software, which in turn depends (ultimately) on functional requirements.
I'll second your opinion on this book, although it's really not a methodology book in any way, shape or form. As your subject line states, it's more "meta-programming".
Methodology books aren't completely useless, provided you avoid slavish adherence to any one approach. The best approaches to software development have to take into account not only the actual task at hand, but also indirect (often economic in the case of commercial development) factors: expected life cycle, cost targets, hard release dates, etc. I have yet to find a single methodology that does this for me, although I have been able to take away useful ideas from some.
Care to name some software that is "only available from microsoft...[with] no comparible[sic] products" ??
He may have meant by this "software supported only on Microsoft platforms", which includes, basically, ka-gillions of applications from games to vertical apps, not to mention driver support.
I began experimenting with Linux when the old SLS floppy images came out, and have used it regularly since 1.2 (I even contributed a smidgen of code to the ip masquerading subsystem), but the poster is essentially correct: an outright ban is a really bad idea.
While this horse has been beaten pretty much to death, pre-loaded DLLs are not the only reason IE loads faster than Mozilla. IE also has an advantage over Mozilla because the windows version of Mozilla is a pig. Opera loads faster than Mozilla as well, and it ain't because MS built in special support for the nice folks over at Opera.
How exactly does one "win" a Slashdot argument anyway? Especially when your opponent resorts to proof by repeated assertions, and simply claims that accuracy is unimportant? Well, yes, if accuracy isn't important, C++, Java, and C# are all just C.
And if I were claiming that accuracy is never important, cobol and forth would also be C. But then I never claimed that accuracy was unimportant; I merely claimed that for the purposes of this discussion, the term 'C' is "accurate enough". Put another way, I have defined 'C' in accordance with the common usage of the term among those of us making a living in the field. This is neither unreasonable nor illogical. It's how language works.
As to the question of proof, neither one of us has offered "proof" of anything, logical or otherwise, since this thread degenerated into a semantic quibble by pretty much any standard some time ago. Haven't you been following along?
And by the way, one "wins" an argument on Slashdot by having the last word.
This definition is both logically inconsistent and subjective.
Now you're just being silly. As I pointed out before, nobody (other than you, it would seem) demands that minor language deviations (i.e. K&R and others) must be termed "C-like" in the course of informal discussions such as this one. Put another way, semantic rigidity on your part isn't going to win you this argument. You remain as wrong as ever; C is perfectly suited to 8-bit development.
Surrender now, and I'll consider sparing your women and children...
If it precludes recursion, then it's not C. Don't change the definition to suit your argument, because C is an international standard.
First of all, your assertion that C is unsuited for 8-bit devices is simply wrong. C compilers are widely used in the embedded development world with extremely limited machines, and such compilers work very well indeed.
As to what constitutes a 'C' complier, you're splitting hairs. If you like, then I'll concede the point that, yes indeed, a fully standards-compliant C compiler is indeed unsuitable for most 8-bit development.
Using your reasoning,though, K&R C isn't really C either, since it isn't ANSI standard. A compiler that takes code which is recognizably C is C. Period. Not ANSI C or even standards compliant, granted, but C nonetheless. You know C? You know the hardware? Then you can use these compilers immediately.
Having used both straight assembler and these same compilers pretty extensively on 8-bit platforms (68HC11, PIC and AVR in my case)I can assure you that they are entirely well-suited for their little respective corners of the embedded universe. Do they produce the highly portable code you might expect of a standards-compliant compiler? Of course not. But then neither would any other language suitable for use with these platforms -- and in any case, portability is the least of your concerns working on a microcontroller with 1024 bytes or less of program memory.
C is a horrible match for the 6502. This is a processor with a 256 byte stack and no stack frame support.
It's not really C that you're referring to, it's the way most compilers use the stack.
Actually, there are C compilers available for PIC microcontrollers (and similar devices) that are even more limited than the 6502: 8 byte hardware stack (not directly accessible from code), Harvard architecture, etc. These work quite nicely, although they can't use the stack for much, instead using and intelligently reusing registers for parameter passing and local variables. All of this requires call-tree analysis, which precludes recursion. But then you'd be insane to write recursive code on a machine with an 8-byte stack.
I imagine that the problem lies less in computing the taxes, but in actually paying them to the corect parties, along with the appropriate paperwork. Streamlining that part would undoubtedly make compliance a lot less burdensome.
Slashdot Mirror
This is only slightly relevant, as these aren't laser diodes, but but I noticed this AM standard long-wave UV LEDs have hit the electronics surplus market in big numbers lately for cheep (All Electronics has these at $1.75). All you experimenters out there can stock up now!
Once the price of cars drops, though, I'm sure we'll see a lot more of this kind of thing...
Which is why we surgically implant the phone into junior's abdomen. Let's see the little nippers get around THAT one...
To keep them from deviating too close to the refrigerator? Sign me up!
Spam is bad, targetted or not. If I didn't ask for it I don't want it. So, yes, basically, it's all bad.
Not when used properly. It should be mentioned, however, that early implementations in a number of compilers tended to create object code for identical template instances in multiple places (basically treating templates like your "super #define"). This really did_ lead to a great deal of bloat.
Modern compilers (at least the ones I use) instantiate templates more intelligently. The only real problem I've seen is that templates, like a lot of useful tools, can hide enough underlying complexity that a naive programmer can underestimate the actual amount of code generated for a given template instantiated over many types. This is a programmer issue, though, not a template issue.
While I was really speaking in the mathematical sense, note that minimum wage for workers in the US who receive more than $30/month in tips is actually $2.13/hr. The current US minimum wage for other non-exempt workers stands at $5.15.
Of course under some circumstances, salaried workers can also end up making less than minimum wage, depending on salary versus actual hours worked.
Low wages are not, those damned Indians will just use it to build more casinos...
By the way, it _is_ possible to get $4.00/hr and pull down 5 digits... Although I don't think at that point it would be termed "pulling down". More like "scraping by". Cheers -- m
... because in no other era could my penis have had this much correspondence dedicated to its well-being. We're living in a Golden Age, people, but none of you appreciate it...
Avoid the tubgirl link unless you want to be emotionally scarred for life...
The grammar in the second AC posting is flawless. Plus -- and this is only a guess -- the author is probably possessed of extraordinary intelligence and rugged good looks. I could be wrong, but I doubt it.
The article also fails to mention that Farechaser was sentenced to death by lethal injection in the same decision...
Patterns are always used when just about anyone writes code, unless the writer is doing something completely novel. The movement behind the whole pattern thing is simply to publish these, so we don't have to constantly re-invent the wheel. As such, patterns aren't something that's simply "interesting to think about".
Framing user requirements is another animal altogether and has nothing to do with design patterns at all, except to the extent that the patterns chosen will depend on the design of the software, which in turn depends (ultimately) on functional requirements.
Methodology books aren't completely useless, provided you avoid slavish adherence to any one approach. The best approaches to software development have to take into account not only the actual task at hand, but also indirect (often economic in the case of commercial development) factors: expected life cycle, cost targets, hard release dates, etc. I have yet to find a single methodology that does this for me, although I have been able to take away useful ideas from some.
He may have meant by this "software supported only on Microsoft platforms", which includes, basically, ka-gillions of applications from games to vertical apps, not to mention driver support.
I began experimenting with Linux when the old SLS floppy images came out, and have used it regularly since 1.2 (I even contributed a smidgen of code to the ip masquerading subsystem), but the poster is essentially correct: an outright ban is a really bad idea.
While this horse has been beaten pretty much to death, pre-loaded DLLs are not the only reason IE loads faster than Mozilla. IE also has an advantage over Mozilla because the windows version of Mozilla is a pig. Opera loads faster than Mozilla as well, and it ain't because MS built in special support for the nice folks over at Opera.
No, no. I'm feeling magnanimous today. The victory goes to you.
And if I were claiming that accuracy is never important, cobol and forth would also be C. But then I never claimed that accuracy was unimportant; I merely claimed that for the purposes of this discussion, the term 'C' is "accurate enough". Put another way, I have defined 'C' in accordance with the common usage of the term among those of us making a living in the field. This is neither unreasonable nor illogical. It's how language works.
As to the question of proof, neither one of us has offered "proof" of anything, logical or otherwise, since this thread degenerated into a semantic quibble by pretty much any standard some time ago. Haven't you been following along?
And by the way, one "wins" an argument on Slashdot by having the last word.
Now you're just being silly. As I pointed out before, nobody (other than you, it would seem) demands that minor language deviations (i.e. K&R and others) must be termed "C-like" in the course of informal discussions such as this one. Put another way, semantic rigidity on your part isn't going to win you this argument. You remain as wrong as ever; C is perfectly suited to 8-bit development.
Surrender now, and I'll consider sparing your women and children...
First of all, your assertion that C is unsuited for 8-bit devices is simply wrong. C compilers are widely used in the embedded development world with extremely limited machines, and such compilers work very well indeed.
As to what constitutes a 'C' complier, you're splitting hairs. If you like, then I'll concede the point that, yes indeed, a fully standards-compliant C compiler is indeed unsuitable for most 8-bit development.
Using your reasoning,though, K&R C isn't really C either, since it isn't ANSI standard. A compiler that takes code which is recognizably C is C. Period. Not ANSI C or even standards compliant, granted, but C nonetheless. You know C? You know the hardware? Then you can use these compilers immediately.
Having used both straight assembler and these same compilers pretty extensively on 8-bit platforms (68HC11, PIC and AVR in my case)I can assure you that they are entirely well-suited for their little respective corners of the embedded universe. Do they produce the highly portable code you might expect of a standards-compliant compiler? Of course not. But then neither would any other language suitable for use with these platforms -- and in any case, portability is the least of your concerns working on a microcontroller with 1024 bytes or less of program memory.
It's not really C that you're referring to, it's the way most compilers use the stack.
Actually, there are C compilers available for PIC microcontrollers (and similar devices) that are even more limited than the 6502: 8 byte hardware stack (not directly accessible from code), Harvard architecture, etc. These work quite nicely, although they can't use the stack for much, instead using and intelligently reusing registers for parameter passing and local variables. All of this requires call-tree analysis, which precludes recursion. But then you'd be insane to write recursive code on a machine with an 8-byte stack.
I imagine that the problem lies less in computing the taxes, but in actually paying them to the corect parties, along with the appropriate paperwork. Streamlining that part would undoubtedly make compliance a lot less burdensome.
But I think the idea is that bacterial cells can synthesize elements significantly smaller than themselves.