Nice troll/automatic assuming of a borken function, but most people use IDE's these days, and they're perfectly capable of pointing out where a function is called, among other things. And in OOP, typically functions reside in classes or interfaces, that by their names provide additional context above and beyond what you can already readily discern from the name of the function and its parameters and which are in or out parms. What other context do you somehow require?
You sound as if you work in the sysadmin side of the house. This is probably totally appropriate for your tasks, where you may typically need modest-sized scripts to piece together some things to, say, process a log file.
But note that there's a whole other world out there, and be careful not to fall into the PHBism of assuming that anything you don't know about must be simple. On the software engineering side, for large-scale projects, the choice of languages is not at all inconsequential, and can affect maintainability, quality, and performance. We're not handed a pseudocode design that spells everything out, and we only have to translate it into the actual language syntax. A requirement may say such-and-such shall appear alphabetically. You know what the program "needs to do", but there are choices of sorting algorithms, and data structures/containers, that have different qualities, that should be evaluated and chosen deliberately for the task at hand.
Pseudocode is fine, but it's not critical to your point. You can do all that you describe in an actual language, as at this level you'll not be using any language-specific features anyway (otherwise by definition you couldn't use pseudocode either!).
For example, I work with many languages but am most fluent in C++, as are my coworkers, so for an object-oriented design, for example, I'll just go ahead and write up some mostly-empty class declarations, with comments inside for guts that aren't appropriate to spell out at this level, as it's as good a language as any in this case. No need to make up a pseudo one.
It only appears that the world is saying fuck you now because before, in your really young and naive days, it seemed like it was welcoming you with the promise and hope of a good life. There was no such promise. As it is throughout the rest of the animal kingdom, it's survival of the fittest. Buck up and find a job and do the best you can. You're no different than myself or anyone else in this sense. The world isn't saying fuck you, the world just doesn't care. Only people care. Which brings me to #2:
Your folks and siblings and cousins and friends etc. will obviously care if you die tomorrow. Even if you don't land that way cool job the first time, there's oh so much more to life than work. You'll probably get married, and give your spouse, and maybe children, if that's your thing, a lifetime of happiness. Don't sell yourself short just because some clueless PHB's and HR droids want to pretend you're not worth much. Find someone who you can prove it to that you're valuable.
The.Net framework and it's languages/technologies (e.g. ASP.NET) are 1.0 or 1.1 (2.0's in beta). How dominant was the Java language/platform in its 1.0/1.1 days. I was there, doing Java then at my first company. It was not unheard-of, but not dominant..Net and C# (I don't think VB.Net will ever be big, nor anywhere near as big as VB was) won't really take off until its 2.0 technologies and Longhorn and all the Avalon/Indigo stuff. That is, when there is much more advantage, with the newer GUI and Web Services tools, to adopt it. Right now I view.Net as mostly an MS-only Java alternative, which is not exactly compelling to me, as a Windows C++ developer. I don't need another wrapper around the Win32 API. But I expect MS to leap ahead of the competition in a year or two, and only then will we really know how things are going to shake out.
Of course, if you're an employer, you can list it as a high paying job with a lot of requirements. The more requirements, the less likely you will find someone to meet all of them...and that means you can justify lower pay.
Or you can add to all the artificial jobs for which unsurprisingly no USian qualifies, thus the software industry as a whole can retain "evidence" for continued desperate need of H1-B's, that they can pay less.
Re:The Problem With XML
on
Effective XML
·
· Score: 1
This is overstated. If, say, you don't know the domain, then the items and their data are going to be foreign to you whether it's in XML or not. But otherwise, the schema designer would have to intentionally and knowingly make the data less decipherable by doing something unorthodox, like storing the numeric value of the year minus 1900 between year tags, instead of the more obvious actual year number itself. And nesting could only fail to convey hierarchical information if the tags were made cryptic, such as with mutilated abbreviations.
Re:The Problem With XML
on
Effective XML
·
· Score: 1
I.e. somebody might come along and add a valid set of tags to your data and your app breaks.
This is not true. With the DOM parser your code wouldn't even drop into child nodes it didn't know about, and with SAX, you're also only processing those tags thrown at you that you know about/are interested in.
There's no need for you and your partner to suffer in silence due to the stigma surrounding premature optimization, and other forms of programming dysfunction. Treatment is just a phone call away!;-)
When I first glanced at that, I got tripped up for a split sec on "if (!instance)....". I thought, hmm, I wonder why that class is overriding operator bool. I find the following clearer, in increasing clarity:
if ( instance != NULL )...
if ( ! pInstance )...// (I subscribe to a "sane set" of Hungarian notation)
if ( pInstance != NULL )...
That bothers me as well. But then I'm guilty of practicing something similar, for ranges, as I think the following, e.g., makes it as clear as it can possibly be that a variable must fall within a certain range:
I believe I also would not hire you, as you are now. Your overblown rant on mixed case could indicate an inflexibility, and a tendency towards imagining distinctions without differences. There are no "gobs of errors" in either of two things that are merely stylistic differences. If you work at a place that uses CamelCase, you use that, whether you personally think it's the source of all evil in the world or not.
The belief that the notion of self-documenting code is BS is also troubling. And troublingly defeatist. If you think self-documenting code is unattainable, then you're not going to even try for it. With that belief it would be illogical to strive for descriptive names, may as well be terse and save some typing. When the spoken language is English, at least, and I suspect with most human languages, they actually could not be worse as a medium in conveying rigorously and accurately what code does. Human languages are terribly imprecise, with multiple meanings/nuances for words, plus non-language cues such as facial expression often critical for interpreting the meaning. Why do you think the various diagramming "languages", such as the ones in the UML, were invented if human language was so superior for describing code-related concepts?
On your commenting comment: If you have to comment a variable, it means that you've failed to think of a sufficiently descriptive name for it. If you have to comment a function (at least on what it does), you've violated function cohesion. I agree that code should be commented well, but define it much differently. They should be (not need to be more than) infrequent. I comment my overall approach. I'll comment a loop that has a fair amount of content, to give a one-line description of what it's for (not what it does -- that's what the code is for). I'll comment major blocks in a function so that it can be quickly absorbed at a high level. I'll comment things like where the API documentation is in error, and you really have to pass foo instead of bar, at least in that version of the API, to get functionality baz, so someone else doesn't come along and wonder who the dodo was, or worse, change it.
On commenting each and every non- standard library function call, why would I want to waste time doing something twice? Why would I name a function "con", and then have to put a comment above it, and everywhere it's called, saying "see if connected", when I could just name the function "isConnected"?
Way over-rated. Parent said Canada "has no clear plan". Announcing "okay, everyone, begin to pollute less now", is not a plan. There's no reason to believe that this could result in reaching any particular concrete goal, except by coincidence. Hoping you get lucky is not a plan.
Don't confuse successful with having a finite popular lifetime. Someone ought to be able to correct me if I'm wrong, but I'd heard that at one time Pascal was the major development language at Microsoft, in its time. And I think Fortran was extremely popular in its day.
Also, I consider Java to be an academic/learning language (and I think most universities today would agree), designed to demonstrate (and steer one into) OOP and its benefits, without the potential frustration and turn-off of getting hung up on details like pointers and freeing (some) resources, or from crashing the machine. And yet it's certainly very successful. But it too may dwindle in popularity at some point, and be superceded by The Next Big Thing.
If.Net enables developing applications that can be (Windows) native or Web-based (with just a recompile with a different switch, or something) which I've gathered is one of the motives (correct me if I'm wrong -- IANA.NetExpert), then there'll still be plenty of development on Windows.
Also note that if web services/SOA is ever fully realized, then your apps are a combination of web services with a thin-client front-end tying them together, and then what languages/platforms the individual services are implemented in becomes much less relevant.
With enough nerd common sense, plus a little willpower, you don't even need the anti-virus crap. I haven't had a virus since my Mac System 6 and 7 days in college, when Apple thought it was a good idea to auto-execute code on every floppy disk that was inserted.
Some of us detest the hiding of less frequently used menu items, and turn that shit off.
My Computer isn't in the Start Menu on my XP Pro (SP1) system here at work. Besides, what would I need that for?
Cmd line tab completion can be turned on for W2K with a registry entry -- have that at home.
A couple of things I remembered having to do to XP so that I wouldn't find it annoying as hell:
Turn off the cutesy mommy login page and get back the NT-style one.
Turn off some simplified security mode to prevent Grandma from screwing things up, so that I could see what the hell perms on which things were set for which users and to what.
The point is, these pushbacks have given open source the chance to make major innovation,...
How often has open source innovated? Seems like it's mostly cloning. Then again, that's probably exactly one of the major goals, to provide an OSS alternative to everything, I guess.
My gut feeling is that Longhorn will knock the socks off whatever is out there at the time,...
How on earth could it do that? If their fancy file system is still a pipe dream, Avalon/XAML is like XUL (and like the pre XML Visual C++.rc file -- nothing really new here), Indigo may be a nice web services framework, but they already exist, and will web services even really ever take off?.Net is a JVM/sandbox -- already been done. The blue "aqua" looking GUI has already been done. Maybe the 3D parts of the GUI will knock the socks off some PHB's.
Some would say the pendulum is swinging towards Open Source on the desktop at the moment, but I worry that Longhorn could stop that in its tracks.
Why? I don't worry that the popularity of rocky road ice cream will outpace that of butter pecan. Not exactly timeless matters of earth-shattering importance here. I eat and use whichever I feel like when it suits me.
Service-Oriented Architecture (SOA). If GUI apps were broken down into discrete services tied together, the services could be recombined or chained together in different ways for other "applications".
Basically we need to give people reading interpratation tests like they had on the SAT and GRE.
This was my thinking exactly. Some things like:
My name is John. Mary's mom is my mother-in-law. That makes Mary my ______.
You buy a candy bar for 85 cents. You give the cashier a dollar, and you'll typically get back a ______ and a nickel.
A previous poster also hinted on this, but presented it as a multiple-guess style test. I think the important thing, is for the answer to appear nowhere in the question. That's what makes traditional CAPTCHA's vulnerable.
In my experience doing IT projects for the govt., they simply can't be bothered to tell you what they want. They rely on you to come up with the requirements, and then after you build it they tell you it's all wrong and then finally start to give you some actual hints on what they were expecting. The problem is, there's no penalty to them/their job/their career for wasting tons of taxpayer money like this, so they just don't care.
Slashdot Mirror
Nice troll/automatic assuming of a borken function, but most people use IDE's these days, and they're perfectly capable of pointing out where a function is called, among other things. And in OOP, typically functions reside in classes or interfaces, that by their names provide additional context above and beyond what you can already readily discern from the name of the function and its parameters and which are in or out parms. What other context do you somehow require?
But note that there's a whole other world out there, and be careful not to fall into the PHBism of assuming that anything you don't know about must be simple. On the software engineering side, for large-scale projects, the choice of languages is not at all inconsequential, and can affect maintainability, quality, and performance. We're not handed a pseudocode design that spells everything out, and we only have to translate it into the actual language syntax. A requirement may say such-and-such shall appear alphabetically. You know what the program "needs to do", but there are choices of sorting algorithms, and data structures/containers, that have different qualities, that should be evaluated and chosen deliberately for the task at hand.
For example, I work with many languages but am most fluent in C++, as are my coworkers, so for an object-oriented design, for example, I'll just go ahead and write up some mostly-empty class declarations, with comments inside for guts that aren't appropriate to spell out at this level, as it's as good a language as any in this case. No need to make up a pseudo one.
The .Net framework and it's languages/technologies (e.g. ASP.NET) are 1.0 or 1.1 (2.0's in beta). How dominant was the Java language/platform in its 1.0/1.1 days. I was there, doing Java then at my first company. It was not unheard-of, but not dominant. .Net and C# (I don't think VB.Net will ever be big, nor anywhere near as big as VB was) won't really take off until its 2.0 technologies and Longhorn and all the Avalon/Indigo stuff. That is, when there is much more advantage, with the newer GUI and Web Services tools, to adopt it. Right now I view .Net as mostly an MS-only Java alternative, which is not exactly compelling to me, as a Windows C++ developer. I don't need another wrapper around the Win32 API. But I expect MS to leap ahead of the competition in a year or two, and only then will we really know how things are going to shake out.
Or you can add to all the artificial jobs for which unsurprisingly no USian qualifies, thus the software industry as a whole can retain "evidence" for continued desperate need of H1-B's, that they can pay less.
This is overstated. If, say, you don't know the domain, then the items and their data are going to be foreign to you whether it's in XML or not. But otherwise, the schema designer would have to intentionally and knowingly make the data less decipherable by doing something unorthodox, like storing the numeric value of the year minus 1900 between year tags, instead of the more obvious actual year number itself. And nesting could only fail to convey hierarchical information if the tags were made cryptic, such as with mutilated abbreviations.
This is not true. With the DOM parser your code wouldn't even drop into child nodes it didn't know about, and with SAX, you're also only processing those tags thrown at you that you know about/are interested in.
(Here's some extra chars to work around Slashdot's lame "lameness filter".)
There's no need for you and your partner to suffer in silence due to the stigma surrounding premature optimization, and other forms of programming dysfunction. Treatment is just a phone call away! ;-)
if ( instance != NULL ) ... ... // (I subscribe to a "sane set" of Hungarian notation) ...
if ( ! pInstance )
if ( pInstance != NULL )
The belief that the notion of self-documenting code is BS is also troubling. And troublingly defeatist. If you think self-documenting code is unattainable, then you're not going to even try for it. With that belief it would be illogical to strive for descriptive names, may as well be terse and save some typing. When the spoken language is English, at least, and I suspect with most human languages, they actually could not be worse as a medium in conveying rigorously and accurately what code does. Human languages are terribly imprecise, with multiple meanings/nuances for words, plus non-language cues such as facial expression often critical for interpreting the meaning. Why do you think the various diagramming "languages", such as the ones in the UML, were invented if human language was so superior for describing code-related concepts?
On your commenting comment: If you have to comment a variable, it means that you've failed to think of a sufficiently descriptive name for it. If you have to comment a function (at least on what it does), you've violated function cohesion. I agree that code should be commented well, but define it much differently. They should be (not need to be more than) infrequent. I comment my overall approach. I'll comment a loop that has a fair amount of content, to give a one-line description of what it's for (not what it does -- that's what the code is for). I'll comment major blocks in a function so that it can be quickly absorbed at a high level. I'll comment things like where the API documentation is in error, and you really have to pass foo instead of bar, at least in that version of the API, to get functionality baz, so someone else doesn't come along and wonder who the dodo was, or worse, change it.
On commenting each and every non- standard library function call, why would I want to waste time doing something twice? Why would I name a function "con", and then have to put a comment above it, and everywhere it's called, saying "see if connected", when I could just name the function "isConnected"?
Way over-rated. Parent said Canada "has no clear plan". Announcing "okay, everyone, begin to pollute less now", is not a plan. There's no reason to believe that this could result in reaching any particular concrete goal, except by coincidence. Hoping you get lucky is not a plan.
Also, I consider Java to be an academic/learning language (and I think most universities today would agree), designed to demonstrate (and steer one into) OOP and its benefits, without the potential frustration and turn-off of getting hung up on details like pointers and freeing (some) resources, or from crashing the machine. And yet it's certainly very successful. But it too may dwindle in popularity at some point, and be superceded by The Next Big Thing.
What are you talking about, they offer "great new features" the first Tuesday of every month! ;-)
Also note that if web services/SOA is ever fully realized, then your apps are a combination of web services with a thin-client front-end tying them together, and then what languages/platforms the individual services are implemented in becomes much less relevant.
With enough nerd common sense, plus a little willpower, you don't even need the anti-virus crap. I haven't had a virus since my Mac System 6 and 7 days in college, when Apple thought it was a good idea to auto-execute code on every floppy disk that was inserted.
- Some of us detest the hiding of less frequently used menu items, and turn that shit off.
- My Computer isn't in the Start Menu on my XP Pro (SP1) system here at work. Besides, what would I need that for?
- Cmd line tab completion can be turned on for W2K with a registry entry -- have that at home.
A couple of things I remembered having to do to XP so that I wouldn't find it annoying as hell:How often has open source innovated? Seems like it's mostly cloning. Then again, that's probably exactly one of the major goals, to provide an OSS alternative to everything, I guess.
My gut feeling is that Longhorn will knock the socks off whatever is out there at the time, ...
How on earth could it do that? If their fancy file system is still a pipe dream, Avalon/XAML is like XUL (and like the pre XML Visual C++ .rc file -- nothing really new here), Indigo may be a nice web services framework, but they already exist, and will web services even really ever take off? .Net is a JVM/sandbox -- already been done. The blue "aqua" looking GUI has already been done. Maybe the 3D parts of the GUI will knock the socks off some PHB's.
Some would say the pendulum is swinging towards Open Source on the desktop at the moment, but I worry that Longhorn could stop that in its tracks.
Why? I don't worry that the popularity of rocky road ice cream will outpace that of butter pecan. Not exactly timeless matters of earth-shattering importance here. I eat and use whichever I feel like when it suits me.
Or rather, just STFU and simply wait 10 years, learn from whatever mistakes in .Net's design surface, and then introduce Java#!
Service-Oriented Architecture (SOA). If GUI apps were broken down into discrete services tied together, the services could be recombined or chained together in different ways for other "applications".
This was my thinking exactly. Some things like:
- My name is John. Mary's mom is my mother-in-law. That makes Mary my ______.
- You buy a candy bar for 85 cents. You give the cashier a dollar, and you'll typically get back a ______ and a nickel.
A previous poster also hinted on this, but presented it as a multiple-guess style test. I think the important thing, is for the answer to appear nowhere in the question. That's what makes traditional CAPTCHA's vulnerable.In my experience doing IT projects for the govt., they simply can't be bothered to tell you what they want. They rely on you to come up with the requirements, and then after you build it they tell you it's all wrong and then finally start to give you some actual hints on what they were expecting. The problem is, there's no penalty to them/their job/their career for wasting tons of taxpayer money like this, so they just don't care.