Correct. That was when MS decided that instead of an application-centric UI, they preferred a document-centric one. So instead of Program Manager as your shell (which was an MDI application -- Program Groups were the MDI child windows contained within it), where you first picked the application you wanted to use, and then from within that application opened the document you wanted to work on, since the Win95 shell you have a file or document Explorer (an SDI (Single Document Interface, not "star wars"!) app), typically opening by default to a folder called My Documents, where you just directly pick the document you want to work on.
(Windows Explorer is still a little MDI-ish, in the sense that all the hierarchies of all your volumes and shares are all tossed into and confined by one list pane, that you're somehow supposed to be able to easily work with. Too much a pain in the ass trying to copy a file somewhere where the destination is two page-downs in that pane, so I made some shortcuts that instantiate an Explorer rooted on just a certain volume -- if I want to copy something from C: to D:, I want a window for each that I can view mostly side-by-side and drag-n-drop between. I view the "copy and paste files" thing as a kludge to work around Windows Explorer's unfortunate all-in-one-window UI.)
HTML is the universal data format over the HTTP protocol. Text is the universal data format over the SMTP/POP3/IMAP protocols. Why do you think binaries need to be encoded in email? Because it's an ASCII medium.
People who didn't know the Internet existed before the birth of the WWW think that that's all there is, and that email and everything else runs on top of the WWW. It doesn't.
If I thought morse code was the schweetest form of communication, and sent out all my emails in dots and dashes, that wouldn't make them not evil. It would still be an annoying and inappropriate use of the medium.
Grandparent is not flamebait. It's even uglier in Outlook as Plain Text, which you need to set for security purposes. I get "legit spams" from places like MS (employer gets us MSDN subscriptions) and the Uni I take an occasional class at, and I can't make any sense out of them so I delete them 100 out of 100 times.
If I had the time, I would. But in this field it's a struggle to maintain employability. So I have to concentrate on established and popular technologies.
If he had just gotten his CS degree, then you probably didn't hire a programmer. He should certainly know what a hash and what a sort are, although someone who worked for me who wrote their own sort wouldn't last long, any more than someone who wrote their own strcpy.
You may have been too hard on the poor kid. Where I was hired fresh out of school they called us "farmers". I guess cuz we knew nothing about the business, and were starting from scratch. Entry-level people need to be mentored and supervised.
It also doesn't help that with all the incentives that were offered for so long when the economy was bottoming-out recently, as with Christmas shopping, everyone now expects incentives and profit-shredding sales, and will hold out for them.
As for lack of demand, who do you think all the people that bought huge trucks and SUV's for the past several years were buying from? Honda?
Amen. Atari BASIC was a high level scripting language for a game design kit (the Atari platform). One that quickly lead to learning assembly language to speed up certain things like vertical sprite movement. When something leads a kid to learn asm and the binary and hexadecimal numbering systems, it is the opposite of a turn-off.
Similarly, when I graduated neither I nor my fellow graduates knew what VB or the Win32 API was if it bit us in the ass. But that's not the point of a CS program. It's not vocational training.
I received what I consider to be a classical computer science education. There was some programming, but not enough to make one a programmer. It was a survey of operating systems and programming language principles, of algorithms and data structures, of software and hardware principles. As such, it occurred to me one day, several years out of college, and it remains generally true for me today, that everything that I've made money on, I've taught myself. But my education was a good foundation, and taught me how I learn, so that I could continue it.
We weren't taught how to set up a mail server or every programming language there ever was and will be, we were taught the ideas behind how things work so that we could figure them out when/if the time comes, depending on our different career choices within this field.
Also read up on distributed systems, web services, and SOA in general, since these are trends that are going to impact your designs more than just a 64bit platform.
I agree. I also tend to think that since dual-core cpu's are going to become mainstream on the desktop, there'll be a sooner migration of things to take (or take more) advantage of multi-threading than the move to 64 bits.
Win95 was a 16/32-bit hybrid/bastardization. It ran both 16 and 32-bit apps natively (and you could thunk calls between them). The NT-based OS's were always 32-bits (or more now), and emulate a 16-bit layer when needed (the Windows on Windows, or WOW subsytem). I believe it was WinME that was the last of those bastardizations.
I had my asm class in college on the MC68000, and remember that it had 16-bit control and data buses (with 32-bit registers!) and a 24-bit address bus. Since 2^16 can only address 64K, and 4GB would have been way overkill in those days, I guess 24 bits was somehow logical. And I too remember plenty of warning for getting "32 bit clean".
Nothing I have written advocates doing research with the brutal ends that the Nazis advanced.
It's not exactly like the Nazis were evil (evil as in actually evil, not evil as in M$) only because of the brutal ends they advanced, and that otherwise the experimentation on human beings part was ethically just fine.
Wow, I've never agreed so much with a comment on/. as this one. When faced with learning a new programming language or library or technology, it's never even occurred to me to think oo, this is hard, I'll just give up and call it "evil". I just do it. It's what I'm paid to do. I don't even think of sitting and crying as an option.
All these babies entered the field when HTML was considered "programming", and they think because Java is all they know, it's the pinnacle of programming and all that they should have to do. But why would I hire them, when I could hire high school kids at minimum wage to just as easily program in it?
As a teen I would booby-trap the Atari 800 computers at Gemco. A continous loop in Atari BASIC that went from 0 to 255 and back, that poked its value into the memory locations to change screen colors and sound pitch, initiaited when someone hit a key. Run it and turn the volume on the TV it was attached to all the way up, and then hide down the next aisle and wait for an unsuspecting victim to come by and witness them:
1) Jump out of their skin at the first touch of the keyboard, and
2) Cause a great scene and have to endure mucho embarassment, and
3) Make them wonder how they could've possibly "broke it".
Muwhahahaha.
An architect describes a new building at a high level. (high level design)
A civil engineer designs the building generating the blueprints (aka code).
Contructions workers implement the design by putting up the building (compile and run).
This is essentially right on. Unfortunately, non-technical managers, I've found, believe that there are only two levels, designers/architects, and implementers. So they have a senior person do the design, and then hand it off to junior code monkeys (at that point in their careers) to implement it, and so while the high-level architecture has good qualities, at the code level there is little-to-no design, so ultimately what you end up with is brittle and non-performant.
You don't throw the high-level design directly to the noobs, you throw it to another senior developer (the "civil engineer"), who can do the code-level design, and hand out smaller-sliced implementation tasks to the beginners and to herself, and she can oversee things at that level and ensure generally loosely-coupled objects, wise algorithm choices, etc.
This is similar to a new software tool I've been working on, that may revolutionize the way software projects are badly managed. This new breed of tool, called "DEATH SPIRAL", automatically generates unrealistic deadlines, schedules in exponentially increasing overtime, and adds random pieces of vague, ill-conceived functionality to effect feature creep and cost overruns. This frees up managers' time to concentrate on fostering the more personal, human aspects of the project -- low morale, burnout, and turnover.
The Costco in my world doesn't take Visa, only personal checks or their partnered Amex card. So either Costco's web site takes Visa but their stores don't, which I would wonder why, or something's amiss here.
Then I'm going to actually write what the button does on the button, so the user has to read the button and understand it to make a choice.
One should always use the appropriate verbs for button labels, instead of lazily trying to shoehorn the simple OK/Cancel model into every situation. (IIRC this was an Apple UI Guideline for the first Macs.) For example, the set "Save and Exit", "Discard and Exit", and "Cancel Exiting", with a very succinct question above them, like "Save before exiting?", is vastly superior in clarity and ease-of-use to a long-winded textual description filled with all kinds of important details, and then Yes/No/Cancel choices where the person has to carefully read everything to understand how to map the buttons to the meanings. People not only have a tendency to automatically click whatever is the affirmative button, they also don't want to read more than a few words before making what they expect (sometimes little do they know!) is a routine decision. That security dialog in the vitalsecurity.org link should be stripped down and have most of it moved behind the already existing More Details button. Something like:
Braces are important to code flow, but they don't require a line by themselves any more than semicolons do.
Semi-colons do when the body of a loop is empty:
/* skip to the next field */ for ( char* p = pRecord; *p != ',' && *p != '\0'; p++ )
;/* no body */
The fact that you're inside a conditional (or loop) is important, and made quite clear by proper indentation.
But you cannot always rely on proper indentation, as you admit you've experienced yourself in your immediately prior post: "But because both were indented as if they were in the loop, and logically belonged there, it was a very subtle and difficult bug to track down." The compiler looks at the braces, and so should you.
you don't have to comment out the ending brace; you can just add an opening one
I don't even have to do that:
//if (condition) {
function(); }
If you really feel that braces should not be on a line by themselves, you should take that to its logical conclusion and advocate:
Indentation can (and where I work, quite often does) get messed up.
How can it possibly get messed up?
I imagine it's due to people having their editors set to different-sized tabs, or differing values of the "use real tabs" vs. "insert spaces for tabs" toggle. Someone can go ahead and "fix" the alignment problem so it looks right to him, but in someone else's editor it'll just look all messed up (and that person might end up "fixing it back").
Theoretically this could be cured if we had a standard (and everyone stuck to it!), as in theory comments would be great if no one ever let them get out of sync with the code, but the point is theory doesn't always pan out, and when a less error-prone, actually fool-proof, method is available (looking at the braces instead of the indentation/looking at the (self-documenting) code instead of the comments), that's much better to use.
We all strive for having comments that are synchronized with the code, and indentation that's not misleading, but ultimately they cannot be relied upon.
OTB style pisses me off because it makes it hard to match up braces for nested control statements (when your fixing somebody else's crap). Especially when the nesting is more then a few screens
Exactly. I've had to wrangle with multi-page behemoths at my first job, and it's a lot easier to find the brace missing his buddy by using the IDE's "jump to matching brace" hotkey while watching the column # display in the status bar. With the style of matching braces not in the same column, you can't use this technique to help you.
> The braces being by themselves on a line gives a visual break
That's because you look at the braces. I look at the indentation to provide visual breaks.
That's not smart. Indentation can (and where I work, quite often does) get messed up. But the braces never lie. (Similar to comments vs. code.)
Also, if your brain tends to interpret that bracing style that way, how often do you come across a stand-alone, unconditional, embedded pair of braces within say a function body?
Slashdot Mirror
Correct. That was when MS decided that instead of an application-centric UI, they preferred a document-centric one. So instead of Program Manager as your shell (which was an MDI application -- Program Groups were the MDI child windows contained within it), where you first picked the application you wanted to use, and then from within that application opened the document you wanted to work on, since the Win95 shell you have a file or document Explorer (an SDI (Single Document Interface, not "star wars"!) app), typically opening by default to a folder called My Documents, where you just directly pick the document you want to work on.
(Windows Explorer is still a little MDI-ish, in the sense that all the hierarchies of all your volumes and shares are all tossed into and confined by one list pane, that you're somehow supposed to be able to easily work with. Too much a pain in the ass trying to copy a file somewhere where the destination is two page-downs in that pane, so I made some shortcuts that instantiate an Explorer rooted on just a certain volume -- if I want to copy something from C: to D:, I want a window for each that I can view mostly side-by-side and drag-n-drop between. I view the "copy and paste files" thing as a kludge to work around Windows Explorer's unfortunate all-in-one-window UI.)
HTML is the universal data format over the HTTP protocol. Text is the universal data format over the SMTP/POP3/IMAP protocols. Why do you think binaries need to be encoded in email? Because it's an ASCII medium.
People who didn't know the Internet existed before the birth of the WWW think that that's all there is, and that email and everything else runs on top of the WWW. It doesn't.
If I thought morse code was the schweetest form of communication, and sent out all my emails in dots and dashes, that wouldn't make them not evil. It would still be an annoying and inappropriate use of the medium.
Grandparent is not flamebait. It's even uglier in Outlook as Plain Text, which you need to set for security purposes. I get "legit spams" from places like MS (employer gets us MSDN subscriptions) and the Uni I take an occasional class at, and I can't make any sense out of them so I delete them 100 out of 100 times.
If I had the time, I would. But in this field it's a struggle to maintain employability. So I have to concentrate on established and popular technologies.
If he had just gotten his CS degree, then you probably didn't hire a programmer. He should certainly know what a hash and what a sort are, although someone who worked for me who wrote their own sort wouldn't last long, any more than someone who wrote their own strcpy.
You may have been too hard on the poor kid. Where I was hired fresh out of school they called us "farmers". I guess cuz we knew nothing about the business, and were starting from scratch. Entry-level people need to be mentored and supervised.
It also doesn't help that with all the incentives that were offered for so long when the economy was bottoming-out recently, as with Christmas shopping, everyone now expects incentives and profit-shredding sales, and will hold out for them.
As for lack of demand, who do you think all the people that bought huge trucks and SUV's for the past several years were buying from? Honda?
Amen. Atari BASIC was a high level scripting language for a game design kit (the Atari platform). One that quickly lead to learning assembly language to speed up certain things like vertical sprite movement. When something leads a kid to learn asm and the binary and hexadecimal numbering systems, it is the opposite of a turn-off.
Similarly, when I graduated neither I nor my fellow graduates knew what VB or the Win32 API was if it bit us in the ass. But that's not the point of a CS program. It's not vocational training.
I received what I consider to be a classical computer science education. There was some programming, but not enough to make one a programmer. It was a survey of operating systems and programming language principles, of algorithms and data structures, of software and hardware principles. As such, it occurred to me one day, several years out of college, and it remains generally true for me today, that everything that I've made money on, I've taught myself. But my education was a good foundation, and taught me how I learn, so that I could continue it.
We weren't taught how to set up a mail server or every programming language there ever was and will be, we were taught the ideas behind how things work so that we could figure them out when/if the time comes, depending on our different career choices within this field.
Also read up on distributed systems, web services, and SOA in general, since these are trends that are going to impact your designs more than just a 64bit platform.
I agree. I also tend to think that since dual-core cpu's are going to become mainstream on the desktop, there'll be a sooner migration of things to take (or take more) advantage of multi-threading than the move to 64 bits.
Win95 was a 16/32-bit hybrid/bastardization. It ran both 16 and 32-bit apps natively (and you could thunk calls between them). The NT-based OS's were always 32-bits (or more now), and emulate a 16-bit layer when needed (the Windows on Windows, or WOW subsytem). I believe it was WinME that was the last of those bastardizations.
I had my asm class in college on the MC68000, and remember that it had 16-bit control and data buses (with 32-bit registers!) and a 24-bit address bus. Since 2^16 can only address 64K, and 4GB would have been way overkill in those days, I guess 24 bits was somehow logical.
And I too remember plenty of warning for getting "32 bit clean".
Talented individuals rely on their marketability. The mediocre masses need unions.
Wow, I didn't know it was that easy! ;-)
Nothing I have written advocates doing research with the brutal ends that the Nazis advanced.
It's not exactly like the Nazis were evil (evil as in actually evil, not evil as in M$) only because of the brutal ends they advanced, and that otherwise the experimentation on human beings part was ethically just fine.
All these babies entered the field when HTML was considered "programming", and they think because Java is all they know, it's the pinnacle of programming and all that they should have to do. But why would I hire them, when I could hire high school kids at minimum wage to just as easily program in it?
As a teen I would booby-trap the Atari 800 computers at Gemco. A continous loop in Atari BASIC that went from 0 to 255 and back, that poked its value into the memory locations to change screen colors and sound pitch, initiaited when someone hit a key. Run it and turn the volume on the TV it was attached to all the way up, and then hide down the next aisle and wait for an unsuspecting victim to come by and witness them:
1) Jump out of their skin at the first touch of the keyboard, and
2) Cause a great scene and have to endure mucho embarassment, and
3) Make them wonder how they could've possibly "broke it".
Muwhahahaha.
This is essentially right on. Unfortunately, non-technical managers, I've found, believe that there are only two levels, designers/architects, and implementers. So they have a senior person do the design, and then hand it off to junior code monkeys (at that point in their careers) to implement it, and so while the high-level architecture has good qualities, at the code level there is little-to-no design, so ultimately what you end up with is brittle and non-performant.
You don't throw the high-level design directly to the noobs, you throw it to another senior developer (the "civil engineer"), who can do the code-level design, and hand out smaller-sliced implementation tasks to the beginners and to herself, and she can oversee things at that level and ensure generally loosely-coupled objects, wise algorithm choices, etc.
This is similar to a new software tool I've been working on, that may revolutionize the way software projects are badly managed. This new breed of tool, called "DEATH SPIRAL", automatically generates unrealistic deadlines, schedules in exponentially increasing overtime, and adds random pieces of vague, ill-conceived functionality to effect feature creep and cost overruns. This frees up managers' time to concentrate on fostering the more personal, human aspects of the project -- low morale, burnout, and turnover.
The Costco in my world doesn't take Visa, only personal checks or their partnered Amex card. So either Costco's web site takes Visa but their stores don't, which I would wonder why, or something's amiss here.
A nitpicky "flaw": "Magic numbers" are bad -- instead return EXIT_SUCCESS, from stdlib.h.
One should always use the appropriate verbs for button labels, instead of lazily trying to shoehorn the simple OK/Cancel model into every situation. (IIRC this was an Apple UI Guideline for the first Macs.) For example, the set "Save and Exit", "Discard and Exit", and "Cancel Exiting", with a very succinct question above them, like "Save before exiting?", is vastly superior in clarity and ease-of-use to a long-winded textual description filled with all kinds of important details, and then Yes/No/Cancel choices where the person has to carefully read everything to understand how to map the buttons to the meanings. People not only have a tendency to automatically click whatever is the affirmative button, they also don't want to read more than a few words before making what they expect (sometimes little do they know!) is a routine decision. That security dialog in the vitalsecurity.org link should be stripped down and have most of it moved behind the already existing More Details button. Something like:
Semi-colons do when the body of a loop is empty:
The fact that you're inside a conditional (or loop) is important, and made quite clear by proper indentation.
But you cannot always rely on proper indentation, as you admit you've experienced yourself in your immediately prior post: "But because both were indented as if they were in the loop, and logically belonged there, it was a very subtle and difficult bug to track down." The compiler looks at the braces, and so should you.
you don't have to comment out the ending brace; you can just add an opening one
I don't even have to do that:
If you really feel that braces should not be on a line by themselves, you should take that to its logical conclusion and advocate:How can it possibly get messed up?
I imagine it's due to people having their editors set to different-sized tabs, or differing values of the "use real tabs" vs. "insert spaces for tabs" toggle. Someone can go ahead and "fix" the alignment problem so it looks right to him, but in someone else's editor it'll just look all messed up (and that person might end up "fixing it back").
Theoretically this could be cured if we had a standard (and everyone stuck to it!), as in theory comments would be great if no one ever let them get out of sync with the code, but the point is theory doesn't always pan out, and when a less error-prone, actually fool-proof, method is available (looking at the braces instead of the indentation/looking at the (self-documenting) code instead of the comments), that's much better to use.
We all strive for having comments that are synchronized with the code, and indentation that's not misleading, but ultimately they cannot be relied upon.
Exactly. I've had to wrangle with multi-page behemoths at my first job, and it's a lot easier to find the brace missing his buddy by using the IDE's "jump to matching brace" hotkey while watching the column # display in the status bar. With the style of matching braces not in the same column, you can't use this technique to help you.
That's because you look at the braces. I look at the indentation to provide visual breaks.
That's not smart. Indentation can (and where I work, quite often does) get messed up. But the braces never lie. (Similar to comments vs. code.)
Also, if your brain tends to interpret that bracing style that way, how often do you come across a stand-alone, unconditional, embedded pair of braces within say a function body?
Your thesis assumes that the programmer who writes unclear code, but who doesn't recognize it as such, will somehow be able to write clear comments.