and yet we had a melanoma incidence rate of 1 in 150,000 in the 1930's and it's around 1 in 75 now. Yeah, it's all part of natural world and nothing to do with the rate of industrialization.
Your design guy is basically in a nice cushy job where he produces shit and can totally avoid taking any responsibility for the final product. Mostly because software design cannot be validated by an sensible means and the end result is that people tasked with doing nothing else but design software end up generating bullshit and humping the dog while coders are tasked with making it work and when it doesn't the pressure goes downwards not up. I'm also willing to bet that the design guy is good friends with some executive at the company. Quit your job because companies are typically very resistant to culture change. Where you are you'll always be overworked and under appreciated while they "high level design" fella will keep getting the praise and the bonuses.
Communication is important but it has nothing to do with software design.
The majority of software project failures I've seen in my career have been due to... software design. Specifically, waterfall big-design-upfront type of projects tended to collapse and crumble under the smallest wind of change coming from customers. The inherent problem with designing software is that it's very difficult to predict the extension points and it's clearly impossible to design software that is extendible in all aspects. Design adds complexity which, when applied to wrong places, adds nothing to the end value. Finally, big-design-upfront teams often spend an inordiante time designing the minute details and even when (often) they get some aspects of the design wrong they end up trying to maintain the structure feeling that since they had already invested so much time and energy in the design, it would be wrong to scrap so much hard work. And so they plough ahead with a broken design and end up spending more time coding the needless complexity, debugging the needless complexity and working around the flaws of the desing to just get the thing working.
Re:The Problem With XML
on
Effective XML
·
· Score: 1
Heh. Bad example as SQL severely limits what you can do in relational algebra but I got your point:-)
However your pre-cooked parser comes with a severe limitation... complete lack of flexibility which implies verbosity. Grammar files are immensely more flexible and just as precise as XML schemas. But it's true that for many people they seem to look harder to develop.
Re:Disgruntled with XML....
on
Effective XML
·
· Score: 1
OK. I wasn't specific enough. When I'm talking about config files I'm mostly thinking "Java config files" or even more specifically "J2EE config files". I find that way too much stuff ends up in XML config files that should actually be implemented in the Java code itself. In some cases, perhaps scripted with Groovy or Beanshell. XML is not the vehicle for application scripting alas that's what most j2ee "config" files have become.
Antlr (actually that's my personal favourite) is harder to learn than JDOM but not impossible. In my opinion it's just as easy to use. For very simple grammars it's even simpler than defining your own XML schema.
As far as parsing APIs go, I really like antlr and its ability to build ASTs with a mix of its own adn client provided classes. I haven't worked with castor but if it's anything like JAXB I don't like it... and working with plain DOM/DOM4j or JDOM is a royal Pain In the Arse.
Re:Disgruntled with XML....
on
Effective XML
·
· Score: 1
I understand you're talking about tools such as JAXB. Care to elaborate about the aforementioned design flaws? I've not been too involved with advanced XML processing (though I've seen JAXB used and didn't like what I saw but mostly due to my sense of "aesthetics").
What are the big gotchas of those XML binding APIs as you see them?
Re:Disgruntled with XML....
on
Effective XML
·
· Score: 1
I agree with the i18n bit, but it's only handled in XML better by the virtue of XML being newer than most parser generating tools out there.
As far as XML development being "easier"... I find that questionable (but it may be my personal view). If the problem domain is trivial then it might be the case that your XML schema happens to be simpler than your BNF grammar. In most non-trivial cases I find it's about even. As far as verbosity goes, 99% of the time your custom grammar will be a lot more space efficient than XML unless you define something very Cobolesque;-)
I also have an issue with most XML parsers where I cannot work with my own classes but have to use the silly API provided objects like TextNode, ThisNode, ThatNode (At least in Java DOM,JDOM etc...). What I usually end up doing is having a parallel hierarchy of my own classes which contain the functionality I actually need. Something like ANTLR allows me to simply provide my own classes for some or all of the AST nodes. Very handy.
Re:The Problem With XML
on
Effective XML
·
· Score: 1
And all that wonderful magic can't be accomplished with something like ANTLR, because...?
Not always possible. You can't do any IO from EJBs for example.
Disgruntled with XML....
on
Effective XML
·
· Score: 1
I've seen XML used for quite a while in a number of completely inappropriate situations such as configuration data, RPC implementations, scripting etc.
Yet, every time I see XML (mis)applied in those cases I keep asking the fundamental question. What does it allow me to do that a decent Lexer and Parser does not? You could be sending grammar files just as easily and without the ridiculous verbosity of XML. Most parsers can work with either text or binary and BNF has been a golden standard for decades. XML reinvents the wheel for the umpteenth time and without a single good reason to justify its existance.
An ex-colleague of mine had the gall to ask his PM in a team meeting for an extra couple of days to write a SELECT query just because the query was returning not just a handful of records, but millions!
Well given that the data had to be stored in memory it's not an extravagant requirement if the app wasn not built ot have support for scrolling etc. In fact it would be more than reasonable to ask for a couple of weeks to handle very large result sets if the app wasn't built to handle them.
Am I the only one who was surprised to see a Darren Aronofski dedicated section on slashdot? Not that I'd disapprove... Darren's a supertalented director and I recommend PI to any slashdot geek.
It's true but it's just a nitpick in my argument. What I said is make sure you're using the most optimal algorithms for your circumstances. Of course, in some cases tree lookups will be faster. Other things to consider are whether inserts or reads will be more frequent etc. The point is, always pick what makes the most sense for your dataset. Most developers tend to just pick whatever came with the standard library or even worse always use DA ARRAY that came built into the language.
First: Avoid doing what you don't have to do. Sounds obvious but I rarely see code that does the absolute minimum it needs to. Most of the code I've seen to date seems to precalculate too much stuff, read too much data from external storage, redraw too much stuff on screen etc...
Second: Do it later. There are thousands of situations where you can postpone the actual computations. Imagine writing a Matrix class with the invert() method. You can actually postpone calculating the inverse of the matrix until there is a call to access on of the fields in the matrix. Also you can calculate only the field being accessed. Or at some sensible threshold you may assume that the user code will read the entire inverted matrix and you can just calculate the remaining inverted fields... the options are endless.
Most string class implementations already make good use of this rule by only copying their buffers only when the "copied" buffer changes.
Third: Apply minimum algorithmic complexity. If you can use a hashmap instead of a treemap use the hash version it's O(1) vs Olog(n). Use quicksort for just about any kind of sorting you need to do.
Fourth: Cache your data. Download or buy a good caching class or use some facilities your language provides (eg. Java SoftReference class) for basic caching. There are some enormous performance gains that can be realized with smart caching strategies.
Fifth: Optimize using your language constructs. User the register keyword, use language idioms that you know compile into faster code etc... Scratch this rule! If you're applying rules one to four you can forget about this one and still have fast AND readable code.
Never argued that American crap is any healthier. The two can probably compete for the the title of the world's most cancerous diet.
One exception to that would be traditional Scottish wild game dishes... but you can't buy them anywhere except for a few posh restaurants in Edinburgh, so it doesn't really count.
I lived in the UK for quite a while. The food in the UK is something that you can get used to. It's not great but it's edible. However, I really wouldn't want to know what kind of toll it it takes on your health. Just to follow your own example: chips and faggots. Real tumour food.
This is very good news indeed as melanoma is a very difficult cancer to get rid of.
Unfortunately a fellow geek has a case. Check out his weblog here.
Basically make sure you get all suspicious looking moles checked by your doctor before it's too late. Melanoma is only life threatening when it spreads beyond the initial site.
Somehow I think that the amount of "normal" particulate waste that all other types of plants tend to emit is much more harmful than the radioactive waste would ever be. Funny enough there is plenty of flora and fauna in the Charnobyl reactor area. I'm sure that some of its fauna has a higher cancer incidence rate but the stories about six foot chickens roaming around aren't true. Honest.
Read Joel on Software on sowftware pricing. (http://www.joelonsoftware.com/articles/CamelsandR ubberDuckies.html)
I found it a very informative piece explaining general rules of successful pricing strategies.
Not exactly what you're looking for but probably the closest to a sensible answer that you can hope for.
One of my uncles is definitely on that list. Now, I know for a fact that it is him because of his pretty uncommon first name and his very uncommon last name. There are very, very few Poles who bear his last name...
Anyway, my point is, in the '80s he was actually on the other side of the fence, working for the opposition. In 1981 when the communist government introduced the martial law and outlawed Solidarity which was quickly followed by massive detentions he was one of those detained. I remember it well as my mother came home crying that her brother was snatched by WRON (the martial law enforcement agency formed after instituting the martial law) in the middle of the night and detained god knows where. He was released a few weeks later after being forced to sign some shit declaring that he would not work to subvert the communist government ever again. This is most likely why he's on the Wildstein list.
Of course, right after his release it was business as usual for him: printing Solidarity leaflets, distributing Solidarity news magazines and smuggling letters from the loved ones out of the detention centers.
I'm quite angry this list has surfaced as it tarnishes my uncle's name who actually fought the regime and risked his safety numerous times in defending the cause (and no he was not an informant or a double agent).
I just hope this list isn't taken too seriously and does not lead to a witch hunt of sorts because a lot of innocent people will be harmed (though my uncle is "safe" in this respect: he died of a stroke about ten years ago).
Thank you. It is such a forgotten issue in the whole discussion about holocaust. While it's true that most of the Poles who died from German and Soviet hands weren't actually gassed doesn't mean they had it any better than the Jews. Most were actually starved to death while in forced labour. Hardly a better alternative to a gas chamber.
There is no international medial voice equivalent to Steven Spielberg to highlight the horrors of holocaust. Conversely, the recent holocaust movie by Polanski ("The Pianist") skewed the picture of life outside the Warsaw ghetto. Watching that movie one may infer that life in nazi occupied Poland continued pretty much as before the war. That is blatently untrue. Listening to the accounts of old Warsovians, life in Warsaw was incredibly tough (food shortages, no heating fuel) coupled with constant persecution by Gestapo and of course snatching people from streets to send them to forced labour camps.
Slashdot Mirror
and yet we had a melanoma incidence rate of 1 in 150,000 in the 1930's and it's around 1 in 75 now. Yeah, it's all part of natural world and nothing to do with the rate of industrialization.
Your design guy is basically in a nice cushy job where he produces shit and can totally avoid taking any responsibility for the final product. Mostly because software design cannot be validated by an sensible means and the end result is that people tasked with doing nothing else but design software end up generating bullshit and humping the dog while coders are tasked with making it work and when it doesn't the pressure goes downwards not up. I'm also willing to bet that the design guy is good friends with some executive at the company. Quit your job because companies are typically very resistant to culture change. Where you are you'll always be overworked and under appreciated while they "high level design" fella will keep getting the praise and the bonuses.
The majority of software project failures I've seen in my career have been due to... software design. Specifically, waterfall big-design-upfront type of projects tended to collapse and crumble under the smallest wind of change coming from customers. The inherent problem with designing software is that it's very difficult to predict the extension points and it's clearly impossible to design software that is extendible in all aspects. Design adds complexity which, when applied to wrong places, adds nothing to the end value. Finally, big-design-upfront teams often spend an inordiante time designing the minute details and even when (often) they get some aspects of the design wrong they end up trying to maintain the structure feeling that since they had already invested so much time and energy in the design, it would be wrong to scrap so much hard work. And so they plough ahead with a broken design and end up spending more time coding the needless complexity, debugging the needless complexity and working around the flaws of the desing to just get the thing working.
However your pre-cooked parser comes with a severe limitation... complete lack of flexibility which implies verbosity. Grammar files are immensely more flexible and just as precise as XML schemas. But it's true that for many people they seem to look harder to develop.
Antlr (actually that's my personal favourite) is harder to learn than JDOM but not impossible. In my opinion it's just as easy to use. For very simple grammars it's even simpler than defining your own XML schema.
As far as parsing APIs go, I really like antlr and its ability to build ASTs with a mix of its own adn client provided classes. I haven't worked with castor but if it's anything like JAXB I don't like it... and working with plain DOM/DOM4j or JDOM is a royal Pain In the Arse.
What are the big gotchas of those XML binding APIs as you see them?
As far as XML development being "easier"... I find that questionable (but it may be my personal view). If the problem domain is trivial then it might be the case that your XML schema happens to be simpler than your BNF grammar. In most non-trivial cases I find it's about even. As far as verbosity goes, 99% of the time your custom grammar will be a lot more space efficient than XML unless you define something very Cobolesque ;-)
I also have an issue with most XML parsers where I cannot work with my own classes but have to use the silly API provided objects like TextNode, ThisNode, ThatNode (At least in Java DOM,JDOM etc...). What I usually end up doing is having a parallel hierarchy of my own classes which contain the functionality I actually need. Something like ANTLR allows me to simply provide my own classes for some or all of the AST nodes. Very handy.
And all that wonderful magic can't be accomplished with something like ANTLR, because...?
Not always possible. You can't do any IO from EJBs for example.
Yet, every time I see XML (mis)applied in those cases I keep asking the fundamental question. What does it allow me to do that a decent Lexer and Parser does not? You could be sending grammar files just as easily and without the ridiculous verbosity of XML. Most parsers can work with either text or binary and BNF has been a golden standard for decades. XML reinvents the wheel for the umpteenth time and without a single good reason to justify its existance.
Am I the only one who was surprised to see a Darren Aronofski dedicated section on slashdot? Not that I'd disapprove... Darren's a supertalented director and I recommend PI to any slashdot geek.
It's true but it's just a nitpick in my argument. What I said is make sure you're using the most optimal algorithms for your circumstances. Of course, in some cases tree lookups will be faster. Other things to consider are whether inserts or reads will be more frequent etc. The point is, always pick what makes the most sense for your dataset. Most developers tend to just pick whatever came with the standard library or even worse always use DA ARRAY that came built into the language.
Second: Do it later. There are thousands of situations where you can postpone the actual computations. Imagine writing a Matrix class with the invert() method. You can actually postpone calculating the inverse of the matrix until there is a call to access on of the fields in the matrix. Also you can calculate only the field being accessed. Or at some sensible threshold you may assume that the user code will read the entire inverted matrix and you can just calculate the remaining inverted fields... the options are endless.
Most string class implementations already make good use of this rule by only copying their buffers only when the "copied" buffer changes.
Third: Apply minimum algorithmic complexity. If you can use a hashmap instead of a treemap use the hash version it's O(1) vs Olog(n). Use quicksort for just about any kind of sorting you need to do.
Fourth: Cache your data. Download or buy a good caching class or use some facilities your language provides (eg. Java SoftReference class) for basic caching. There are some enormous performance gains that can be realized with smart caching strategies.
Fifth: Optimize using your language constructs. User the register keyword, use language idioms that you know compile into faster code etc... Scratch this rule! If you're applying rules one to four you can forget about this one and still have fast AND readable code.
No doubt you have this one in mind.
One exception to that would be traditional Scottish wild game dishes... but you can't buy them anywhere except for a few posh restaurants in Edinburgh, so it doesn't really count.
I lived in the UK for quite a while. The food in the UK is something that you can get used to. It's not great but it's edible. However, I really wouldn't want to know what kind of toll it it takes on your health. Just to follow your own example: chips and faggots. Real tumour food.
-"Mary what's the name of that German guy who keeps hiding my reading glasses?"
-"Alzheimer grampa, Alzheimer!"
- "It's Alzheimer grampa, Alzheimer!"
Given the life expectancy with either HIV or metastasized melanoma I'd take HIV any day of the week.
Unfortunately a fellow geek has a case. Check out his weblog here.
Basically make sure you get all suspicious looking moles checked by your doctor before it's too late. Melanoma is only life threatening when it spreads beyond the initial site.
Somehow I think that the amount of "normal" particulate waste that all other types of plants tend to emit is much more harmful than the radioactive waste would ever be. Funny enough there is plenty of flora and fauna in the Charnobyl reactor area. I'm sure that some of its fauna has a higher cancer incidence rate but the stories about six foot chickens roaming around aren't true. Honest.
So either accept that or the answer is $42/hr
Anyway, my point is, in the '80s he was actually on the other side of the fence, working for the opposition. In 1981 when the communist government introduced the martial law and outlawed Solidarity which was quickly followed by massive detentions he was one of those detained. I remember it well as my mother came home crying that her brother was snatched by WRON (the martial law enforcement agency formed after instituting the martial law) in the middle of the night and detained god knows where. He was released a few weeks later after being forced to sign some shit declaring that he would not work to subvert the communist government ever again. This is most likely why he's on the Wildstein list.
Of course, right after his release it was business as usual for him: printing Solidarity leaflets, distributing Solidarity news magazines and smuggling letters from the loved ones out of the detention centers.
I'm quite angry this list has surfaced as it tarnishes my uncle's name who actually fought the regime and risked his safety numerous times in defending the cause (and no he was not an informant or a double agent).
I just hope this list isn't taken too seriously and does not lead to a witch hunt of sorts because a lot of innocent people will be harmed (though my uncle is "safe" in this respect: he died of a stroke about ten years ago).
There is no international medial voice equivalent to Steven Spielberg to highlight the horrors of holocaust. Conversely, the recent holocaust movie by Polanski ("The Pianist") skewed the picture of life outside the Warsaw ghetto. Watching that movie one may infer that life in nazi occupied Poland continued pretty much as before the war. That is blatently untrue. Listening to the accounts of old Warsovians, life in Warsaw was incredibly tough (food shortages, no heating fuel) coupled with constant persecution by Gestapo and of course snatching people from streets to send them to forced labour camps.
Poland needs its own Steven Spielberg.