|
Application Development Without Programming III
Just to add yet more burning dung to the pile of offal generated by these threads:
The wisest response posted so far that, that coincidentally matches my feelings on the subject is from 'Has':
http://discuss.fogcreek.com/joelonsoftware/default.asp?cmd=show&ixPost=134889&ixReplies=35
>> thank god for all the unreasonable buggers demanding what the "reasonable" folks say can't be done. So keep at it my man!
...and...
>> learning to program isn't about learning a language's features, or what libraries to use, or what techno-buzzwords to spout when impressing friends and family. It's about 1. identifying the big, complex problem you wish to solve, followed by 2. breaking that big, complex, initial problem down into lots of small, simple, little problems that you can easily solve one at a time.
---
I find that most programmers have 'survivor' mentality. They have been to hell and back, usually needlessly, and therefore get very emotional about the dues that they paid which they expect anyone else to pay who presumes to enter their illustrious realm.
Jason has posted some questions that may superficially come off as PHD level purist gobbledegook, but I been taking the core of his questions to be: is there any way to make software that doesn't demand a ridiculously steep learning curve in the nuts and bolts? The reaction from programmers who have been doing this for years seems to be like a blue collar worker's dismissal of anyone who seeks an easier and more direct way to do something backbreaking.
I have encountered this bias often with programming tools over the years. I have both generated this 'survivor' FUD myself and I have been victimized and distracted by it at other times.
12 years ago I poured my heart, soul and liver into a 'application framework' in C++ for developing a certain type of Windows application. When a co-worker suggested VB (then just coming out) I trashed him and told him to crawl back in his sewer hole. But in retrospect, he was right because I was spending 14 months to develop functionality you could buy off the shelf for $199.
More recently, in the late 90s I was a Delphi maven - shoe on other foot. Delphi's environment gave me an exceptionally simple and integrated way to develop applications containing custom controls. I would point this out to people who were dealing with VB's bugs and who spent much time integrating VC++ controls with VB - I would say "there is absolutely an easier way and less risky way" and they would look at me like I was an idiot.
The profusion of geek-ego-centered complex alternative ways to do simple things makes modern programming a garbage pile of details. And I wonder if fragile techie egos that protect their turf contribute to the malaise in hiring of IT people. Do managements look at what we do and say and just dismiss it with "aw, f*ck it! we'll go back to paper." I wonder.
A few years ago you saw companies squandering millions of dollars to build elaborate Java based architectures when a simple Perl & PHP setup would have sufficed. You see this pattern of overly complex 'survivor' mentality over and over, treating complex work and details like entitlements.
I think it's legitimate to give the field a once over from outside and just say the words: "this is ridiculous. Isn't there a simpler way?"
Bored Bystander
Saturday, April 24, 2004
"I think it's legitimate to give the field a once over from outside and just say the words: "this is ridiculous. Isn't there a simpler way?""
I agree. However, "Doc" seemed to believe that you could remove the programming from programming.
I do agree that tools could be easier to use. I'm a recent Delphi convert (just learning it now). Wow, what a graceful architecture.
However, there is still huge room for improvment (thus the market for Code Rush and Castalia).
But there's a huge difference between removing the Administrative burdens (remembering variable names, doing garbage cleanup, writing the implementation of a function in addition to the interface, etc.) and "can't I just tell it what I want to do?"
BOTTOM LINE:
There will always be room for improvement in a language (and we should D E M A N D it).
There will also always be a need for someone who can translate "just do it" into precise code.
Remember the fellow who created Visicalc? Remember why?
He was a programmer who thought programming would become so easy there'd be no demand. Went back to school to get a biz degree. Discovered how accountants use spreadsheets. Viola... an entire industry.
Oh, and we now find, 20 years later, that programming still ain't easy.
Hey, I wish it were. I program both because I love it and because I sell the products I make. I'd love it if CREATING them took 1 month instead of 10. I'd spend the rest of the time playing with my kids.
So... when this new magic development system comes around, sign me up!
Mr. Analogy
Saturday, April 24, 2004
You have a point, but I dont really see the connection with the Docs post. I agree that sometimes things get needlessly complex in specific cases. I dont agree that this is true for programming in it self though.
Delphi does not make programming easier, it just reduces the amount of programming you have to do becasue it provides you with premade stuff for common tasks. You have the widgets and the event loop all taken care of. But writing a consol app isnt easier, is it?
I cant conceive of a way to abstract logic. You have to spell it out, or you lose the control.
Eric Debois
Saturday, April 24, 2004
>> I cant conceive of a way to abstract logic. You have to spell it out, or you lose the control.
Indeed. I agree completely.
Admittedly my post was a hybrid of opinions. I wasn't backing up everything Doc Jason said, just one aspect that occurred to me - which is that programming has become more about itself than about solving problems or implementing logic or creating solutions.
My point is: an outsider to programming can probably find absolutely no logical entry point, no segue', no Programming 101.
And there appear to be no politically acceptable ways to say this or express legitimate confusion over selection of a direction for learning, w/o being trashed as a high-level, white gloved sycophant. Someone who asks this question gets yelled at for appearing to simplify "legitimate" complexity.
Bored Bystander
Saturday, April 24, 2004
> My point is: an outsider to programming can probably find absolutely no logical entry point, no segue', no Programming 101.
Outsiders begin by specifying the problem: the requirements. The only problem that he specified was that he didn't know how to program (didn't specify what he wanted to program); if he had specified what he wanted to program, then people might have been able to suggest some appropriate programming tools.
Christopher Wells
Saturday, April 24, 2004
"I been taking the core of his questions to be: is there any way to make software that doesn't demand a ridiculously steep learning curve in the nuts and bolts?"
I propose that the nuts and bolts don't matter.
Doesn't anyone here do high-level design? For the most part, you are _supposed_ to architect any project at a high level before you ever write any code. Now, in reality, that probably doesn't happen as often as it should. But either way, there is a disconnect between the design (blueprint) and the nuts and bolts (construction).
The different programming languages or development environments are just tools to get the job done. VisualBasic, for example, makes some projects much easier than doing the equivlant in C++. However, the opposite is also true -- sometimes VB makes things harder. The language is only a tool.
A lay person can help with the design. In fact, in a ideal world the lay person should. This is no different from me helping to design my own house. I sit down with an architect and we work out a plan. But I still need the architect because he knows the nuts and bolts. He knows why I need to have walls in certain places and how much everything will cost. Software development and building design and construction and very similar in this way.
We are also seeing the general state-of-the-art in the computing improve and simplfy all the time. Just look at the recent rise of Java. Here is a platform that has automatic memory management, simple object-orientedness, and huge library of reusable code that grows constantly. As Doc Jason said, Sun advertises J2EE has bringing programming to the masses! How many times in the last decade have we heard that? Does anyone ever believe it anymore?
It's interesting about your talk about "elaborate Java based architectures when a simple Perl & PHP setup would have sufficed". There are alot of terrible developers out there -- any they are the ones who build these horribly monsterous projects.
Lay people are also terribly bad at design in this way. They design hugely complicated applications because they don't understand the software development in general. I had one client that wanted a very simple (or so he thought) feature addition. He didn't want me to do alot of work so he was very *specific* about what he wanted. Perhaps it's ironic in programming, but the more specific you are the more work it is. I discussed the feature with him and got him give me what he wanted ideally if time and money were no option. In the end, I built a *general* solution that did much more and it took less time than building what he considered simple.
Almost Anonymous
Saturday, April 24, 2004
Eric >> Delphi does not make programming easier, it just reduces the amount of programming you have to do becasue it provides you with premade stuff for common tasks.
Not only that, but languages like Pascal, Basic or Python make us more productive because they remove the needless complexity that come with a language like C. For instance, pointers are a handy tool and should be available, but in this day and age, nobody should spend time doing this with such daily task as handling strings.
Incidently, Basic compilers like PowerBasic or PureBasic show that you can have a highly productive language and still get very tight, dependance-free EXE's if you need. It's not the language, it's the compiler :-)
I totally agree with Bored B. It takes a lot of wisdom and self-confidence to stop doing things the old fashioned way when it's obvious that there are much better and productive ways to solve the problem. I used to think that VB sucked because of its runtime (and possibly OCX's) requirement. But now that I understand fairly well how the whole thing works, how to package and deploy a VB app... and how productive you are working with a tool like that, in this days and age, who cares if you need to ship a 1meg runtime?
Back to work.
Fred
Saturday, April 24, 2004
Christopher is right. As the guy doesn't tell us what he wants to do we can hardly suggest anything for him to do it with.
I did love some of the suggestions as to something simple for a non-programmer - even Lisp got a look-in.
There are, incidentally, programming 101 books. The one I like best is by a guy called Al Stevens called "Welcome to Programming"; entirely off-topic but if anybody has got the files do it I'd love to have them - they came with the book but on a 5.25" diskette and I'm not in the mood to install a 5.25" drive just to read them.
Stephen Jones
Saturday, April 24, 2004
If the problem isn't solved by having someone code it, then the analysis has to be that degree more particular in order for some 'automatic' mapping system generate the solution.
Its actually a far harder skill to acquire than programming.
Simon Lucy
Saturday, April 24, 2004
IMHO there are two mindsets in this age-old discussion.
1) The arrogant belief that anything that makes a job easier isn't possible, or the fearful belief that anything that makes a job easier will take my job away. Both of these are akin to FUD - they muddy the waters with doubt and angst while really adding little to the issue.
2) The experience that despite what people on the outside may think, it's not about job protection or fiddling with tools - the job is simply that freaking hard. Look at this board's reaction whenever lawyers are mentioned - "lawyers make things harder to protect their jobs" or "just get a book from Nolo and copy it." The thing to remember is that most lawyers don't make things hard for the sake of them being hard. They make things hard because they are trying to mediate between a) what their client is demanding, b) what the other side is demanding, c) what their experience tells them is the best way to proceed, and d) what a thousand previous litigations have produces in the law.
It's the same way with any profession. There's a joke about a mechanic who fixed a knocking engine with one tap of a hammer then billed $75. The patron wanted an itemized bill, and got one:
One tap with hammer: $1
Knowing where to tap: $74
Ours should be the same. It doesn't matter that VB reduces two hundred lines of C to the dragging and dropping of one control, or that modern RDBMS engines reduce a full-time DBA job to two hours of work a week. The part where we're supposed to be earning our way is helping clients design applications that maximize the efficiency gained. Design and architecture; earning user buy-in; scalability where needed while not wasting time over-engineering the silly things.
Telling them they don't need a quad-processor with dual RAID arrays to handle their 50MB of data...
Our job is not to drag controls onto a canvas or write lines of code to weave together libraries - it's about being able to THINK like a programmer; to be able to hear a problem and visualize the data and code.
THAT is what no "Learn x in 24 hours" book can teach you.
Philo
Philo
Saturday, April 24, 2004
Damn Philo... spot on.
Almost Anonymous
Saturday, April 24, 2004
That's not *all* it is:
http://zapata.seas.smu.edu/~gorsak/hamming.html
Saturday, April 24, 2004
Philo: I read the same kind of story, except it was Picasso, when asked by a rich woman at an exhibit that he wanted $20K for a painting that took him 10 days.
"20 grands for ten days of work?", she asked.
and Picasso said: "Sure, ten days to _paint_ it, but ten _years_ before this to master the technique" :-)
Fred
Saturday, April 24, 2004
If we extend the Picasso analogy into this discussion, though, we've got someone coming along and asking how they can do a painting.
A few Picasso's pointing out there's a bit more to it than selecting an easel, canvas and paints.
Hey
Sunday, April 25, 2004
Bored Bystander: "The reaction from programmers who have been doing this for years seems to be like a blue collar worker's dismissal of anyone who seeks an easier and more direct way to do something backbreaking."
To me, the doc seems to want a Star Trek computer. One where he just says: "Computer. Write me a program that does this...".
Unless I'm mistaken, no such thing exists. This is the simplest explanation for why his questions are dismissed. There's no need for a geek-ego love of complexity or a survivor mentality to explain the dismissiveness.
You're reading too much into both the questions and the responses. Jason knows nothing about programming and can barely ask a sensible question. He's a newbie. He's unlikely to even understand the responses because he can't be bothered learning to program. I'd be more interested if someone who can program was asking the questions, because they'd know what is and isn't currently possible and their questions would be more insightful. Asking the right questions is often the hardest thing to do.
Also, you seem to have come across a lot of really moronic programmers in your time. I haven't met any like the ones you have mentioned. I've only met dumb ones who avoid complexity because they don't understand it and smart ones who avoid complexity because it adds bugs and drains time (so they abstract it away). Both would jump at the chance to use a Star Trek computer. Neither have a geek ego that affects their ability to make sensible decisions.
Now, if you'll excuse me, I have a date in the holodeck...
RB
Monday, April 26, 2004
I suppose I'm not the only pie-in-the-sky do it yourself physician.
http://www.cioupdate.com/trends/article.php/2234601
Also. Mr Analogy wrote:
" So... when this new magic development system comes around, sign me up!"
Is that how most of you feel? Would you "switch over" to another programming environment if it was worth it- say, a new post- or subset- OO environment?
Also, yes, I am a "newbie"; and that naivety is perhaps my best asset; what leads me to ask "why not?" I, like many domain experts, do not have a financial motive to develop applications - I just want to solve the problems in my field. And my lack of ability in doing so- programming- is a burden on the advancement of my science (said another way, if there is no profit to be made, many products simply will never come-to-market, no matter how useful they may be in a certain field). And that is my dilemma. And that is why I want a tool in my hands.
Doc. Jason
Monday, April 26, 2004
Doc, I followed up the link you provided and found an essentially content-free page that mentions something called "Open Infrastructure for Outcomes". Further searching uncovers a SourceForge project with this summary: "OIO is a Web-based medical/patient, user-extensible forms, and online analysis system. We use it at Harbor-UCLA for health/treatment outcomes data. Forms can be exported+imported as XML and exchanged via the online OIO Library at www.TxOutcome.Org."
So we have a very specifically-tasked application being written and maintained by programmers. That maintenance includes the addition of new features, improvement of existing ones, and correcting of bugs. This application is designed specifically to allow people to record information about specific individuals and/or events using web-based forms that are designed by the users themselves.
At this point you just have a configurable application, not 'programming for non-programmers'. At least that's my interpretation; I've provided similar tools to some of my clients.
If the Source Forge project contributors continue extending this application (they already allow user-defined regex* for field validation), they may eventually end up with a domain-specific programming language or maybe even a general purpose programming language. In either case, the user is either going to have to become a programmer or hire one. My personal opinion is that even for the existing application, a programmer would be able to make sure your custom screens make sense (i.e. no duplicate entry of data, etc.).
*regex is a common abbreviation for 'regular expressions'. Search the web for either phrase and you'll quickly discover that mastering regex is non-trivial. I believe that many programmers would consider mastery of regex to be an excellent start down the road to becoming a programmer.
Ron Porter
Monday, April 26, 2004
Doc Jason,
I still think your best bet is to attempt to learn programming at a surface level so that you can phrase your questions in such a way that programmers can help constructively.
A second alternative would be to look for someone else's software that is a solution for a type of problem that is similar to the one that you're seeking to solve. In this case, you'd be using an analogy to help communicate a concept.
After reading your last response, I think RP was right and you can't be bothered to grasp the fundamentals of the field about which you're inquiring. I think many of us take this as deliberate trivialization of necessary complexity.
Programming has never been conceptually pure. That's not to say that it can never be nor never will be, but that programming has always consisted of dirty menial details and mastery of someone else's specialized abstractions.
There's a chasm here. You haven't once explained the nature of the type of problems that you wish to solve. We can't help you since what you wish to do is absolutely unknown to us.
You're so far removed from any way to help you that it's not even funny...
Bored Bystander
Monday, April 26, 2004
RP,
>> Also, you seem to have come across a lot of really moronic programmers in your time. I haven't met any like the ones you have mentioned. I've only met dumb ones who avoid complexity because they don't understand it and smart ones who avoid complexity because it adds bugs and drains time (so they abstract it away).
Yeah, glad you caught that.
I am in the US, in a "flyover" (non coastal) area in the midwest. Developers around me are isolated and undereducated, and even anti-intellectual.
What tends to be created in an isolated and inbred population like this is excessive complexity for its own sake.
Bored Bystander
Monday, April 26, 2004
Oh, I forgot to answer the question you posed: "Is that how most of you feel? Would you "switch over" to another programming environment if it was worth it- say, a new post- or subset- OO environment?"
Absolutely! I've already switched a few times and anticipate switching at least once more before I retire. I started with hand-assembled machine code, moved into stack-based languages, swithed over to procedural languages, and finally made it to object-oriented programming. I'm not sure what comes next, but if the past can be used to predict the future, I'll be doing something new within a decade.
Ron Porter
Monday, April 26, 2004
Some of the logical disconnect that's showing up, Doc Jason, is that programmers are already doing the very thing you're talking about. When I write a program, all I'm doing is telling the computer what it is that I want it to do. The chief problem is that the brightest computer in the world has less capacity for understanding than a dog. The only thing it knows how to do is shuffle numbers around. So I use a language that's appropriate for shuffling numbers (C) rather than one that works well for dogs ("find the cat"). All I'm doing when I program is telling the computer what to do, in the simplest and most direct language that I have available.
What you're proposing is sort of the equivalent of a programmer deciding that he should be able to practice medicine without first going to medical school.
The system you pointed out as an example is neither revolutionary, nor is it programming free. It's also very restricted in its abilities. Since it's focused on patient records, I'm willing to go out on a limb and suggest that it isn't a good tool for managing the pharmacy's inventory the the hospital payroll. I also don't think that it could be easily extended to do these things without a programmer getting in there and geting their hands dirty.
What you want is to sit down with Microsoft Access. It's a great package, has all of the capabilities of the tool you gave as an example, and isn't so tied to a specific use. It's also a lot easier to administer.
Clay Dowling
Monday, April 26, 2004
Leaky Abstractions.
http://www.joelonsoftware.com/articles/LeakyAbstractions.html
Surprised no one has mentioned this yet (or did I miss it?). The Doc is asking (I think) for a language that expresses concepts in his domain of expertise and then compiles them into something a computer can understand.
But what's likely is that at some point he will write an expression that takes an order of magnitude or 3 longer to execute than another expression that didn't look much different. And he'll have no idea why. Or an expression won't give him quite the result he was expecting, and he'll have no idea why or how to change it. Or he'll want to express something that his language can't quite seem to express and he won't know how to add it.
At that point, the Doc will have to a) higher a programmer b) get more educated about programming or c) give up.
Jim Rankin
Monday, April 26, 2004
"At that point, the Doc will have to a) higher a programmer b) get more educated about programming or c) give up."
And that's a hurdle he'll have to jump if/when he reaches it. Until then, however, he'll be doing what he wants to do in the way he wants to do it. It's getting that initial foot in the door that counts.
Never underestimate the importance to users of being in control of their own destiny. And don't assume that their values and priorities are automatically the same as their own. For many, even a little power can go an awful long way.
Example: I started out in Mac application scripting while working as an illustrator in a publishing house, and it took me almost a couple years before I exceeded my amateur scripting skills and finally knucked down and learn to program properly. In the meantime, I managed to script my desktop, munge postscript files and automate various page layout tasks; not bad for a "non-programmer". If I'd had to learn "real programming" first, I'd have stuck to doing it all by hand as a lot less time and trouble.
Or, to paraphrase the great Gilbert Shelton: "Expert domain knowledge and enthusiasm will get you through times of no formal programming skills better than formal programming skills will get you through times of no domain knowledge or enthusiasm." :)
has
Monday, April 26, 2004
Jason, an empty mind is not the only kind of open mind. But at least the ignorant are more easily forgiven for pointing out the emperor has no clothes. ;)
This reminds me of the defunct Feyerabend Project. Some people known by this forum, like Jerry Weinberg and Ward Cunningham, apparently used one of its workshops to privately explore topics that, if mentioned publicly, can injure many peoples' professional reputations. And I have little doubt it influenced their teachings positively, looking at what they do.
Tayssir John Gabbour
Monday, April 26, 2004
Incidentally, I did not mean to sound insulting by calling anyone "ignorant." I should have said something like "newbie." I was just not thinking straight; I just had a small disturbing feeling that you were taking a bit too much pride in not being willing to learn.
Now, there are many ways of learning computers that are worse than knowing nothing at all, and I tacitly respect your position. But unreasonable people expend unreasonable effort at some points, and your claim that you can't "afford" to learn programming is a rather reasonable statement.
Tayssir John Gabbour
Wednesday, April 28, 2004
Hey, nothing wrong with "ignorant". It's bliss. :)
has
Wednesday, April 28, 2004
 Recent Topics
Fog Creek Home
|
