You seem to have fallen prey to the alpha geek mentality. The implication of your post amounts to:
"It works for me. If it doesn't work for you, you must be stupid".
There are people with drives out there that have had to install hard disk drivers using a floppy drive. A floppy drive is a very cheap piece of equipment to add to your PC, even if it's just as a contingency. It makes no sense to save $10 on a computer that might cost anywhere from $400 to $4000, when there might be situations you might need that $10 piece of equipment.
For the record I've also seen mouse drivers and other hardware come only on a floppy disk. Granted most of the time you can download from the net, but compared to pushing a disk that came with your product into a drive it's more work.
What I'd like to see is all hardware and software manufacturers stop distribution of their drivers and software on floppy. It really is an ancient piece of technology that should be dead by now. Sadly it's not.
Say there are 5 real human operators at the end of the line, and everyone uses these little tricks to get hold of them. Well you're still not going to get to a human more quickly. You'll either be put on hold for a much longer period of time, or be told to call back. The company still isn't going to hire more people, you're just clogging it up for thoese that genuninely need to interact with a human being because what they want to do is not one of the standard menu options.
Im sorry, from the above its apparent you dont understand what design patterns are and Im not about to try and teach you.
No I understand them well. I've applied them. I've seen what they do to a project in the long run and I abhor them.
Thanks for not trying to teach me about them. Though it would have been amusing.
I somehow suspect though, given your earlier comments regarding UML that you think designs should live in ones head, in pseudo code or maybe even that flow charts are sufficient or maybe you know of an even better set of methodologies to apply for (OO) design and documentation?
Um I didn't even mention UML. Someone else did. How about actually READING a post, including who it's by before attempting to blast them? Just a tip there. You just look ridiculous when you get it wrong. It prooves beyond a shadow of a doubt that you don't know what you're talking about (or indeed who you're talking to).
My stance: Design good. Cookie cutter design pattern method bad.
Designs should definitely be documented, just not in the vague jibberish design patterns cloak them in. Designs should be clear and concise, and solve a problem that has been analysed.
As an example, when an engineer or architect solves a problem, sure they use the knowledge and techniques of the past, but what they don't do is try to make their next project just like that other one they just did because it's sort of similar.
Okay, so what exactly is your position here? Is it that there is no possible way that design patterns can be useful for software engineering? Because I just have to disagree with you on this point.
My position: Design patterns considered harmful. Design patterns teach you to be lazy and try to force a problem that you may not have explored into a problem you do understand. Often encourages overengineering through the unnecessary application of patterns.
I think you are letting your bitterness for the current state of software desgn prejudice your view of a perfectly valid software engineering concept. After all, if most people weren't misusing design patterns in software design, they would probably just find something worse..
So you're arguement here is that if people didn't use this bad methodology they'd find something worse???? And you have the gaul to call me bitter?
There's nothing valid about solving problems that don't necessarily exist. That's what design patterns encourage.
Oh yeah that's the problem. People believing in things. People making up their minds, and making a stand for what they believe is absolutely evil and should be banned. Right now. You should take every experience you have, and any common sense, scientific process, and anything else that appeals to logic, reason or emmotion and throw it out the window so that you can keep an open mind. Wooo wooo witches and ghosts and other scary things and evolution is wrong.
Yes we could, but you'll "prove" us wrong by telling us you "feel" they are "obviously" inherently evil.
I happen to have plenty of experience with what I'm talking about.
Nice emmotive argument there. Too bad it's not actually based on anything I said.
Only if you don't know how to use any frameworks. Writing a web app in raw PHP is like writing a client app drawing directly to the screen and capturing clicks and keystrokes. Of course GUI toolkits are going to be more mature having been a core area of commercial development over the past 25 years while the web has only been heavily prospected for 10.
Sounds like you're saying web apps aren't ready for prime time on the one hand, and that's why they're slower, but on the other hand they're better so nyer!
In any case you're seriously confusing tool maturity (and 10 years is plenty of time to mature) with complexity and architecture.
Client apps are much quicker to build. I've worked on both, and I've used plenty of frameworks for both. If you haven't seen that you're either writing web apps much quicker than anyone else I know, or you've never seen true client RAD at work.
So you think people like to download and install software, and you think that everything should be written in a verbose language with bloated APIs using cumbersome engineering techniques, and you think that content creation is an afterthought that can be accomplished equally well on any platform.
So you're saying the only options: a) The web + today's latest fad AJAX b) Something big and bloated and overengineered?
That's a narrow view. I thought there were lots of languages, tools, and ways of presenting content, all with their advantages and disadvantages. But I guess I stand corrected.
Any moron can list 100 flaws with the web, but it takes a genius to come up with something better and get market penetration.>/I>
Yes sometimes when I use the web it feels like I've been penetrated by the market.
When something better comes along, I'll be there because I don't have some idealogical ties to the 'one true way' of doing things.
No you'll be too busy saying the web is good and standard and we don't need anything new. You're discouraging people from using anything other than the web with that post right there.
Things go in cycles. Web pages will be unpopular at some point. So will thin client. So will design patterns. Everything goes through cycles (it doesn't just evolve).
HTML + CSS is orders of magnitude simpler than presenting typical content through a GUI.
You've never designed a good GUI with a RAD have you? Web pages, or GUIs are just as easy to design. It all depends on having good, efficient, flexible tools for building your GUI.
People will be shopping on amazon, networking on myspace, bookmarking on del.icio.us, deleting outlook and switching to webmail, getting directions on Google maps, and otherwise making use of the web while you pine away for your IDE and compilers. Sorry the computing world is passing you by.
Perhaps, but the guy's right. People who get paradigm happy during the early years of their career I can understand. But 30-50 year olds who still think every new technology is fantastic, and that they better jump on that band wagon or it'll pass them by...well that's just sad!
Ask yourself what couldn't be done with 10 year old technology that can be today. Sure you can leverage faster processors, graphics etc. but fundamentally none of these new technologies are offering any new capability, and that's what the problem is here - increased complexity at huge cost for zero benefit.
Perhaps you've never been introduced to abstraction before. Abstraction is what makes it possible to code in your pet language like Java.
Abstraction for abstraction sake leads to incredible waste. Instead of abstracting everything, ask yourself if you're ever REALLY likely to want to change that feature you're making pluggable for instance. You don't want an application that's a jack of all trades and master of none. Spend the time building actual real functionality into code, and use abstraction as a tool, instead of a way of adding 30 new layers that you'll never use to the application, and making it confusing to follow anything that's going on.
Instead of pointing out the things that web applications are missing, I challenge you to figure out a way to add all the benefits and features of web applications to "true software model":
* No Installation
Oh you have a magic web browser, that requires no installation do you? Or are you using an operating system that happened to install a web browser when you installed it.
* Easy content creation
The content is easy to create because there are tools available. You must be young to think that HTML was the first tool to allow "easy content creation">
* Global hyperlinking system
* Speedy interaction
TCP is quick. No matter what you send over it you're going to be limited by the speed of this interaction. Web page rendering is actually still quite slow despite years of web browser development.
* True rapid development
For true rapid development you need drag and drop positioning, and the ability to link events and/or actions to code behind it quickly. I've seen some good WYSIWYG HTML editors, but none that handle for example custom tags in JSP.
* Standard navigation/bookmarking scheme
Well anything can become a standard if you get enough people to adopt it. In any case all you mean is HTTP URLs are standard. So what, they're only useful because there's already so much software out there that understands them.
People will be shopping on amazon, networking on myspace, bookmarking on del.icio.us, deleting outlook and switching to webmail, getting directions on Google maps, and otherwise making use of the web while you pine away for your IDE and compilers. Sorry the computing world is passing you by.
Everything you've written above has been done in the mid 90s. Webmail isn't new nor does it require AJAX. Samme with the rest except perhaps google maps you have NEED live updating. Wake up and smell the hype!
Given the information in the post, how can you deduce that the poster is missaplying patterns, or using them in some sort of cookie cutter fashion?
Patterns are all about being used in a "cookie cutter fashion". The only way in which I am "attacking" this guy is that he's obviously read about patterns and fallen for the hype of this paradigm. I believe the entire philosophy is deeply flawed.
How do you know the he isn't analysing his problems in a competent way?
Because I believe that the application of standard "patterns" is a bad way of analysing a problem. You're trying to fit a problem into one of a handful of solutions (patterns) instead of doing an actual analysis. An actual analysis requires that you don't jump up and yell "oooo oooo I know how to fix that" before you've taken in all the details.
All he said was that reading up on design patterns improved his coding and you jump all over the guy.
Actually he said reading about patterns have made him a better programmer, and I therefore think he's being naive, or that his inexperience makes him think he's improving when actually design patterns are harmful when applied rigorously.
Just because a methodology can be (or is) misused doesn't make it bad.
You could also argue that just because a nuclear weapon can be misused, doesn't make it bad.
A methodology that consistently encourages bad, unscientific behaviour however is quite bad. One that has been bought into (taken hook line and sinker!) by the coding community at large is worse. In fact it's terrible. It's the reason we have bloated "enterprise" software with 10-20 distinct "layers" of abstraction where a simple well written application (or in some cases a bunch of scripts) would be more suitable.
Design patterns and any other methodology tends to operate like a cult. That is until the next cult comes along and teaches you the error of your ways.
I realise what I'm saying is unpopular but honestly when you have applications written using patterns, standard tools, and "best practices" that take a day to modify trivially something's come of the rails and people need a good old slap with a wet fish!
Oh goodie. Another one that thinks their coding has been improved by the methodology from hell. What you've learnt how to do, and do confidently, is misapply a solution to a problem, to a slightly related problem. Or in other words you see a requirement to build a bridge, pull out your trusty cookie cutter bridge building pattern, and promptly proceed to build an arch bridge, where a suspension bridge was needed, because the two lines of vague description ("pattern to build a link between two pieces of land isolated by water") was too vague for you to see that it shouldn't be applied in this case (you or the pattern author forgot to include a pre-requisit that the span of the bridge should be under a certain length).
There is no substitute for analysing a problem. Giving some credence to past solutions is absolutely and fundamentally important in doing so. Being lazy and just applying a cookie cutter pattern (or worse an entire freaking set of them) that attempts to be non-specific to a given problem (and many general solutions to a problem are poor) is just a recipe for over-engineering that is absolultey encouraged by design patterns ("Why didn't you use a standard pattern?")
It took me a long time to work out for myself why I felt so uneasy about patterns, but once I did I understood perfectly why I disliked them so much at a gut level.
I agree with you 100%. Only problem is that the technology being used now is so overengineered - even standard stuff that everyone uses (J2EE/struts/tiles/hibernate/spring etc.) - and bloated that you need 6 months of experience to get anything done. What I want to know is WTF ever happened to RAPID application development.
I miss the days when it took a day and zero experience to knock up a screen in Delphi, VB or C++ builder, and then another 3-4 days to actually plug everything together once the business had agreed that the screen was okay. Now it takes 15 minutes at work of rebuilding an Effing EAR file (with lots of WARS and JARS in it to boot), then redeploying and hoping that the app server picks up the changes correctly - just to see some damned screen changes. Never mind going through 12 layers of abstraction to add a goddamn field that already exists in the database to the screen.
Re:Why are you so unscientific in your testing
on
Ask The Mythbusters
·
· Score: 1
Just had to make a comment about this
First: I was using an example of a show they'd already done on purpose. " For example you'll test " probably should have read " For example you've tested" but I didn't think I was being that unclear unless the aim was to flame someone without even trying to understand what they're saying.
Second: I've actually seen it cut down to half an hour. In fact I've seen highlights of Mythbuster episodes shown as part of a larger science/technology. Also note that many episodes cover more than one myth.
I could have worded what I said better, I grant you, and not doing so is my fault. Bottom line is I was busy with something else and wanted to comment while I had an oportunity to do so.
My point is still valid - they can retain the entertainment factor, and actually make the show scientifically credible. My question therefore is why they've chosen not to. The show masquerades as science when the techniques they use are not scientific at all, and they devote zero time to the scientific method (controls, repeatability, showing what others have done).
How about instead of criticising and berating me over getting the duration of their show wrong, you actually have a look at what I was trying to say. Just because the forum you're using is a message board on the net doesn't mean you can't cut a person some slack, or that you need to be rude.
Why are you so unscientific in your testing
on
Ask The Mythbusters
·
· Score: 1
For example you'll test one or two types of cell phone for it's ability to make petrol explode when the phone is called, then conclude that all cell phones are safe to use at the petrol pump. You do this time and time again with all your myths - conclude from one or two tests that the whole myth is bogus. I understand it's a half hour show and that you're there to entertain, but could you not take THREE minutes out of each and every show to point to more rigorous scientific studies? It would make what you do SO much more credible, and retain the entertainment zing!
Only a handful of atheletes will make it as pros either. They should also find something else to do. The whole idea of paying people large amounts of money for being number one at a sport, at acting etc. means that you attract the best talent. Most of them end up with their lives ruined but since they're all chasing that huge payoff, you get cut throat competition amongst the cream of the crop needed to push the boundaries on these endevours.
He spent 11 years working on the problem ineptly, with no expertise, and no training in chemistry. Hell if I was spending 11 years on a problem, I'd be teaching myself some basic chemistry instead of just trying random products. I don't think it'd take me as long to work outI had to make notes either (He lost his "bouncing" bubble because he doesn't know what he did to make it. In 11 years I'd be teaching myself enough chemistry to read scientific papers.
If the chemist could solve the overall problem, I don't think it would have likely taken him long to workout how to preven the dye from sinking to the bottom of the bubble.
So in other words you think the person that sets the problem and/or funds the project deserves the credit while the guy that actually solves it deserves to be a footnote in history.
*Start sarcasm* So I guess we owe the US patent office big time for the theory of relativity. After all if Einstein didn't have a salary he'd never have had time to come up with the theory. In fact why is Einstein even famous. He only came up with the idea.
Oh and lets not give any credit to any of the software developers at Microsoft. It was Billy G and Balmer that funded the company. So they should be given credit for everything in every version of Windows, Office and every other piece of software they aquired. Developers schmelopers! *End sarcasm*
Personally my respect goes to the chemist that solved the problem. Not the compulsive nut job that couldn't repeat anything because he didn't keep proper notes and who had to throw a massive party and cover everyone with colour to realise they'd freak out if you did that.
Not to whin(g)e, but tweaking modelines in XF86Config(-4) is straightforward.
Ahhhhh. Spoken like a true alpha geek. Modelines are easy to tweak to a computer expert or enthusiast. Just like a car's engine would be easy to tweak to a mechanic or car enthusiast. That doesn't mean the rest of the planet wants to be required to know how to do it. They want the machine to work without them having to think about the details, so they can concentrate on writing their document or editing their spreadsheet. And rightly so. Imagine what the automobile industry would be like if we insisted everyeone who drove a car was a qualified mechanic. Sure we do insist you can check oil and water, but the computer equivalent would be checking you have hard disk space left and emptying the recycle bin.
As for the rest of your rambling post, you're basically making an analogy between office and a neurotic tart. A counter analogy would be Linux as the pimply geek girl that wonders why no one calls the next morning. Neither of them are desirable in the long term, and nobody appreciates them for what they are, because they're looking for something better out there. In the mean time they'll use and abuse them. But to be honest I find these analogies superfluous and a little immature. If you stay focused on the facts neither MS Office or the open source Linux based alternatives are even close to idal.
If you honestly believe software can be anything like manufacturing you're part of the problem. Manufacturing involves setting up _repeatable_ processes. Writing software, the code is different each and every time. It is not unskilled work. There is no process "solid enough" to deal with the infinite variability of the software which will be written.
JUnit, J2EE and all the frameworks that surround this technology are nothing more than tools. The tools can be good or bad, suited or unsuited to a task. Unskilled IT staff applying these tools without any concept of what the tradeoffs are gives you the slow messy development we're seeing today.
In any case, it takes a lot to learn the myriad of frameworks and technologies, only to misapply them because the process of writing software is being boxed into the manufacturing mentality you describe. The skill required to use these tools at all, let alone effectively, requires a good understanding of the tools, their applicability and their limitations.
I've seen a team of 2-3 SKILLED developers outdo a team of 20-30 "let's put bums on seats" developers.
Clearly you're not a lawyer. If you were you wouldn't be posting on a public message board about your employer in regards to something that's legally actionable. Even though you're defending them you're opening yourself up to being fired or sued!
You know what I don't miss powerbuilder (unstable) or VB (disorganised mess), but I do miss Delphi.
Agile is not at all based on RAD. I crave the days that you could drag a dozen components onto a frame, write a few lines of code and have an actual well behaving prototype sitting on the screen. I have an honest question for you. Did you ever work with VB, Delphi or perhaps CBuilder?
Spring is awful. Inversion of control is a silly concept. Yes you write less code, but it's all externalised where it's hard to debug. If you do change the behaviour through the externalised files it'll probably break more than you realise. Besides there's a lot to be said for the visibility and simplicity in following explicit error/exception handling.
Struts is awful. Get anything wrong in the config and you get a nice blank screen. Then spend ages debugging because you're forced to rebuild an EAR file containing a WAR file...etc. etc. Same with all J2EE. Layer upon layer of wrappers, interfaces and plugs, all of which have to be changed to propagate anything to the screen.
Hibernate is woeful. Ever tried writing a complex query using hibernate? Hint: HQL has severe limits (for example try grouping by an agregate function). Or debugging null sessions? Horrible.
Half the problem with design is that esign patterns are all the rage. Good ideas in theory but in practice it means every half decent programmer finding a similar problem to the one you're solving and cobbling on the solution whether or not it fits, instead of actually ANALYSING the problem in the first place. Then lets abstract everything out as much as possible so it's pluggable. (Never mind that we'll never actually switch or plug in anything else). J2EE design "best practice" in recent years is a mess of overengineered nonsense.
We have a brand new buzzword^H^H^H^H^H^H^H^Htechnology that will save you millions and make all your technology function correctly. It's called AOP. It'll make your code more complex, probably force you to use non-standard implementations of Java, but it will be worth it in the end. We promise. Trust us.
Bring back the concept of RAPID application development. The only thing that was missing over 10 years ago was scalability. Today's frameworks are bloated and horrible. Testing will be much simpler, and require less tools when it's QUICK to build screens, and you don't have to propagate changes by hand to 15 layers of damn code. You may also need to employ a test team that has an understanding of how the code works, as well as the business requirements. It can and has been done.
/ Clippy has detected a flame war about to start. | Would you like to: \ 1) Karma whore?
\ 2) Join in the flame war?
\ 3) Go for the humorous post?
\ / __ \
\O| |O|
|| | |
|| | |
|| |
|___/
I'm not a glass is half empty kind of person at all. I just choose not to haulcinate half a glass of water when in reality there is none. I also choose not to make this a personal attack. (Tip: Personal attacks may sound cool and witty when you write them but actually they just detract from what rational people will think).
I was making the point that a regular, well researched science show ie a QUALITY show as opposed to one person's rant (be it scientist, college kid, or pimply teen) is going to require a team of people with the time and money to do it.
Perhaps you don't understand the value of having more than one source for information. Perhaps you don't understand what real science is. One thing is for sure, you have appauling social skills. The last line of your comment shows that, and ironically is the exact kind of response I would expect from a bored teenager.
Name me one quality science show that has been written, researched and produced by a single individual without the backing of a team. It takes more than just a scientist or two "talking about what they're doing". It takes opposing views, research on the history and current state of an area of scientific interest, political and social debate about the changes the science can cause. You don't need millions of dollars to do this, but to get paid professionals you may well need tens of thousands per month.
I propose a naming convention. Astronomers like naming conventions so this won't be too hard to adopt.
Name each large telescope NBT (Next Big Thing/Telescope) and give it a number corresponding to the year it sees first light. If more than one NBT goes online in a year append a letter.
So one day you might have a headline SN2010b discovered with NBT2010a.
Slashdot Mirror
You seem to have fallen prey to the alpha geek mentality. The implication of your post amounts to:
"It works for me. If it doesn't work for you, you must be stupid".
There are people with drives out there that have had to install hard disk drivers using a floppy drive. A floppy drive is a very cheap piece of equipment to add to your PC, even if it's just as a contingency. It makes no sense to save $10 on a computer that might cost anywhere from $400 to $4000, when there might be situations you might need that $10 piece of equipment.
For the record I've also seen mouse drivers and other hardware come only on a floppy disk. Granted most of the time you can download from the net, but compared to pushing a disk that came with your product into a drive it's more work.
What I'd like to see is all hardware and software manufacturers stop distribution of their drivers and software on floppy. It really is an ancient piece of technology that should be dead by now. Sadly it's not.
Say there are 5 real human operators at the end of the line, and everyone uses these little tricks to get hold of them. Well you're still not going to get to a human more quickly. You'll either be put on hold for a much longer period of time, or be told to call back. The company still isn't going to hire more people, you're just clogging it up for thoese that genuninely need to interact with a human being because what they want to do is not one of the standard menu options.
Im sorry, from the above its apparent you dont understand what design patterns are and Im not about to try and teach you.
No I understand them well. I've applied them. I've seen what they do to a project in the long run and I abhor them.
Thanks for not trying to teach me about them. Though it would have been amusing.
I somehow suspect though, given your earlier comments regarding UML that you think designs should live in ones head, in pseudo code or maybe even that flow charts are sufficient or maybe you know of an even better set of methodologies to apply for (OO) design and documentation?
Um I didn't even mention UML. Someone else did. How about actually READING a post, including who it's by before attempting to blast them? Just a tip there. You just look ridiculous when you get it wrong. It prooves beyond a shadow of a doubt that you don't know what you're talking about (or indeed who you're talking to).
My stance:
Design good.
Cookie cutter design pattern method bad.
Designs should definitely be documented, just not in the vague jibberish design patterns cloak them in. Designs should be clear and concise, and solve a problem that has been analysed.
As an example, when an engineer or architect solves a problem, sure they use the knowledge and techniques of the past, but what they don't do is try to make their next project just like that other one they just did because it's sort of similar.
Okay, so what exactly is your position here? Is it that there is no possible way that design patterns can be useful for software engineering? Because I just have to disagree with you on this point.
My position: Design patterns considered harmful. Design patterns teach you to be lazy and try to force a problem that you may not have explored into a problem you do understand. Often encourages overengineering through the unnecessary application of patterns.
I think you are letting your bitterness for the current state of software desgn prejudice your view of a perfectly valid software engineering concept. After all, if most people weren't misusing design patterns in software design, they would probably just find something worse..
So you're arguement here is that if people didn't use this bad methodology they'd find something worse???? And you have the gaul to call me bitter?
There's nothing valid about solving problems that don't necessarily exist. That's what design patterns encourage.
This is the problem with the world today...
Oh yeah that's the problem. People believing in things. People making up their minds, and making a stand for what they believe is absolutely evil and should be banned. Right now. You should take every experience you have, and any common sense, scientific process, and anything else that appeals to logic, reason or emmotion and throw it out the window so that you can keep an open mind. Wooo wooo witches and ghosts and other scary things and evolution is wrong.
Yes we could, but you'll "prove" us wrong by telling us you "feel" they are "obviously" inherently evil.
I happen to have plenty of experience with what I'm talking about.
Nice emmotive argument there. Too bad it's not actually based on anything I said.
Only if you don't know how to use any frameworks. Writing a web app in raw PHP is like writing a client app drawing directly to the screen and capturing clicks and keystrokes. Of course GUI toolkits are going to be more mature having been a core area of commercial development over the past 25 years while the web has only been heavily prospected for 10.
Sounds like you're saying web apps aren't ready for prime time on the one hand, and that's why they're slower, but on the other hand they're better so nyer!
In any case you're seriously confusing tool maturity (and 10 years is plenty of time to mature) with complexity and architecture.
Client apps are much quicker to build. I've worked on both, and I've used plenty of frameworks for both. If you haven't seen that you're either writing web apps much quicker than anyone else I know, or you've never seen true client RAD at work.
So you think people like to download and install software, and you think that everything should be written in a verbose language with bloated APIs using cumbersome engineering techniques, and you think that content creation is an afterthought that can be accomplished equally well on any platform.
So you're saying the only options:
a) The web + today's latest fad AJAX
b) Something big and bloated and overengineered?
That's a narrow view. I thought there were lots of languages, tools, and ways of presenting content, all with their advantages and disadvantages. But I guess I stand corrected.
Any moron can list 100 flaws with the web, but it takes a genius to come up with something better and get market penetration.>/I>
Yes sometimes when I use the web it feels like I've been penetrated by the market.
When something better comes along, I'll be there because I don't have some idealogical ties to the 'one true way' of doing things.
No you'll be too busy saying the web is good and standard and we don't need anything new. You're discouraging people from using anything other than the web with that post right there.
Things go in cycles. Web pages will be unpopular at some point. So will thin client. So will design patterns. Everything goes through cycles (it doesn't just evolve).
I'll bite.
HTML + CSS is orders of magnitude simpler than presenting typical content through a GUI.
You've never designed a good GUI with a RAD have you? Web pages, or GUIs are just as easy to design. It all depends on having good, efficient, flexible tools for building your GUI.
People will be shopping on amazon, networking on myspace, bookmarking on del.icio.us, deleting outlook and switching to webmail, getting directions on Google maps, and otherwise making use of the web while you pine away for your IDE and compilers. Sorry the computing world is passing you by.
Perhaps, but the guy's right. People who get paradigm happy during the early years of their career I can understand. But 30-50 year olds who still think every new technology is fantastic, and that they better jump on that band wagon or it'll pass them by...well that's just sad!
Ask yourself what couldn't be done with 10 year old technology that can be today. Sure you can leverage faster processors, graphics etc. but fundamentally none of these new technologies are offering any new capability, and that's what the problem is here - increased complexity at huge cost for zero benefit.
Perhaps you've never been introduced to abstraction before. Abstraction is what makes it possible to code in your pet language like Java.
Abstraction for abstraction sake leads to incredible waste. Instead of abstracting everything, ask yourself if you're ever REALLY likely to want to change that feature you're making pluggable for instance. You don't want an application that's a jack of all trades and master of none. Spend the time building actual real functionality into code, and use abstraction as a tool, instead of a way of adding 30 new layers that you'll never use to the application, and making it confusing to follow anything that's going on.
Instead of pointing out the things that web applications are missing, I challenge you to figure out a way to add all the benefits and features of web applications to "true software model":
* No Installation
Oh you have a magic web browser, that requires no installation do you? Or are you using an operating system that happened to install a web browser when you installed it.
* Easy content creation
The content is easy to create because there are tools available. You must be young to think that HTML was the first tool to allow "easy content creation">
* Global hyperlinking system
* Speedy interaction
TCP is quick. No matter what you send over it you're going to be limited by the speed of this interaction. Web page rendering is actually still quite slow despite years of web browser development.
* True rapid development
For true rapid development you need drag and drop positioning, and the ability to link events and/or actions to code behind it quickly. I've seen some good WYSIWYG HTML editors, but none that handle for example custom tags in JSP.
* Standard navigation/bookmarking scheme
Well anything can become a standard if you get enough people to adopt it. In any case all you mean is HTTP URLs are standard. So what, they're only useful because there's already so much software out there that understands them.
People will be shopping on amazon, networking on myspace, bookmarking on del.icio.us, deleting outlook and switching to webmail, getting directions on Google maps, and otherwise making use of the web while you pine away for your IDE and compilers. Sorry the computing world is passing you by.
Everything you've written above has been done in the mid 90s. Webmail isn't new nor does it require AJAX. Samme with the rest except perhaps google maps you have NEED live updating. Wake up and smell the hype!
Given the information in the post, how can you deduce that the poster is missaplying patterns, or using them in some sort of cookie cutter fashion?
Patterns are all about being used in a "cookie cutter fashion". The only way in which I am "attacking" this guy is that he's obviously read about patterns and fallen for the hype of this paradigm. I believe the entire philosophy is deeply flawed.
How do you know the he isn't analysing his problems in a competent way?
Because I believe that the application of standard "patterns" is a bad way of analysing a problem. You're trying to fit a problem into one of a handful of solutions (patterns) instead of doing an actual analysis. An actual analysis requires that you don't jump up and yell "oooo oooo I know how to fix that" before you've taken in all the details.
All he said was that reading up on design patterns improved his coding and you jump all over the guy.
Actually he said reading about patterns have made him a better programmer, and I therefore think he's being naive, or that his inexperience makes him think he's improving when actually design patterns are harmful when applied rigorously.
Just because a methodology can be (or is) misused doesn't make it bad.
You could also argue that just because a nuclear weapon can be misused, doesn't make it bad.
A methodology that consistently encourages bad, unscientific behaviour however is quite bad. One that has been bought into (taken hook line and sinker!) by the coding community at large is worse. In fact it's terrible. It's the reason we have bloated "enterprise" software with 10-20 distinct "layers" of abstraction where a simple well written application (or in some cases a bunch of scripts) would be more suitable.
Design patterns and any other methodology tends to operate like a cult. That is until the next cult comes along and teaches you the error of your ways.
I realise what I'm saying is unpopular but honestly when you have applications written using patterns, standard tools, and "best practices" that take a day to modify trivially something's come of the rails and people need a good old slap with a wet fish!
Oh goodie. Another one that thinks their coding has been improved by the methodology from hell. What you've learnt how to do, and do confidently, is misapply a solution to a problem, to a slightly related problem. Or in other words you see a requirement to build a bridge, pull out your trusty cookie cutter bridge building pattern, and promptly proceed to build an arch bridge, where a suspension bridge was needed, because the two lines of vague description ("pattern to build a link between two pieces of land isolated by water") was too vague for you to see that it shouldn't be applied in this case (you or the pattern author forgot to include a pre-requisit that the span of the bridge should be under a certain length).
There is no substitute for analysing a problem. Giving some credence to past solutions is absolutely and fundamentally important in doing so. Being lazy and just applying a cookie cutter pattern (or worse an entire freaking set of them) that attempts to be non-specific to a given problem (and many general solutions to a problem are poor) is just a recipe for over-engineering that is absolultey encouraged by design patterns ("Why didn't you use a standard pattern?")
It took me a long time to work out for myself why I felt so uneasy about patterns, but once I did I understood perfectly why I disliked them so much at a gut level.
I agree with you 100%. Only problem is that the technology being used now is so overengineered - even standard stuff that everyone uses (J2EE/struts/tiles/hibernate/spring etc.) - and bloated that you need 6 months of experience to get anything done. What I want to know is WTF ever happened to RAPID application development.
I miss the days when it took a day and zero experience to knock up a screen in Delphi, VB or C++ builder, and then another 3-4 days to actually plug everything together once the business had agreed that the screen was okay. Now it takes 15 minutes at work of rebuilding an Effing EAR file (with lots of WARS and JARS in it to boot), then redeploying and hoping that the app server picks up the changes correctly - just to see some damned screen changes. Never mind going through 12 layers of abstraction to add a goddamn field that already exists in the database to the screen.
Just had to make a comment about this
First: I was using an example of a show they'd already done on purpose. " For example you'll test " probably should have read " For example you've tested" but I didn't think I was being that unclear unless the aim was to flame someone without even trying to understand what they're saying.
Second: I've actually seen it cut down to half an hour. In fact I've seen highlights of Mythbuster episodes shown as part of a larger science/technology. Also note that many episodes cover more than one myth.
I could have worded what I said better, I grant you, and not doing so is my fault. Bottom line is I was busy with something else and wanted to comment while I had an oportunity to do so.
My point is still valid - they can retain the entertainment factor, and actually make the show scientifically credible. My question therefore is why they've chosen not to. The show masquerades as science when the techniques they use are not scientific at all, and they devote zero time to the scientific method (controls, repeatability, showing what others have done).
How about instead of criticising and berating me over getting the duration of their show wrong, you actually have a look at what I was trying to say. Just because the forum you're using is a message board on the net doesn't mean you can't cut a person some slack, or that you need to be rude.
For example you'll test one or two types of cell phone for it's ability to make petrol explode when the phone is called, then conclude that all cell phones are safe to use at the petrol pump. You do this time and time again with all your myths - conclude from one or two tests that the whole myth is bogus. I understand it's a half hour show and that you're there to entertain, but could you not take THREE minutes out of each and every show to point to more rigorous scientific studies? It would make what you do SO much more credible, and retain the entertainment zing!
Only a handful of atheletes will make it as pros either. They should also find something else to do. The whole idea of paying people large amounts of money for being number one at a sport, at acting etc. means that you attract the best talent. Most of them end up with their lives ruined but since they're all chasing that huge payoff, you get cut throat competition amongst the cream of the crop needed to push the boundaries on these endevours.
Two counterpoints:
He spent 11 years working on the problem ineptly, with no expertise, and no training in chemistry. Hell if I was spending 11 years on a problem, I'd be teaching myself some basic chemistry instead of just trying random products. I don't think it'd take me as long to work outI had to make notes either (He lost his "bouncing" bubble because he doesn't know what he did to make it. In 11 years I'd be teaching myself enough chemistry to read scientific papers.
If the chemist could solve the overall problem, I don't think it would have likely taken him long to workout how to preven the dye from sinking to the bottom of the bubble.
So in other words you think the person that sets the problem and/or funds the project deserves the credit while the guy that actually solves it deserves to be a footnote in history.
*Start sarcasm*
So I guess we owe the US patent office big time for the theory of relativity. After all if Einstein didn't have a salary he'd never have had time to come up with the theory. In fact why is Einstein even famous. He only came up with the idea.
Oh and lets not give any credit to any of the software developers at Microsoft. It was Billy G and Balmer that funded the company. So they should be given credit for everything in every version of Windows, Office and every other piece of software they aquired. Developers schmelopers!
*End sarcasm*
Personally my respect goes to the chemist that solved the problem. Not the compulsive nut job that couldn't repeat anything because he didn't keep proper notes and who had to throw a massive party and cover everyone with colour to realise they'd freak out if you did that.
Not to whin(g)e, but tweaking modelines in XF86Config(-4) is straightforward.
Ahhhhh. Spoken like a true alpha geek. Modelines are easy to tweak to a computer expert or enthusiast. Just like a car's engine would be easy to tweak to a mechanic or car enthusiast. That doesn't mean the rest of the planet wants to be required to know how to do it. They want the machine to work without them having to think about the details, so they can concentrate on writing their document or editing their spreadsheet. And rightly so. Imagine what the automobile industry would be like if we insisted everyeone who drove a car was a qualified mechanic. Sure we do insist you can check oil and water, but the computer equivalent would be checking you have hard disk space left and emptying the recycle bin.
As for the rest of your rambling post, you're basically making an analogy between office and a neurotic tart. A counter analogy would be Linux as the pimply geek girl that wonders why no one calls the next morning. Neither of them are desirable in the long term, and nobody appreciates them for what they are, because they're looking for something better out there. In the mean time they'll use and abuse them. But to be honest I find these analogies superfluous and a little immature. If you stay focused on the facts neither MS Office or the open source Linux based alternatives are even close to idal.
If you honestly believe software can be anything like manufacturing you're part of the problem. Manufacturing involves setting up _repeatable_ processes. Writing software, the code is different each and every time. It is not unskilled work. There is no process "solid enough" to deal with the infinite variability of the software which will be written.
JUnit, J2EE and all the frameworks that surround this technology are nothing more than tools. The tools can be good or bad, suited or unsuited to a task. Unskilled IT staff applying these tools without any concept of what the tradeoffs are gives you the slow messy development we're seeing today.
In any case, it takes a lot to learn the myriad of frameworks and technologies, only to misapply them because the process of writing software is being boxed into the manufacturing mentality you describe. The skill required to use these tools at all, let alone effectively, requires a good understanding of the tools, their applicability and their limitations.
I've seen a team of 2-3 SKILLED developers outdo a team of 20-30 "let's put bums on seats" developers.
Clearly you're not a lawyer. If you were you wouldn't be posting on a public message board about your employer in regards to something that's legally actionable. Even though you're defending them you're opening yourself up to being fired or sued!
You know what I don't miss powerbuilder (unstable) or VB (disorganised mess), but I do miss Delphi.
Agile is not at all based on RAD. I crave the days that you could drag a dozen components onto a frame, write a few lines of code and have an actual well behaving prototype sitting on the screen. I have an honest question for you. Did you ever work with VB, Delphi or perhaps CBuilder?
Spring is awful. Inversion of control is a silly concept. Yes you write less code, but it's all externalised where it's hard to debug. If you do change the behaviour through the externalised files it'll probably break more than you realise. Besides there's a lot to be said for the visibility and simplicity in following explicit error/exception handling.
Struts is awful. Get anything wrong in the config and you get a nice blank screen. Then spend ages debugging because you're forced to rebuild an EAR file containing a WAR file...etc. etc. Same with all J2EE. Layer upon layer of wrappers, interfaces and plugs, all of which have to be changed to propagate anything to the screen.
Hibernate is woeful. Ever tried writing a complex query using hibernate? Hint: HQL has severe limits (for example try grouping by an agregate function). Or debugging null sessions? Horrible.
Half the problem with design is that esign patterns are all the rage. Good ideas in theory but in practice it means every half decent programmer finding a similar problem to the one you're solving and cobbling on the solution whether or not it fits, instead of actually ANALYSING the problem in the first place. Then lets abstract everything out as much as possible so it's pluggable. (Never mind that we'll never actually switch or plug in anything else). J2EE design "best practice" in recent years is a mess of overengineered nonsense.
We have a brand new buzzword^H^H^H^H^H^H^H^Htechnology that will save you millions and make all your technology function correctly. It's called AOP. It'll make your code more complex, probably force you to use non-standard implementations of Java, but it will be worth it in the end. We promise. Trust us.
Bring back the concept of RAPID application development. The only thing that was missing over 10 years ago was scalability. Today's frameworks are bloated and horrible. Testing will be much simpler, and require less tools when it's QUICK to build screens, and you don't have to propagate changes by hand to 15 layers of damn code. You may also need to employ a test team that has an understanding of how the code works, as well as the business requirements. It can and has been done.
/ Clippy has detected a flame war about to start.
| Would you like to:
\ 1) Karma whore?
\ 2) Join in the flame war?
\ 3) Go for the humorous post?
\ / __ \
\O| |O|
|| | |
|| | |
|| |
|___/
I'm not a glass is half empty kind of person at all. I just choose not to haulcinate half a glass of water when in reality there is none. I also choose not to make this a personal attack. (Tip: Personal attacks may sound cool and witty when you write them but actually they just detract from what rational people will think).
I was making the point that a regular, well researched science show ie a QUALITY show as opposed to one person's rant (be it scientist, college kid, or pimply teen) is going to require a team of people with the time and money to do it.
Perhaps you don't understand the value of having more than one source for information. Perhaps you don't understand what real science is. One thing is for sure, you have appauling social skills. The last line of your comment shows that, and ironically is the exact kind of response I would expect from a bored teenager.
Name me one quality science show that has been written, researched and produced by a single individual without the backing of a team. It takes more than just a scientist or two "talking about what they're doing". It takes opposing views, research on the history and current state of an area of scientific interest, political and social debate about the changes the science can cause. You don't need millions of dollars to do this, but to get paid professionals you may well need tens of thousands per month.
I propose a naming convention. Astronomers like naming conventions so this won't be too hard to adopt.
Name each large telescope NBT (Next Big Thing/Telescope) and give it a number corresponding to the year it sees first light. If more than one NBT goes online in a year append a letter.
So one day you might have a headline SN2010b discovered with NBT2010a.